Front page | perl.perl5.porters |
Postings from January 2011
On Tue, Jan 4, 2011 at 5:57 AM, Nicholas Clark <nick@ccl4.org> wrote: > The same thing seems already to have played out with the blead releases. > Once individual committers had started to enjoy the "fun" of the actual > release engineering process, I got the impression that they started to be > more aware of it when making commits generally. So it seems beneficial to > the overall process to have as many people experience as many parts of it as > is sane. (Provided that they want to, they are competent, and we don't > compromise quality) +1 That was definitely my experience. On topic -- I think the blanket rule "if there is any question ... then it almost certainly should not be included" is the right guiding rule and the bullet point on documentation implies a more liberal rule and should be clarified. I liked Ricardo's suggestion: "Documentation updates are acceptable if they fix broken links, broken Pod, or correct factual errors." That's very specific and on par with the other bullet points relating to code. The gray zone might be a situation where substantial document cleanup, refactoring or revision was done in blead and *then* a factual error was found. It might sometimes be easier for maint to pull the refactoring commits and then the commit that fixed the error. But I'd leave that to the discretion of the maint manager to do or else just reject the whole thing. (Since I assume that we want minimal commits in maint -- e.g. a targeted error fix -- that aren't in blead). -- DavidThread Previous | Thread Next