Re: [Gimp-developer] refactor palette loading code



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]