Fedora 13 Release Candidate Phase

Bernie Innocenti bernie at codewiz.org
Thu May 13 13:53:19 UTC 2010


El Wed, 12-05-2010 a las 15:59 -0500, Bruno Wolff III escribió:
> On Thu, May 13, 2010 at 02:23:38 +0530,
>   Rahul Sundaram <metherid at gmail.com> wrote:
> > On 05/13/2010 02:22 AM, Bruno Wolff III wrote:
> > > I don't see that pulling in the games is a good idea. The release process is
> > > that only blockers should be pulled in right now, though that is being
> > > bent a little. There should be some clarification done in that regard for
> > > the next release, but there is no way these game updates are in that category.
> > > While the risk that they would break other things seems very low, I don't
> > > think starting out with a smaller updates repository at this point is worth
> > > taking the risk. I might be convinced otherwise for a large package that
> > > was on the default install as that could result in significant bandwidth
> > > savings. But I don't think that applies to wesnoth or openarena.
> > >   
> > 
> > Well then, why do I hear people complain about it?
> 
> I think because they see the size of updates as important and the risk of
> something breaking as being very low. Also the rules for including new
> packages are being bent for some packages, which makes one think they can
> be bent for other packages.

Ironically, the OpenArena update *does* indeed break something:

 bernie at giskard:~$ openarena
 [...]
 Sound initialization successful.
 --------------------------------
 Loading vm file vm/ui.qvm...
 ...which has vmMagic VM_MAGIC_VER2
 Loading 1550 jump table targets
 total 0, hsize 1021, zero 1021, min 0, max 0
 Segmentation fault (core dumped)


I gave a -1 to this update a few days ago, but it's been ignored:

 https://admin.fedoraproject.org/updates/openarena-0.8.5-1.fc13


Whether a broken update comes before, after or during a freeze does not
significantly change the overall distro quality perceived by users.

What we really need, imho, is a better QC process between packagers and
stable updates. Bodhi was supposed to implement such process, but in
fact it's mostly useless because there's no incentive for testers to go
there and report about their experience with a package installed from
updates-testing.

One reason why I myself neglect to give karma points to updates is that
it's hard to remember which packages were installed from
updates-testing. Perhaps yum and gpk-application could remind you to do
it. Even better, the abrt applet could popup after one day from
installing an update to let you file a comment in Bodhi easily without
going through the web interface.


> I don't think the complaints are unreasonable. I think the answer should still
> be no. The process should be explained as well as at least a general rational
> for other exceptions granted this go around. And for the future the process
> should be more closely followed and the process documentation updated if there
> are reasons we will take updates for packages other than to fix blockers after
> the RC process has started.

I think we could take any package at any time, after a sufficient amount
of testing has been done on it. If we want to raise the quality bar
between RC and release, we may simply require more karma points to push
an update to stable.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



More information about the devel mailing list