Jim Jagielski wrote: > William A. Rowe, Jr. wrote: > >> From discussion - I see us branching 2.1.x anyways, but still object >>since we will now be maintaining two or three backports for every >>bugfix commit to trunk/. Humbly suggest this isn't the conclusion >>we reached at AC Las Vegas, and suggest it's still the wrong solution >>to a non-problem. >> > > > Bill makes some good points... it seems that branching would simply be > "renaming" trunk. The good thing is that with svn this is cheap > and easy, but will it really do what we want? Also, the "gotta > backport this to yet another branch" issue is valid. > > In other words, trunk is 2.1 anyway, so what does a branch provide? > I would say it's a perception advantage mostly.
Yes. I think it is almost 90% about perception. This is about 'drawing the line in the sand'. Personally, I have held off on starting refactors of code, because I do not want to be detrimental to the ability to make a 2.2 Branch. I would like to investigate making more parts of httpd async, in conjunction with the Event MPM. I would also like to redo some of the configuration system -- but I have avoided working on these, because of my personal belief that 2.1-dev has enough for a new GA branch. I think there is wide agreement that /trunk/ should always be open for commits. I don't imagine that my personal development ideas match everyone, and they are not my only reason for wanting a 2.1.x branch. Right now, I see 2.1-dev as a never ending version. There are always problems, and there will always be new problems with trunk. Yes, it makes back ports harder, and I believe, rightfully so, because we already have enough features for 2.2. This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? I don't think the two listed in the STATUS file reflect reality. If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. -Paul
