Schedule for releases

[John Baldwin]

On Monday, December 27, 2010 9:47:32 am Bjoern A. Zeeb wrote:
> On Wed, 22 Dec 2010, Ulrich Spörlein wrote:
> 
> Hi,
> 
> > 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.

Sadly, I need to actually ship the development I do that is work-related, so I 
do it on stable first and then forward port it to HEAD afterward.  Other 
changes that are not work-centric (e.g. PCI hacking) I do on HEAD directly.  
However, for tasks specific to what work needs, that model does not work.

One key reason it does not work is that many bugs only show up in production.  
This was true for me at Y! as well as my current job.  And we are _not_ going 
to run HEAD in production.  I simply can't sell that.  So that means that when 
we do encounter various bugs, we have to debug and fix them on the -stable we 
currently use and later forward port to HEAD.

> 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.

This does not work for bugs that only show up under production load (which is 
most of them).

> 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.

It can be a lot of work to maintain support for compiling on multiple 
platforms that companies may not (I know some of them definitely will not) 
want to invest extra time in.

> 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?

In many cases if a company has local changes to FreeBSD, their software is 
heavily tied to those local modifications and will not run on stock FreeBSD.

> 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.

I think this is an area of give and take though.  Some companies already 
budget time in that they employ committers and allow them to work on FreeBSD 
stuff that isn't strictly work-related part-time and merge things upstream to 
HEAD when possible.  Is it too much to ask that the Project make that path a 
bit easier by making stable branches longer?

There are some recent examples of companies funding work to go into HEAD first 
that they plan to use a backport of (NFSLOCKD, the NFS server GSSAPI support, 
SU+J, and infiband), so this model can certainly work.  It probably also works 
best for upstreamable new features which tend to be some of the largest diffs 
where the features can be tested independently of a company's proprietary 
software stack.

-- 
John Baldwin