* Nicholas Clark <nick@ccl4.org> [2011-01-04T03:54:55] > > 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? Here's some anecdotia. I've come across a number of "approved" commits that are not actually cherry-picked. It seems to me that if the commit is approved, and I'm going to do the next release, I should pick it. So, that adds time -- three people wanted the commit, but not enough to pick it, so I will. Then I find out that it won't actually apply cleanly. A previous commit, possibly only seconded but not approved, is required. So I review that and pick it to apply, then go back to the approved commit. Then I find that tests fail, because there's now a Pod syntax error, which is fixed in later, not-even-requested commit. This takes *much* longer than C code patches, which I ignore entirely. -- rjbsThread Previous | Thread Next