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.