Hi E, On 9/2/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: ...
As stated, the 1.5.1 should have been released much sooner, but we > didn't. Let's try to deliver 1.5.2 by mid october. +1 2) Process > ----------------- > > The next release should be smoother than this one. We were in a hurry, > many of us were having vacations, some of us had personnal issues to > deal with. This is unavoidable, but we should be carefull when planning > a release during summer, easter or christmas. It would also be > interesting that active committers give a planning of their vacations > when we try to define a release schedule. > > It leads me to the next point : we may need a release manager for the > last month before a release. The release manager role is quite easy, > it's a kind of project manager. Dealing with planning, tasks, missing > committers with an affected task, postponing tasks which can't be done > by the milestone, stuff like that. The difference with real life > projects is that we are all volunteers, so all 'resources' are not > available on call. I could not agree with you more on this. And as you stated at some point it has to be someone who is objective and not trying to fix the bugs themselves. 3) Next release > ------------------------- > I'm not sure we will add a lot of features in this next release, in my > mind it would be much more a bug fix release. But it's not just about > me, we need to discuss it. Yes I think we should only focus on a few points keeping the next release simple: o code cleanup so we can be more efficient o architectural changes o bug fixes Some features/improvements/wishes can be handled if they facilitate the above points. For sure, we need 1.5.2 before ApacheCon US (Nov, 12-17). I'm not sure > that any of us is going to Atlanta (may be David ?), but it's important > to keep those Apache Conference as milestones for releases, as they are > the place we can announce novelties and benefits from the ApacheCon buzz. > > I would like to get 1.5.2 certified with the STANDARD compliance. I > think it's possible, but we have to do a round trip with OG, as I > _think_ that there are some bugs in their tests (to be confirmed). I would like to do this which will help cleanup the referral handling issues. I also want solid infrastructure setup around running these tests at the push of a button so we're not pinging Zoerner everytime we need to run the test. Hopefully we can get some hardware soon to do this but 40 days may not be enough. Regardless this is something we need to get the ball rolling on. We should also conduct real perfomance test, and compare ADS with > previous versions (1.0.3, 1.5.0 and 1.5.1) and with other servers > (OpenLdap, OpenDS and FDS). We have a load of machines, let's use them ! Yes we need to setup the infrastructure to do this as well. The SLAMD environment will be critical. --------------- > > Ok, it's enough for me, I would like to get your feedbacks and feeling > about this release, and about the server as a whole. Well this release realy sucked IMO because of the pressure element. It did not feel like an OS thing. But we did not plan ahead of time so this could have been avoided. It and was also a lower quality release even though it was jammed with goodies like the new installers and improved functionality. I guess that harmless stack trace with the unbind handler really sticks me in the side, I hate seeing it and if it was not for LDAP Con I would have cast a -1 on this release. I keep telling myself that this is just a feature introduction release but I want to make sure we don't slip on our quality even if it's a feature introduction release. Thanks to everyone who participated on this release, especially those > who killed themselves working hard hours in the last few days ! Yeah lot's of people went above and beyond the call of duty to make it happen so fast. Really this was a lot of work but I want to make sure we don't burn out our people by planning a little better. As a community this is the next stage. Perhaps some altered form SCRUM techniques may be used to lessen the slippage along with an independent release/project manager. Alex
