On 23 June 2011 23:48, David W. Hodgins <davidwhodg...@gmail.com> wrote: > On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3...@gmail.com> > wrote: > >> On 23 June 2011 07:58, Dexter Morgan <dmorga...@gmail.com> wrote: > >>> yes it needs to go to backports_testing before iirc > >> Got a link to a thread on -dev ML / irc meeting log / <insert your >> favourite communication method here>, where this was decided? > > This mailing list, thread "Release cycles proposals, and discussion", > messageid BANLkTimrPR-=ugqonfvakqpft80lni9...@mail.gmail.com > > Where Anne posted ... > >> exactly what I had in mind. Having backports can allow choice between >> "the last version of" and "the stable version with which I'm happy >> with". But indeed we need more quality in backport rpms that is policy >> and tests. > > In order for the qa team to perform the tests, before they go to the > backports repository, they have to go to to the testing repository > first. >
1) It doesn't say "we're going to use backports_testing", does it? guessing != an instated policy 2) IMHO, QA is too small to handle backports too > Something that works in cauldron may not work when moved to backports, > if a dependency is missed. By using backports_testing, we can catch > that before it hits the average user. > > Regards, Dave Hodgins > Right so, the plan is: - A packager submits to backports_testing and assigns to QA - QA tests, the package is good to go - The report is assigned to <whoever has privileges to move packages from backports_testing to backports>, atm that's sysadm team - Package is moved and the report closed Caveats: - QA is too small, and it'll take time/effort to get through the backported packages requiring tests, unless you depend on the user asking for the backport to have tested the package properly, the user will say it works if it works on his box for the arch he's using, he won't do both archs, not just because he's lazy, but maybe he has one Mageia box for example - Sysadm team is already overworked with many other tasks, meaning the packages requiring a move will rot for a while in backports_testing. Now compare that to what's used in e.g. mdv: - User asks for a backport - Packager submits the backport and closes the report Do you see the problem I am talking about yet? adding more complexity to backporting may result in less backports; the more the hoops, the less the backports, the more the users' complaints about I-want-the-latest-version-of-foo-yesterday. The "quality of backports" is a sentence that lacks statistics and numbers; in e.g. mdv, how many packages were backported to release foo? how many of them worked(tm)? how many of them didn't work and required a bit of fixing? how many of them didn't work and won't work due to any number of reasons? I think backports in mdv worked pretty well all those years, not all of them worked, but most of them did. -- Ahmad Samir