On Wed, 2011-08-24 at 12:00 -0500, Steve Linabery wrote:
On Thu, Aug 18, 2011 at 11:58:43PM -0400, Mike Orazi wrote:
On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
<snip
At this point with the ongoing issues around bundler it's not clear to me that we are stable enough to cut a release. Based on conversations with jayg iiuc install is only working some of the time.
I am adding a 0.4.x branch to conductor git repo at current tip of master, but I'm not confident we're ready to tag that as an 0.4.0 release.
Comments/suggestions welcome!
s|e
I know I am late to this discussion, but I am wondering if we should really be having 'official' releases per sprint, as things tend to be rather unstable at that time. My proposal instead is this:
* Keep the current testing repo at or very close to 'bleeding edge' (could be 1 build per day or something). IOW, this should be pretty close to whatever is on master, and is what people can try out without having to build from source. As with building from source, this means there are going to be times when things do not work 100% as expected.
* At the end of each _Iteration_, do an official release, which we have spent $days/weeks testing and fixing bugs on w/o adding features. QE has tested this with a given set of dependencies (version of factory, iwhd, etc), and given it the green light.
I think this allows us the best of both strategies we have tried in the past. It both gives us a regular release schedule for official releases (with very frequent unofficial releases to testing), and also lets us make sure our official releases are not horribly broken (ie, they have actually been tested properly).
I suspect this will raise the ire of some, but its my idea and I sticking to it :)
Oh, and while I am ticking people off - why not have a 'stable-updates' or similar repo that always points to the latest official release? This would allow us to always point new users at the same url on our site (maybe less of an issue once f16 is out, but I think still valid, as we may have a new release that doesn't go into f16 or whatever fedora is current at that time). Seems like that would be an awful lot easier for a user to do an update than having to grab a whole new .repo file.
Ok, commence flame war!
-j