Re: [Gimp-developer] refactor palette loading code

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal <wt penguintechs org> wrote:
> 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.

Well there are no strict rules, I guess, likely because the team is
small. I guess the real "rule" is to do so that others are not annoyed
by the form your patch (so that they will actually check it, and not
delay it to forever). Which means that if the other developers are ok
with a git bundle for instance (I did not even know what it is, I had
to look it up), or by adding your repo as a remote, well that's all
good. :-)

I am myself flexible and adapt to various team logics. But by
experience, I know some others of the core GIMP team want git
format-patch. When I made my first patches (I am myself likely the
most recent of the core developers), I also set up a public git repo
for others to fetch. Well I was told my patches would more likely be
reviewed if I provided patch files instead. And now I got used to it,
so I work also easily with these. That's not more time-consuming.
With a patch formatted with `git format-patch`, you can just "git
apply" it, and done! So easy to review (and also to commit if the
patch looks good with with git am, nothing to do).

I believe that at the opposite, for small patches, it is much easier
to provide patch files than maintain a public repo. For huge features
which require many commits over weeks, yeah there probably a public
branch is worth it. :-)

Jehan

> > > 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