---------- 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.
Thanks,
Josef
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel