Re: [Gimp-developer] refactor palette loading code

[Warren Turkal <wt penguintechs org>]

I am willing to do whatever is needed to contribute. However, it would be
nice if the mailing list wouldn't block patches.

Has anyone taken a look at maybe using gerrit? It's actually a pretty
reasonable way to handle code changes when using git. It has a pretty nice
code review workflow. Projects like Android and Libreoffice use it. As an
example, here's a link
<https://gerrit.libreoffice.org/#/q/status:open,n,z>to the Libreoffice
instance.

wt


On Sun, Sep 15, 2013 at 2:22 AM, Jehan Pagès <jehan marmottard gmail com>wrote:

> 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