Re: freebsd-current Digest, Vol 77, Issue 70

* freebsd-current-request_at_freebsd.org <freebsd-current-request_at_freebsd.org> [041106 10:09]:

> ------------------------------
> 
> Message: 16
> Date: Fri, 05 Nov 2004 16:38:21 -0700
> From: Scott Long <scottl_at_freebsd.org>
> Subject: FreeBSD 6.0 and onwards
> To: "current_at_freebsd.org" <current_at_freebsd.org>
> Message-ID: <418C0EED.1060301_at_freebsd.org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> All,
> 
> FreeBSD 5.3 is about to be announced this weekend and will signal the
> true kick-off of the 5-STABLE and 6-CURRENT series.  We are very excited
> about this, both because 5.3 is a good release, and because 6.0 will
> give us a chance to, erm, redeem ourselves and our development process
> =-)
> 

Thanks a lot Scott and all the TEAMS.

I prefectly understand your issues reported in your mail,
and I simply can say, you are all doing the BEST.

If every "System" ( and I dont talk about only the informatic systems )
would follow such discussions, analysis, workflow, then everything
would be much more "Stable" in life :)

That's one Reason why, I think FreeBSD is the best out here at this time.
10x a 1000000
alex

> 5.x was a tremendous undertaking.  SMPng, KSE, UFS2, background fsck,
> ULE, ACPI, etc, etc, etc were all incredible tasks.  Given that many of
> these things were developed and managed by unpaid volunteers, the fact
> that we made it to 5-STABLE at all is quite impressive and says a lot
> about the quality and determination of all of our developers and users.
> However, 4 years was quite a long time to work on it.  While 4.x
> remained a good work-horse, it suffered from not having needed features
> and hardware support.  5.x suffered at the same time from having too
> much ambition but not enough developers to efficiently carry it through.
> 
> By the middle of 2002 is was very apparent that we needed to start
> focusing on getting 5.0 released.  Unfortunately, we fell into the trap
> of wanting to finish more features in order to feel good about 5.x.  We
> kept on ignoring the fact that 5.x already had a lot of good and needed
> features, and that the number one goal needed to be to get it stabilized
> and turned into 5-STABLE.  Instead we drew up a road map document that
> dictated releases based on features rather than on stability and, even
> more importantly, timeliness.
> 
> There has been quite a bit of discussion about this over the past week
> by the developer community.  The proposal that I and Poul-Henning have
> set forth is to stop gating releases, both major and minor, or features,
> and instead gate them on a schedule that is both reasonable and timely.
> New -STABLE branched will be made on a calendar-based time line, and
> point releases on those branches will be made at regular intervals.  We
> are still debating the exact time line, but it will fall somewhere
> between doing a new -STABLE branch every 12-18 months, and doing point
> releases every 4-6 months.
> 
> While as engineers we all tend to hate timelines, this does have a lot
> of positive aspects.  First, it increases the predictability of the
> development both for our users and for our developers.  Users can plan
> effectively for upgrades and testing/validation knowing that there will
> be major and minor releases at fixed times of the year.  Developers can
> judge when to start new projects and when to focus on bug-fixing because
> there will no longer be the temptation to delay a release by a month in
> order to slide 'one more thing' in.  This is not unlike most commercial
> OS vendors, and we've received a _LOT_ of feedback that this method of
> planning is desperately needed.
> 
> Second, it means that development efforts for major features will
> continue to shift out of CVS and into Perforce.  This already happens
> quite a bit, so it's not as radical of a change as it seems.  CVS HEAD
> will remain the 'experimental' development branch, but large items will
> not be brought into it until they are functionally complete and
> integrated.  HEAD may still get unstable from time to time, but it
> hopefully won't turn into the collision of lots of half-done
> experimental things like it has in the recent past.  It also means that
> if a major feature isn't done in time for a -STABLE branch-point that it
> can continue to be developed outside of the CVS tree and be made ready
> for the next scheduled branch point.
> 
> Third, by having more frequent and scheduled branches and releases, we
> avoid the 5.x problem of having too much time to let too many things
> get into the tree and dilute developer resources to handle and debug
> them.  As I said at the beginning, 5.x has an incredible number of big
> things.  6.0 will be more modest, and will 7.0 and on.  We'll know when
> to 'stop digging and start climbing', and Robert aptly puts it.
> 
> So the current plan is to branch RELENG_6 (aka 6-STABLE) sometime around
> May or June 2005.  That will begin a 1-3 month freeze and stabilization
> process for the 6.0 release.  After that is released, we will do 6.1,
> 6.2 and onwards at likely 4 month intervals.  In May/June 2006 we'll
> look at doing RELENG_7, or we might wait until Nov/Dec 2006 (12 months
> vs 18 months).  The 5.4 release will likely be in Feb/March 2005, with a
> 5.5 release possibly in June/July, depending on where 6.0 is.  There may
> be 5.x releases after 6.0 if 6.0 turns out to not be as stable as needed
> (as is often the case with and .0 release).
> 
> As far as promising features for releases, this new process means that
> we will be getting away from that.  That's not to say that there aren't
> many big features that need to be done, but whatever is not done in time
> for the 6-STABLE branch will have to wait until after 6.0.
> 
> I expect (and hope!) for there to be a lot more discussion on this.
> However, it has already been discussed quite a bit at the developer's
> summit last Friday and in the days since, so this is really more of an
> announcement of the release engineering team and the project's
> intentions going forward.  Once 5.3 is formally announced and we've
> had a few days to see the results, I'll publish a formal schedule.
> 
> Again, thanks to all of the developers and all of the users that have
> worked so hard on bringing 5.x forward and keeping 4.x viable.
> 
> Thanks,
> 
> Scott
> 

Thanks a lot
alex

-- 
** acme aka Alex D'Elia		--> root.acme.com
** mail:: acme_at_enemy.org
**