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:
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
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
* 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!