Early last week, Scott Long publicly requested heavy testing of the latest revisions to -current code, especially the new vnode layer [story], net80211 [story], and wireless lan drivers. Now, with the revival of the ULE scheduler [story], stress testing is likely even more urgent. Scott explains:
"There has been an incredible amount of work going into 6-CURRENT in the last 5 weeks. With the holidays quickly approaching, now seems like a good time to step back and start really testing the system to shake out the bugs and catch the developers before they disappear for the holidays."
Read Scott's full message below.
From: Scott Long [email blocked] To: freebsd-current Subject: Wanted: lots of 6-CURRENT testing Date: 2004-12-09 14:41:01 All, There has been an incredible amount of work going into 6-CURRENT in the last 5 weeks. With the holidays quickly approaching, now seems like a good time to step back and start really testing the system to shake out the bugs and catch the developers before they disappear for the holidays. In particular, the recent massive changes to the vnode layer and the upgrade of the net80211 layer and wireless lan drivers needs a lot of review and testing. Now is also a good time to review the recent additions to the PR database and start seeing if there are trends developing and/or areas that need immediate attention. While 6-CURRENT remains in a high state of flux I'll also ask that people carefully consider what to merge into 5-STABLE and when to merge it. Don't let important bugfixes that would benefit 5-STABLE and 4-STABLE drop on the floor, but also make sure that they recieve thorough testing before being merged back. Thanks, Scott
considering the debarcle that
considering the debarcle that is 5-X why even bother. why cant they work on 5 before they start waisting time on 6. shesh. get all those people waisting time on 6 to work on all the unresolved items for smp/ng, kse etc. lets see them remove giant. but ooh no.. lets put resources onto 6 before 5 is even workable. 5 is really a bastard child that should never have been.
with 4 being pretty much also given up ive switched to dragonfly. head is stable and works for me on par with 4. i see no reason to go back UNLESS they really put more effort into fixing 5.
Re: considering the debarcle that
Don't let the use of version numbers confuse you. RELENG_5 is the stable branch and a majority of major subsystem fixes (code rewrites, refactoring, etc.) is done in the -current branch and then merged back. This is how FreeBSD development has always worked. The goal of -current (tagged 6-current) testing is to target stable and reliable feature/fix merges to the 5 branch as well as to generally test new features.
It's important to note, however, that a -stable tag indicates that the dev team is not allowed to break userland and kernel API/ABI. Specifically, there are some changes that are entirely inadvisable to merge from current. Fixes of major subsystems in -current have to be carefully weighed (..and tested) to be deemed worthy for merges back to stable. Based on the the published release schedule, the stable branch is then cut for the next point release (in this case, 5.4).
> with 4 being pretty much also given up [...]
From Scott's email:
"Don't let important bugfixes that would benefit 5-STABLE and
4-STABLE drop on the floor, but also make sure that they recieve
thorough testing before being merged back."
Also, 4.11 is scheduled for release in Jan. I believe, and although it's considered "legacy", I disagree with the assertion that it's been given up on.
> i see no reason to go back UNLESS they really put more effort into fixing 5.
The majority of current freebsd development efforts, at this point in time, appear to be geared for just that.
as a freebsd users since the
as a freebsd users since the final 2 series, i fully understand the release engineering. ive run 3 head, 4 head and after fighting so much with 5 Ive plain given up. I understand 5-stable, 6-current. etc.
My point was, they need to spend more time fixing 5 than investigating 6 right now.
If as you say, its all geared to 5, why even bother asking for people to test -current??
wouldnt it be better to actually stabalise 5 then build 6 once 5 is solid? because right now 5 is far from solid at all. 5 may heave been a bit too ambitious a jump from 4 but, they put both feet in, and sofar, they are wobling on landing.
Re: as a freebsd user since the
Well, I dunno.. Core has actually changed their release cycle procedure this time around (and from here on..), in that they're basing their releases on a timeline schedule rather than a feature list. One of the problems observed during the 5 cycle was that, as you say, they were ambitious and developing strictly based on when a set of features would be completed left too much time for other code (more new features and subsystem improvements) to creep into the tree - developers were stepping on each other while still trying to complete a core set of release requirements. The way I see it, tagging 6 isn't a matter of investigating something new and leaving 5 behind, it's a matter of saying - "new stuff goes here", while continuing stabilization of the 5 branch and merging back beneficial commits from 6 - an absolute necessity. In that way, you don't hinder your future development and you benefit from unified design improvements that can be collectively tested.
The truth is, stabilizing 5 has a lot more to do with continuing to overhaul low-level subsystems than strictly bug fixes and I think the nature of the beast is such that they have to be able to make those necessary design revisions while still providing a viable production system that is released in a timely fashion. I've found recent stable builds to be very stable and my expectation is to see subsystem improvements in 6 make it to 5.4 and 5.5 once they're sufficiently tested.
Anyhow, I'm not a kernel developer for FreeBSD or any other OS, so I'm really just speculating. I'm aware of why core made these decisions and in my humble opinion, the reasoning is sound. My point is I don't see the testing of 6 as a departure from stabilizing 5, it's all part of the same process - commits to current are appropriately marked for MFC once they've been *tested*.
just my two cents.
I don't think he was debating that
The problem is that RELENG_5 is NOT stable. It should not be called stable. See.
You complain that RELENG_5 is
You complain that RELENG_5 is not stable and post a list of bugs that are present in a release from that branch that are a month and a half old. You must be joking!