On Wed, Feb 13, 2002 at 11:32:46AM -0500, Padwa, Daniel wrote: > > It could be a chicken-and-egg problem. If the developers of those tools > don't have a > > lot of users asking for Apache 2.0 support, what is their motivation for > providing it? > They are probably like us, with lots of other things on > their to-do lists. If we had a > golden release, perhaps that would help > change the situation. > > Really not trying to throw out flamebait, but....... > > I think Greg hit the nail on the head here. There hasn't been much > visibility to anyone not following this list (or even to many following it) > of a timeline or roadmap to gold on 2.0. Do people know that all the major > interfaces are stable? Are they?
Nope. We can only know that the major interfaces are stable by receiving feedback. Seeing how the input filters worked dictated (in my mind) that we needed to change that interface. However, I'm hopeful that we won't encounter anything in the future. As we get more developer feedback, we can tweak the APIs. However, once we've decided on a GA release, our APIs should be fairly consistent. > Is there yet a consensus on a timetable for getting this to gold, or is it > still a "when it is ready" approach? If the latter, it's going to be hard > to get people very excited about even kicking the tires on the betas. Well, true. My emphasis is switching from development to getting this to GA quality. I'm probably not going to be adding new features at this point. Each developer will have to make that call on their own. My goal is now to see a stable GA-quality release hit rather soon. Personally, I've been using Apache 2.0 for my own websites for a few months and haven't encountered any major issues. > It's going to be really hard to build momentum towards a release without a > release target and active release management. According to the latest > STATUS, we've had only one tag/roll event (2.0.31) in the last three months. I believe .30 would have gone beta except for the fact that we ran into a problem running it on daedalus. .31 got hit by some input filtering problems and Win32's brokenness. And, .32 is far better than .28 is. > It's also confusing to customers when at least two vendors are distributing > Web servers that are "based on 2.0" when 2.0 is still not fully baked. Heh. You're not the only one who finds it amusing that commercial companies are distributing products based on something that we often have trouble calling beta. I blame it on the fact that we have higher standards when there is no money to make off of it. =) > Justin's work on coordinating the .32 release has been extremely positive in > this regard (way to go Justin!). A few more releases like this can > probably get 2.0-gold out the door. Without that kind of focus on and > ownership of releases, it's going to be really hard to ship this thing. Hopefully, .32 will go out. We can then get constructive feedback on what's wrong and then move forward. .32 would have been out sooner if Win32 wasn't borked. I felt that it was definitely worth the wait for a beta to have functional Win32 support. That was my call - I know that some people would have made a different call. So, it goes. > PS> A simple roadmap and timeline, like the one that Subversion has at > http://subversion.tigris.org/project_status.html, would go a very long way > towards addressing these issues. I suggested this a long time ago and got beaten down for it (I think I referred to how Tomcat does it). The majority of our developers don't like the idea of enforcing timelines on a true group of volunteers (those people who get paid are balanced out by the different companies they work for). SVN is a bit different because the core contributors all work for the same company. They have a mandate from above to complete the task. Over here, we're not that structured where any one person has unquestioned pull over the group. Our release procedures are like stabbing in the dark, but I can't seriously come up with an alternative that works for our situtation. The only thing I can do is take the RM responsibility and try to shepherd a release out. Hopefully, the rest of the group can keep focused enough not to curtail my efforts. -- justin
