eta on 1.0.4
BJ Dierkes
---
derks
Andrew Garner
<wdie...@5dollarwhitebox.org> wrote:
> Hey all, just wanted to follow up on 1.0.4 and determine what we need to do in order to make a release.
I think we are ready for a release. We just need to retag 1.0.4
against HEAD. There have only been minor bugfixes to address some
last minute issues and a couple documentation bugs that Tim addressed,
I believe.
We probably should revisit how we tag/test releases, given that, at
least recently, only serious testing seems to occur once we've tagged
and inevitably some showstopper issue is found.
~Andy
Tim Soderstrom
Agreed. I wonder if we can enlist some help from Cloud or something to help us with an IUS model type of thing. Seems like the tests we actually run are never the ones that catch bugs :) An automated test suite will help considerably there but we still need to figure out a good test/release cycle.
BJ Dierkes
On Aug 3, 2010, at 11:18 AM, Tim Soderstrom wrote:
>
> On Aug 3, 2010, at 11:14 AM, Andrew Garner wrote:
>
>> On Tue, Aug 3, 2010 at 10:22 AM, BJ Dierkes
>> <wdie...@5dollarwhitebox.org> wrote:
>>> Hey all, just wanted to follow up on 1.0.4 and determine what we need to do in order to make a release.
>>
>> I think we are ready for a release. We just need to retag 1.0.4
>> against HEAD. There have only been minor bugfixes to address some
>> last minute issues and a couple documentation bugs that Tim addressed,
>> I believe.
>>
>> We probably should revisit how we tag/test releases, given that, at
>> least recently, only serious testing seems to occur once we've tagged
>> and inevitably some showstopper issue is found.
I agree. I think what we should have done is tagged 1.0.3 ... and continued with 1.0.3.1, 1.0.3.2, etc ... and once ready to push to production tag 1.0.4. Or rcX, rcY tags etc... We definitely want to and need to get to a point where when we tag a 'final' stable release version... that version should never be retagged because we should be doing all this testing and prep during the 'dev' release (1.0.3, 1.0.3.1, 1.0.3.2, etc)... or similar.
>
> Agreed. I wonder if we can enlist some help from Cloud or something to help us with an IUS model type of thing. Seems like the tests we actually run are never the ones that catch bugs :) An automated test suite will help considerably there but we still need to figure out a good test/release cycle.
>
I don't think we need to over complicate anything, I think we just need to standardize on something (anything) an get it in writing on the wiki. Hate to admit but handling 'milestones' in launchpad does clarify a lot of this stuff, and gets everyone on the same page about 'where we are' and what bugs need to be closed/etc before a final release. I think regular/scheduled release cycles are good so we might also consider that (2 week, 4 week?). Maybe every 3 weeks tag a dev version (for the purposes of packaging and testing packages)... prep during that week to iron out all testing and release procedures, and then tag the stable release the following week (monthy stable releases).
---
derks
Andrew Garner
Yeah, I agree on both counts. I think continuous dev releases and
reliable release schedules are a really important problems to fix. I
like the proposal of monthly releases. I don't think we have the
manpower to do this more frequently currently, at least for stable
releases.
I'm very amiable about moving our bug tracker to launchpad and
leveraging lp's other bits we don't have today to make this management
easier. It's probably better to make this switch sooner rather than
later.
~Andy
Tim Soderstrom
On Aug 3, 2010, at 3:38 PM, Andrew Garner wrote:
> I'm very amiable about moving our bug tracker to launchpad and
> leveraging lp's other bits we don't have today to make this management
> easier. It's probably better to make this switch sooner rather than
> later.
Andy and I talked about this. We could likely leave the repo on github.com and just move everything else (though I think LP does or will support GIT at some point?). I actually do not mind GITs tracker. It's a bit underfeatured but works mostly. What bugs me is Google Groups being confusing for non GMail addresses. I much prefer LP for list management. Plus the blueprints and things might be nice as well.
Perhaps we should get 1.0.4 out the door first and then figure out what to do before the next release? 1.0.4 should fix most of the outstanding bugs *crosses fingers* that should give us time to breathe and think about these things.
Long story short, I'm pretty indifferent too but I think LP has some benefits over GH by itself.