[Mageia-dev] Firefox 5

Fri Jun 24 02:04:46 CEST 2011

Le vendredi 24 juin 2011 à 01:17 +0300, Ahmad Samir a écrit :
+> On 23 June 2011 23:48, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> > On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com>
+> > wrote:
+> >
+> >> On 23 June 2011 07:58, Dexter Morgan <dmorganec at 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-=UgQOnfvAkqPft80LNi9seQ at 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.
+
+Then we should have a way to turn complaint into productive behavior,
+like "asking to people to do QA of package they request the backport
+for".
+
+> 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.
+
+And everybody said "do not use backport, they are not supported, and
+they can eat your cat if you use them".
+
+As said in the meeting, I wanted to send a proposal later for that, but
+you shooted first, so let's start.
+
+Your points are valid, and I took them in account in the proposal, who
+is based on previous years feedback, based on Stormi ideas mainly, and
+on your points. 
+
+So I will open 3 separate thread, to answer to the 3 questions I see :
+- what process for backports
+- what policy for backports
+- what about updates of backports
+
+Using 3 mails, I hope to have a more manageable discussion that having a
+big one.
+
+-- 
+Michael Scherer
+
+