[Libreoffice] Patch handling guideline
Kevin Hunter
hunteke at earlham.edu
Mon Feb 21 17:59:10 PST 2011
At 2:40pm -0500 Mon, 21 Feb 2011, Kohei Yoshida wrote:
> http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline
>
> to help us develop some sort of guideline in order to handle this
> ever increasing amount of in-coming patches. The page is intended
> for both those who submit patches, and those who review& push them.
> This page is only 2 hours old, and my hope is to get this page
> developed further into a full-fledged guideline.
Good work, Kohei! The unfortunate reality is that administration of a
project is just as important as the project itself. This page, though
unfortunate that it took away time from the fun part of coding, is very
important. Kudos.
A minor to note: the last section, titled "Reply to the thread with
[PUSHED] tag", talks about a feature of mail clients that is apparently
sometimes lacking. If this is the preferred method for working with
these patches, be prepared for some pushback from folks who work with a
client that doesn't implement the In-Reply-To header. I personally
agree with you, and would not-so-humbly suggest folks change mail
clients for that one feature, but just a heads up to be prepared.
> Also, until now, only a handful of core developers have been
> reviewing patches. However, this obviously does not scale with this
> increasing number of patches to review (unless the core devs have
> nothing else to do than reviewing patches, which unfortunately is not
> the case). So IMO anyone with commit access with reasonable
> experience working with the code base should be able to review
> patches& are encouraged to do so.
Great idea and thought process. After pointing out that I'm not
currently one with commit access (and don't deserve it yet, either),
I'll say I concur with your opinion. This has the two-fold effect of
freeing up more core-dev time and educating others. Analogous to how
one learns a concept much better when teaching it, so too will folks
learn the code base better when reviewing other's patches. Some
mistakes will be made, but that's what working in a group is for, as
well as tests-galore. As the committers for this large project are
still yet small in number, any deliberate and conscientious education of
a younger crew (like myself!) will be the long-term lifeblood of LO.
> I'd like to know what others think of the current situation, and if
> there is a good way to handle this. Feedback appreciated.
I don't think it's time yet, as we are still largely in a cleanup phase,
but one approach that has worked very well for the Postgres project is
the idea of a Commit Fest.
http://wiki.postgresql.org/wiki/CommitFest
Cheers,
Kevin
More information about the LibreOffice
mailing list