On 1/17/12 3:50 PM, Doug Barton wrote:
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.
"leadership" doesn't really control development here. action does.
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?
careful, you are starting to sound reasonable there..
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.
that's another 'man hours' problem (branched ports)
... 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.
I certainly think 9.0 was premature.. 8.x just started.. this should
have been 8.3.
... 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?
usually it's because they just forgot..
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
