On Tue, Jan 04, 2011 at 06:46:21PM +0800, Jesse Vincent wrote: > On Tue 4.Jan'11 at 8:54:55 +0000, Nicholas Clark wrote: > > > > 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? > > Is this the part where I ask you if you want to do 5.14.2? ;) Not if you know what's good for you :-) Actually, I've just realised what *is* interesting here. As soon as Ricardo starts working on being the release manager for a maint release, he starts being a lot more careful/concerned with the mechanics of the maint process. [And Dave started to realise why *I* was doing blead commits the way I was once he started working on 5.10.1] 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) > It doesn't take as much time as a C patch. But it does take time. "noted" sounds rather flippant, but it *is* useful to know. Thanks. Nicholas ClarkThread Previous | Thread Next