On Wed, Nov 12, 2003 at 05:51:46PM -0800, Justin Erenkrantz wrote: > >Creating roles like this is just as bad as having chunks of httpd "owned" > >by one particular developer. (See below) > > I don't think you understand the role of 'patch manager.' On the projects > I'm involved with, that person's only responsibility is for ensuring that > the patches posted to the mailing list are entered into the right tool. > > I think that can easily be a volunteer, rotating job as you don't need to > do anything more than that.
I don't know what this hypothetical tool looks like, but why wouldn't the person submitting the patch just use the tool directly? Seriously though, until we actually have a tool that we want to use, this part of the discussion is moot. > In the patch manager role, nothing would preclude others from adding > patches to the right tool. But, having someone whose responsibility it is > to ensure that patches get inputted into the tool on a timely basis is > goodness. On other projects I'm involved with, that person isn't an even a > committer. They don't have to understand what the patch does - just make > sure it is recorded and allow for annotation. > > And, it doesn't have to be on a 'timely' basis - once a week, you go > through and ensure that all [PATCH] messages are in the right patch > management tool. This lessens the number of dropped patches that we'd > have. (Bugzilla sucks at this, so I think we'd need a new tool.) Bugzilla wasn't designed for this, so yes, it sucks at it. I still maintain that the person submitting the patch should simply enter it into the patch system directly. Even easier would be a patch system that monitored the list for [PATCH] emails and tracked those automatically. We might come up with some standard syntax to help the patch tracking system know what version of httpd (or apr or whatever) the patch applies to. > >Woah woah woah. Are you discouraging people from thinking about big > >changes for the 2.2 timeframe? If someone has a revolutionary idea for > >the next generation of Apache HTTPD, who will stand in their way? Not I. > > Frankly, yes. > > I think our changes that we already have in the tree is about 'right' for > 2.2 (no big architecture changes, but lots of modules have been rewritten > and improved). It's just that no one has time or desire to shepherd 2.2 to > a release. And, I think we need APR 1.0 out the door before 2.2 can be > rationally discussed. [tangential issue] Why does it take some much time and desire to make a release? Shouldn't that be one of the easier things to do around here? > If we did any major changes from this point that require modules to rewrite > themselves, we'd need to go to 3.0 per our versioning rules. And, I'd > *strongly* discourage that. I don't think it's in anyone's best interest > to revamp our architecture at this stage. > > We don't need to give a moving target to our poor module developers. Only > by producing a series of high-quality releases can we ensure that module > writers will be confident in writing against 2.0 or 2.2. If we come out > with 3.x now, I think we'll just end up hurting ourselves in the long run > even worse than we are now. Let me pose a different angle: If our module API is so broken that we need to change it in an incompatible way, then don't you think the module authors would rather have the improved interface rather than being stuck with the broken one? In other words, the only time we actually talk about making drastic changes is when they are warranted. Therefore, being conservative about API changes merely serves to discourage creative development and that is _a bad thing_. -aaron
