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

Ian Clatworthy ian.clatworthy at canonical.com
Mon Mar 29 09:09:42 BST 2010


On 29/03/10 13:35, Martin Pool wrote:
> On 26 March 2010 21:47, Gary van der Merwe<garyvdm at gmail.com>  wrote:

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

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

>> So, some ideas on how we can fix this:
>>
>> * Look at ways that we can reduce our release cost. Any ideas ?

> I can sympathize with those feelings.

Me too. Having recently taken over bzr Windows packaging and put some 
effort into making the packaging there easier, recent weeks have 
certainly felt like wading through molasses vs adding features. :-(

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

Right. In the case of the Windows installers, I think having the 
different branches is the critical thing. For example, if I know QBzr 
0.18.x is what ships with bzr 2.1.x, then it's reasonably safe for me 
(as the packager) to grab the tip of that branch. It's nice to also have 
the particular release tagged but it isn't strictly necessary IMO.

So maybe we should worry less about formally packaging old releases of 
plugins, given that most Windows/Mac users of them receive them via 
installers?

Beyond that, +1 to us getting to the point where rolling out new 
releases is a "One-click" activity. If we can making releasing easy for 
bzr and it's plugins, then hopefully other LP projects can piggyback off 
whatever streamlining we can introduce.

Ian C.



More information about the bazaar mailing list