Schedule for releases

Bjoern A. Zeeb bzeeb-lists at
Mon Dec 27 15:02:08 UTC 2010

On Wed, 22 Dec 2010, Ulrich Spörlein wrote:


> I think this is the core "problem". Statistics[1] show, that most
> developers run some form of -CURRENT and
> [1] I just made this statistic up.

and I think you are just plain wrong here.  Seriously I would bet that
  >75% of the developers do not run some sort of head for their
day-to-day work.  They might use it for compile (and boot and maybe
sometimes even some more) testing, they might run it in a VM, or a lab
machine but not on their servers, not on their notebooks and not on
their desktops they work with daily (and neither would I expect most
consumers of FreeBSD unfortunately).

I am still not convinced that whatever development model people and
companies use (and I heard of in here) is better than to just devel
on HEAD and if it works there merge it and backport it to your release
branch for QA and shipping.
This might be a bit more work in the QA cycle but it saves you PYs on
updating branches every couple of years and in addition allows you to
start to cut a product from any branch {HEAD..your oldest} in theory
whenever you want rather than being unable to deliver for half a year
or a year.  Our naming scheme doesn't matter much in that case. You
lay your tags and start your branches yourself.

Can you do what you ask us to do?  Develop on HEAD and keep your own
stuff going all the way down to 8, 7 and 6?

In addition if you work on HEAD, you find problems as they occur and
not years later when developers have long moved on to other projects
and it's a pain for them to task swap back to whatever for a branch
that indeed is only barely supported anymore.

I know it won't help you with the backporting of new stuff like
drivers to kind of unsupported release branches the way you would like
to but the last paragraph applies there as well.  It might be a lot
easier when just done along initially.

Having fixed a bug of mine with one of the last 10 commits that
happened for RELENG_6, I know the pain.  I have also previously agreed
with people to not commit changes anymore for the sake that they'd
never get the testing they needed - those patches are avail though,
in GNATS, ...

I know that HEAD is broken once in a while but I think we got a lot
better than it sometimes used to be (and similar things apply to stable
branches).  I have cut images from stable branches in the past; I have
given up on that a while ago; I am actually only running HEAD these
days (home and production) for the sake of eating that dogfood but
also to get all the advantages. I do my own tweaks to it as well, like
you would do to your products but I try to keep them to a minimum like
I would expect you to as well.

I would love to hear from people who previously hit the pitfalls and
decided not to go with HEAD again. Why didn't you do it?  Do you
regret it?  Will you change "next time"?

We still lack the parts that would tell us something in the last week
or last 24 hours caused a regression that made my TCP/NFS/ZFS/UFS/<you
name it> n% slower.  Kris had been doing a good job in the past but as
time shows we need more people, different setups, ...

It's not only "compiles", "boots", but also the formerly in this thread
mentioned "works correctly" and in addition to that the "works well as
expected" or "works better than before" - hopefully;).

I think this is a community problem as well.  We need to have those
things show up like quarterly status reports, like nanog gets the
weekly CIDR reports, like there used to be "Internet monthly
reports" (or do they still exist?), like tinderbox emails come in, ...

If you do your daily/weekly/monthly regression tests for your
products you can catch that. If you run HEAD, you'll also catch it
timely to avoid binary searches of multiple quarters or years.
Some of you have the infrastructure and I can understand that you cannot
share (most of) it but you could run it on plain FreeBSD as well and
show us the reports?  Consider to do that regularly (it doesn't have to
be daily but maybe (bi-)weekly or monthly). "Budget" for it in terms of
infrastructure and employee time.  It'll probably save you time (and
with that money) in the end and help us to improve the solid
foundation you are building your products on.

My 0.4cts

Bjoern A. Zeeb                                 You have to have visions!
         <ks> Going to jail sucks -- <bz> All my daemons like it!

More information about the freebsd-arch mailing list