Re: [Gimp-developer] refactor palette loading code

[Warren Turkal <wt penguintechs org>]

On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès <jehan marmottard gmail com>wrote:

> On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
> <drawoc darkrefraction com> wrote:
>  > As a side note for the future, the fastest way to get a patch reviewed
> > is normally if you post it to a pastebin and bother people on irc.
>
> For my own, I would prefer a git format-patch like this, but on a
> feature request/bug report on bugzilla. That's easy to patch a branch
> and to remove after. And also we keep track of any discussion or
> updated patch about a feature/fix. For instance go find this email
> thread in one year in the mailing history.

Even for small refactorings like this one? I would certainly understand
that for a feature add or a major refactor, but it seems like a lot of
overhead for a pretty small refactor like this one. However, I am willing
to do whatever you folks want since I just wanna help the project. However,
please keep in mind that I have very little time to commit to this kind of
work.

> P.S. I don't see the patch on that last email. Are you sure you attached
> it?
>
> I see it but I was also a direct recipient. I guess that the list
> cleans emails out from any attached file.
> Could we have conditional filters? Like any text file with a ".patch"
> or ".diff" extension should not be filtered out.

You should also allow git bundle files, which are a way to pass around git
commits. I have attached one to this mail that includes the second
iteration of my change. I guess only direct receivers of the email will
receive it.

wt