From: Josef Bacik <jbacik@fb.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: GRUB release schedule?
Date: Tue, 8 Dec 2015 16:34:19 -0500 [thread overview]
Message-ID: <56674CDB.5000606@fb.com> (raw)
In-Reply-To: <20151208205556.GC5296@redhat.com>
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
next prev parent reply other threads:[~2015-12-08 21:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 18:22 GRUB release schedule? Peter Jones
2015-07-20 19:25 ` Vladimir 'phcoder' Serbinenko
2015-07-22 21:34 ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-07-29 19:01 ` Bruce Dubbs
2015-07-29 19:14 ` Vladimir 'phcoder' Serbinenko
2015-12-08 20:55 ` Peter Jones
2015-12-08 21:34 ` Josef Bacik [this message]
2015-07-24 4:20 ` Andrei Borzenkov
2015-07-24 8:03 ` Vladimir 'phcoder' Serbinenko
2015-07-24 10:59 ` Andrei Borzenkov
2015-08-21 16:56 ` Josef Bacik
2015-08-21 17:11 ` Konrad Rzeszutek Wilk
2015-08-21 17:18 ` Josef Bacik
2015-08-21 17:30 ` Konrad Rzeszutek Wilk
2015-08-21 17:57 ` Josef Bacik
2015-08-21 18:24 ` Andrei Borzenkov
2015-08-21 18:41 ` Konrad Rzeszutek Wilk
2015-08-21 19:55 ` Bruce Dubbs
2015-08-22 5:19 ` Andrei Borzenkov
2015-08-22 5:16 ` Andrei Borzenkov
2015-08-24 18:20 ` Konrad Rzeszutek Wilk
-- strict thread matches above, loose matches on Subject: below --
2020-10-25 16:59 Bruce Dubbs
2020-10-26 14:27 ` Daniel Kiper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56674CDB.5000606@fb.com \
--to=jbacik@fb.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.