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@xxxxxxxxx>wrote: > Hi, > > On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal <wt@xxxxxxxxxxxxxxxx> > wrote: > > On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx > > > > wrote: > >> > >> On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning > >> <drawoc@xxxxxxxxxxxxxxxxxx> 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 > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
