ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Slawa Olhovchenkov                   2:5030/500     07 Nov 2004  23:41:42
 To : All
 Subject : Вести с полей
 -------------------------------------------------------------------------------- 
 

 
 From: Scott Long <scottl@freebsd.org>
 
 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
 =-)
 
 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
 ... АТС 73 защищает Ваши модемы от каppиеpа с утpа и до вечеpа...
 --- GoldED+/BSD 1.1.5
  * Origin:  (2:5030/500)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор