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




More information about the LibreOffice mailing list