From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Release schedule for Core Update 165 and 166
Date: Tue, 15 Feb 2022 12:30:54 +0000 [thread overview]
Message-ID: <15B6ADF4-1FD5-4F4A-B82B-F09606B56261@ipfire.org> (raw)
In-Reply-To: <bcbbdb75-82da-cb6e-97f5-5b1b732f8888@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]
Hello,
Thanks Peter for this email.
To give a little bit of context for those who have not been attending this month’s video conference:
I would like to push out changes faster. That does not mean that we would generally push for more patches in one update. It just means that we try to divide them better into two categories:
* There are often trivial changes that are easily tested and therefore often well-tested. Those can be released sooner. We also have larger patch sets which have been tested and reviewed and from that point are ready for a release.
* Then we have patches where testing is required and that might be difficult (because not many people have the right piece of hardware for example). Those should not hold back any patches that fall into the category above just because they happened to be submitted to the list at the same time.
I personally find it absolutely acceptable to defer those changes to a later update if they are not ready, yet, but push out what is actually ready. That way, we will be able to ship some things sooner, but the things that will take time will probably be shipped just as fast as they were before: when they are ready.
I would like to test this a little bit and I would like to hear feedback if you think that this made a positive or negative difference, or even if it did not matter to you at all :)
All the best,
-Michael
> On 14 Feb 2022, at 19:27, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>
> Hello development folks,
>
> to make it more clear which patch goes into which release, at which point in time
> a Core Update will be closed, and to ideally release stuff ready to go faster, Michael
> and myself just had a phone call over the IPFire 2.x release schedule (see:
> https://wiki.ipfire.org/devel/release-schedule), and we decided to give that another
> try.
>
> Having extended the "merge window" phase to 14 days, this means:
>
> - I will push my personal testing branch for Core Update 165 into "next" shortly,
> closing the "merge window" (in which I pick up patches from https://patchwork.ipfire.org/)
> by the end of this week.
>
> - Afterwards, Core Update 165 will go into the bugfixing phase for 20 days, until
> March 12nd.
>
> - It will then be released for the public testing phase for 10 days, being released
> as stable at approximately March 22nd. At the same time, I will start working on
> Core Update 166.
>
> For personal reasons, I currently lack oversight over my available for the project
> in March, and will assign Core Update 166 to somebody else if I cannot take properly
> care of it.
>
> While this sounds a bit rush and complex (to myself as well), I think it is worth
> a try. After all, I consider these dates being rough deadlines, and anything major
> will (have to) be an exception to this schedule. Just let's see how it works this
> time... :-)
>
> As always, feel free to drop me a line in case of any questions/trouble/etc.
>
> Also, it would be great if there could be some more people on this list reviewing patches;
> some of the 203 patches currently tracked in https://patchwork.ipfire.org/project/ipfire/list/
> have not been reviewed yet.
>
> Thanks, and best regards,
> Peter Müller
next prev parent reply other threads:[~2022-02-15 12:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 19:27 Peter Müller
2022-02-14 21:43 ` Adolf Belka
2022-02-15 12:30 ` Michael Tremer [this message]
2022-02-23 17:07 ` Peter Müller
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=15B6ADF4-1FD5-4F4A-B82B-F09606B56261@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox