[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: RE: GRUB release schedule?

From: Vladimir 'phcoder' Serbinenko
Subject: Fwd: RE: GRUB release schedule?
Date: Mon, 4 Jan 2016 22:40:35 +0100

---------- Message transféré ----------
De : "Vladimir 'phcoder' Serbinenko" <address@hidden>
Date : 4 janv. 2016 10:40 PM
Objet : RE: GRUB release schedule?
À : "Elliott, Robert (Persistent Memory)" <address@hidden>
Cc :

I'm currently running tests in order to make next beta. I see quite some failures and try to sort them out

Le 4 janv. 2016 10:38 PM, "Elliott, Robert (Persistent Memory)" <address@hidden> a écrit :
Any thoughts on this request (and my requests for a 4.3 tag to
signify that NVDIMM fixes are in place)?

-----Original Message-----
From: grub-devel-bounces+elliott=address@hidden [mailto:grub-devel-bounces+elliott=address@hidden] On Behalf Of Josef Bacik
Sent: Tuesday, December 08, 2015 3:34 PM
To: The development of GNU GRUB <address@hidden>
Subject: Re: GRUB release schedule?

On 12/08/2015 03:55 PM, Peter Jones wrote:
> On Mon, Jul 20, 2015 at 09:25:56PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> I'll do next beta tomorrow and will assess current open bugs to see how far
>> we're from release
> Did this ever happen?  It doesn't appear as though it did.
> So I'm back with my original question: What's the path to regular
> releases?  I don't honestly believe we have to fix everything about
> source control, patch contribution, and test suites to do that, though
> those are all important things.  Plenty of projects do releases with the
> same tools this one has, with great success.  But this is one more case
> where the search for perfection is stopping us from having any releases
> *at all*.
> "Fix everything in the code *and* the infrastructure and then do a
> release" is not workable.  We need to have regular releases, and we need
> to make improvements to the project's infrastructure and processes be a
> part of those releases.  Waiting for a flag day with each thing to be
> improved just means delaying indefinitely, especially if the wish list
> includes things nobody is actively working on.
> So that means we need two things: 1) decide on a schedule for one release,
> 2) decide when the ones after it will be.
> Here's a suggestion: Schedule a release at the end of January, and work
> towards that.  It doesn't have to be perfect; everybody is shipping
> something based on the current tree already anyway.  Then plan on
> another release at the end of July, and follow that plan indefinitely.
> It's okay if there are reasons to adjust it sometimes, but let's start
> with a plan.
> Thoughts?

I'd like to second this.  ATM we're just running whatever is in my
github copy of grub2, which I rebase whenever somebody tells me to.  If
we have consistent releases then it'll make it easier for me to run
automated tests internally as well as have clear indicators when I need
to rebase and figure out what outstanding patches I still have pending.


Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]