---------- Message transféré ---------- De : "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com> Date : 4 janv. 2016 10:40 PM Objet : RE: GRUB release schedule? À : "Elliott, Robert (Persistent Memory)" <elli...@hpe.com> 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)" < elli...@hpe.com> 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=hp....@gnu.org [mailto: > grub-devel-bounces+elliott=hp....@gnu.org] On Behalf Of Josef Bacik > Sent: Tuesday, December 08, 2015 3:34 PM > To: The development of GNU GRUB <grub-devel@gnu.org> > 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
