Hi Doug,
On Wed, 18 Jan 2012, Doug Barton wrote:
On 01/18/2012 11:46, John Kozubik wrote:
- mark 9 as the _only_ production release
While I understand your motivation, I am not sure this is a workable
goal when combined with the goal that others have expressed of longer
timelines for the support of a given branch. Speaking from personal
experience, once a service is released on a given platform the costs of
migration can be significant. And if what I have is working well and
only needs the occasional bug/security fix my motivations for migration
are near zero. So the tradeoffs then become more frequent major releases
to get new features, vs. longer support for a given release branch.
Agreed. What I am saying is that that "dial" is currently set
incorrectly. I think we should sacrifice new features for longer lived
releases.
My own experience has been that all of the new features I have benefited
from did not start being useful until several releases past their
introduction. For instance, one or more new releases has been, at least
partly, justified by ZFS ... and yet it is only now with 8.3 that I'm even
beginning to think of deploying. The same is true with the excellent SMP
code we all now enjoy - it took until 6 to be usable.
That would suggest that the end users don't really lose on features by
delaying the new releases, since those features typically aren't ready
anyway.
Let's take 5 years as a reasonable time period for supporting a branch.
Waiting that long between major releases would significantly stifle the
ability to add new features that require breaks to the [AK][BP]I. It
would also inhibit our ability to do revolutionary architectural changes
such as moving to clang as the primary supported compiler.
I agree. Those are costs I am willing to pay, and I think the response to
this thread shows that a lot of other folks would prefer that cost/benefit
setting to the current one.
What I've proposed instead is a new major release every 2 1/2 years,
where the new release coincides with the EOL of the oldest production
release. That way we have a 5-year cycle of support for each major
branch, and no more than 2 production branches extant at one time.
I think that at first glance, 2.5 or 3 years sounds completely reasonable.
That's a long time, right ? The problem is, nobody uses x.0 (maybe that's
rational and maybe not, but it's a fact) so subtract 6 months there, and
then if the project is even readying the next major, they're going to
detach focus about 6 months prior, so subtract 6 months there ... the next
thing you know I'm back where I am right now: getting *maybe* 1.5 total
years of *real* lifecycle out of a major release.
And since that's my major complaint, I have to disagree. And that is why
I am advocating a 5 year lifespan, with at least 4 of those years being
totally focused - no other "production" releases.
History tells us that 2 production branches is a goal we can achieve,
with the focus shifting more heavily towards only bug/security fixes in
the oldest branch after the new production release branch is cut. If we
combine that with the ideas that are being put forward about teams that
"own" a production branch, and a more frequent stripped-down release
process, I think this is a very workable model.
Well, the top of my priority list is occupied with longer lived releases,
so if we get that, and we're still maintaining two production releases,
it's still a big win for me.
But in the bigger picture I think having two production releases
simultaneously, while possible, is a bad idea. You have to optimize for
something, and in practice I think both lose out. This isn't a FreeBSD
issue, it's a classical resources issue.
There's a reason that part of this thread got hijacked with complaints
about the PR process, and that has to do with PRs getting submitted and
devs deciding which production release to plug them into, etc. That's
just one of many symptoms of that lack of focus.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
