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@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