Doug Barton | 18 Jan 00:50 2012
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

First, let's do away with the whole, "If you step up to help, your help
will be accepted with open arms" myth. That's only true if the project
leadership agrees with your goals.

We also need to take a step back and ask if throwing more person-hours
at the problem is the right solution, or if redesigning the system to
better meet the needs of the users *as a first step* is the right answer?

On 01/17/2012 15:01, Adrian Chadd wrote:
> .. I'm replying to the OP because honestly, this thread has gotten a
> bit derailed.
> 
> If you'd like to see:
> 
> ... more frequent releases? then please step up and help with all the
> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".

Does it need to be? I've been pushing a long time now to have a branched
ports tree. If we have a "stable" version of the ports where only
known-good changes are promoted then that frees us up quite a bit to
redefine what a "release" is.

> ... longer lifecycle? Then please step up and contribute patches for
> features for your favourite branch. As a developer doing this in my
> spare time I'm only really working on new features on -HEAD and maybe
> backporting fixes to 9.x. What _I_ would like is someone to take on
> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.

So you want to do all the fun stuff, and have someone else do your scut
work? Good luck with that. :)  Maybe what we need to do is redefine what
it means to be a FreeBSD committer. "From now on, your commit bit comes
with XYZ privileges, but also ABC responsibilities." Sure, we'd lose
some people, but what would we gain?

Also, your premise is flawed. We (speaking generally) suck at supporting
more than one -stable branch. We *really* suck at supporting three. Six
months ago when the machinery was just beginning to spin up for
9.0-RELEASE I tried to get the PTB to reconsider. I was told that my
concerns were invalid because it was basically ready to go as is.

The plan I laid out at the time was to have no more than 2 stable
branches extant at any given time. Lengthen the periods where each
stable branch is supported, and terminate the oldest one when the newest
one is released.

> ... longer branch lifecycle? Same as above. None of the developers are
> going to reject bugfixes and backported drivers to a legacy, stable
> branch. We may be a bit against the idea of porting entire new
> subsystems to legacy, stable branches - but if there's a good enough
> reason _and_ it's been tested _and_ there's a need for it - _I_
> wouldn't say no.

But committers already fail to MFC *existing* bug fixes to stable
branches (even ones they generated). This is especially true for the
older branches. So how is the idea of users generating more new bug
fixes going to help?

What I'd like to see us do is to rethink what a "release" is. In
particular, I'd like to see us start to do more point releases (e.g.,
8.2.1) which involve only updates to the base, and don't involve the
whole ports and doc machinery. This would combine the current patch
releases done for security purposes. Ideally of course we'd have a
branch were known-good stuff was merged from the -stable branch, so an
8.2.1 wouldn't (necessarily) be what's in stable/8 at the time. However
I'm not sure we have the personnel for that, so even doing stable/8 ->
8.2.N would be an improvement over what we have.

One area where user involvement *would* be really welcome here is in the
area of regression testing. It would be much easier to cut a point
release if we had a series of regression tests, submitted by users so as
to reflect real world conditions, that we could run against the new
version. That way we could at least be sure that we didn't break
anything that current users of that branch are relying on.

Several people have mentioned 3x/year as a good release schedule, I
don't see any reason why we couldn't do point releases in that timescale.

The other thing I think has been missing (as several have pointed out in
this thread already) is any sort of planning for what should be in the
next release. The current time-based release schedule is (in large part)
a reaction to the problems we had in getting 5.0 out the door. However I
think the pendulum has swung *way* too far in the wrong direction, such
that we are now afraid to put *any* kind of plan in place for fear that
it will cause the release schedule to slip. Aside from the obvious folly
in that (lack of) plan, it fails to take into account the fact that the
release schedules already slip, often comically far out into the future,
and that the results are often worse than they would have been otherwise.

Meta-note, there is going to be a strong knee-jerk reaction to that last
paragraph to the effect that I'm attacking individuals who are involved
in the release process. I'm not. The *system* is deeply flawed, so the
heroic efforts of those doing their best to make that system work are in
vain. That's tragic for all concerned, including those who've given so
generously of their time and effort.

I tried to make the point back in June that there was no reason to cut
9.0-RELEASE yet because we don't have solid support for clang in either
the base, or ports (amongst several other reasons) and that the delay
for getting that working would be a great "excuse" for slipping the
support schedule for 8 so that we could release 9.0 not-too-long before
7 was about to go EOL, and make the 8/9/10 release schedules fit the
new, (hopefully) more rational model. Perhaps we can reconsider that
idea for 10.0.

Doug

--

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"


Gmane