From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Release schedule for Core Update 165 and 166 Date: Tue, 15 Feb 2022 12:30:54 +0000 Message-ID: <15B6ADF4-1FD5-4F4A-B82B-F09606B56261@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4176729619147574759==" List-Id: --===============4176729619147574759== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Thanks Peter for this email. To give a little bit of context for those who have not been attending this mo= nth=E2=80=99s video conference: I would like to push out changes faster. That does not mean that we would gen= erally push for more patches in one update. It just means that we try to divi= de 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 whi= ch 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 beca= use 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 tak= e time will probably be shipped just as fast as they were before: when they a= re ready. I would like to test this a little bit and I would like to hear feedback if y= ou 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=C3=BCller wr= ote: >=20 > Hello development folks, >=20 > to make it more clear which patch goes into which release, at which point i= n time > a Core Update will be closed, and to ideally release stuff ready to go fast= er, 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 tha= t another > try. >=20 > Having extended the "merge window" phase to 14 days, this means: >=20 > - I will push my personal testing branch for Core Update 165 into "next" sh= ortly, > closing the "merge window" (in which I pick up patches from https://patchw= ork.ipfire.org/) > by the end of this week. >=20 > - Afterwards, Core Update 165 will go into the bugfixing phase for 20 days,= until > March 12nd. >=20 > - 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 work= ing on > Core Update 166. >=20 > 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 tak= e properly > care of it. >=20 > 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 anythin= g major > will (have to) be an exception to this schedule. Just let's see how it work= s this > time... :-) >=20 > As always, feel free to drop me a line in case of any questions/trouble/etc. >=20 > Also, it would be great if there could be some more people on this list rev= iewing patches; > some of the 203 patches currently tracked in https://patchwork.ipfire.org/p= roject/ipfire/list/ > have not been reviewed yet. >=20 > Thanks, and best regards, > Peter M=C3=BCller --===============4176729619147574759==--