Updates proposal - alternative draft 1

[Michael Schwendt]

On Wed, 10 Mar 2010 02:47:45 +0530, Rahul wrote:

> On 03/10/2010 02:47 AM, Michael Schwendt wrote:
> >
> > On purpose. I didn't have any comments on them.
> >   
> 
> I assume then you don't have any criticism of the proposal since you can
> just assume the second part as a pointer to
> 
> http://fedoraproject.org/wiki/Package_update_guidelines

Well, with regard to your "critical path packages" draft, "no criticism"
would be an exaggeration.

I would prefer to see something in action first. Proof of concept.
A demonstration of how it improves update quality.  Everything could end
up as a farce due to lack of volunteers and/or lack of expertise. No
diligent testing done by humans, but just automated or semi-automated
tests done with tools. Or cursory "works for me" blanket approval of
updates, quickly submitted with a script to process a tiresome queue of
updates. With nobody taking responsibility for (1) the first annoying
problem that will slip through the cracks / (2) the first regression that
will be signed off nevertheless with excuses.

Other than that, I welcome top-down approaches. They are a much better
basis for discussion than those intimidating low-level proposals, where
various variables are inserted already and just wait to be filled in (such
as N weeks, N days, N karma points).

I'd like to see a rationale which mentions

 - the technical constraints (if any), which require an update to sit in
   updates-testing for a minimum time,
   e.g. so special tools can examine updates-testing, if they can
   not hook up in the process earlier,

 - the resource constraints, which require an update to sit in
   updates-testing for a minimum time,
   e.g. so N monkeys get enough time to hammer on the queue actually,
   considering the mirror delivery time, considering the time it may
   take to test something painstakingly on a daily basis,

 - the strategical/political constraints,
   e.g. the analysis of whether what we deliver is what we intend to deliver,
   a precise summary of whether and where Fedora Updates have failed in a
   way that requires policy changes [and confinement] for all/many updates.