[Mageia-dev] Firefox 5

[Ahmad Samir]

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.

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