:I tell you, it's just not possible to win, especially when those doing
:the most yelling are always conspicuously absent when crunch time
:comes. Matt wasn't really fully on board at the time and I'm not
:pointing my finger at him specifically, but it seems like everyone's
:hindsight is 20-20 whereas their immediate vision concerning what
:needs to be fixed in a timely fashion often comes closer to the legal
:definition of blindness. If you want to make this or any other branch
:a decent release target, the time to start is not 10 days before it
:enters a feature freeze, the time to start is right after it branches!
:It's my hope that people will take this lesson more to heart when 4.0's
:own time to branch comes up.
:
:- Jordan
Perhaps I should rephrase: The system was branched without any
significant stabilizing period afterwords. It was a holy mess.
What I am suggesting is that we have an enforced stabilizing period
after the 4.0 release BEFORE we branch 5.0 that is long enough to
actually get feedback and stabilize the system using that feedback.
In otherwords, we should branch with the 4.1 release rather then the
4.0 release.
3 or 4 months seems about right to me. There are no projects which are
going to get so far along that we can't wait 4 months to commit the
patchsets (here I am talking about SMP and VFS). It gives everyone
(including me) a chance to relax a bit and work on stabilizing what we
have for the 4.1 release rather then going off and messing around with
personal projects. While it is true that self-discipline can accomplish
the same thing, I think having an official enforcing framework will yield
much better results in an open-source project.
I would also like to point out that doing this reduces the MFCing load
as well, When 3.0 was released and we branched 4.x, many of us (including
me) had to deal with issues relating to all *THREE* branches for a long
time. While this doesn't entirely go away, waiting a few months to branch
after a .0 release will allow people to continue to concentrate on the
two existing branches for a little while and get them shipshape prior to
starting work on a new branch.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
