[qbzr] qbzr 0.19b1 late - sorry [RFC] Release cadence balance wrong?

[Martin Pool]

On 26 March 2010 21:47, Gary van der Merwe <garyvdm at gmail.com> wrote:
> I was meant to have done the 0.19b1 release yesterday, but I didn't
> because I was deving cool bug fixes and features. I'm sorry it's late.
> I'm sure I will get it out before the end of this weekend.
>
> I've been thinking about it today; and I feel that we don't have the
> correct balance between time doing development and time doing release
> related tasks.
>
> I guess I'm feeling this way because:
>
> * I spent alot of time updating the ppas for bzr 2.1 and all plugins in
> the ppa. This took about 2 weeks of my "can spend on bzr time available
> time". Maybe this was misspent time. But ppas are the easiest way to get
> the software out to ubuntu users.
>
> * bzr is synchronizing it's releases with ubuntu. 2.0 was late, and so
> 2.1 had to play catch up, and so felt shortened.
>
> * Maintaining a stable branch has increased our release costs.
>
> * A serious bug in the treewidget that took a long time isolate, and
> fix, put off other more interesting work.
>
> Now those things are out of the way, I've just gotten into the zone with
> some interesting work, but I have to stop that, and do a release.
>
> Maybe all of these contributing factors are abnormal, and there isn't
> really a problem. I don't know.
>
> So, some ideas on how we can fix this:
>
> * Look at ways that we can reduce our release cost. Any ideas ?
> * May be release less frequently during the beta phases, but with the
> same frequency during the rc and final phases. I would like for qbzr
> release to stay insync with bzr releases, so this would need buy in from
> bzr.

I can sympathize with those feelings.

I think having an identified stable branch for each plugin that goes
with a particular release is a good idea: if a critical bugfix does
come up, we have a place to put it.  (Obviously you can branch off
after the fact but I think defining it ahead of time may avoid
confusion.)

That doesn't mean you have to do a lot of work on the stable branch,
or make releases often.  If you decided that say only high priority
bugs will be fixed there, or you will only release when a critical bug
is fixed that may help.

2.1 was pretty much the right time wrt Ubuntu, so 2.1-2.2 should be
just about exactly six months.

What kind of buy-in would be needed from bzr?  We could certainly ship
the same version of qbzr with both bzr 2.2b1 and 2.2b2 if you didn't
want to do a release in the second month.

At the moment based on the blogpost feedback I'm thinking we should
support stable bzrs for 18 months, but perhaps with bugfix updates
only at 2-3 month intervals.

-- 
Martin <http://launchpad.net/~mbp/>