Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.