[Mageia-dev] Firefox 5

[Michael Scherer]

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