Front page | perl.perl5.porters |
Postings from January 2011
On Tue, Jan 04, 2011 at 03:24:47AM -0500, Jesse Vincent wrote: > On Tue, Jan 04, 2011 at 09:12:22AM +0100, Abigail wrote: > > Typo fixes and many other documentation improvements seems low hanging, > > non-dangerous fruit to me. I'd prefer them to be part of a maint release. Fixes other than typos can be dangerous, if they aren't relevant to (or contradict) behaviour in the maint branch. So they do need checking. > That is how the policy was written after a fair amount of lobbying at > me. I now regret it. The problem isn't whether it's low-hanging fruit > or not. The problem is that each patch adds somewhere between 5 and 15 > minutes of release-engineer load over the life of the release process. > > 25 simple doc fixes quickly start to add up, slowing down the release > and taking focus away from other things that Must happen. When I was doing maint releases I was keen to have them. *But* I was the person choosing to slow myself down. Also, I was (at least subconsciously) aware that the release of 5.10 seemed to be consistently "not happening yet", so any changes in blead "didn't exist", as far as most of the world was concerned, and I was keen to get them out. This, I believe, changes, now that we have clear desire and commitment to make regular new stable releases of blead yearly. Before, distribution upgrades seemed to be from 5.8.$older to 5.8.$newer, so (clearly) doc fixes need to be merged to become visible. I suspect now we're going to see distributions upgrade from 5.$older.something to 5.$newer.something. Yearly stable releases from blead are the new $mumble-monthly stable releases on maint. > I'm not ok with this idea. maint releases need to be as conservative as > possible. Part of making sure that happens is by requiring some checks > and balances before backports happen. Opening up maint for doc > backports without running through the process runs directly counter to that. Agree. However, there are more people qualified to review (and backport) doc patches. So in theory, if a sufficiency of volunteers volunteer, their part of the work takes care of itself without slowing others down. But, you've done it you way - I haven't. Were you finding that all patches were "equal", in that a doc patch potentially took as much of your time as a C code patch? Nicholas ClarkThread Previous | Thread Next