critpath approval process seems rather broken

[Doug Ledford]

On Fri, 2011-04-08 at 21:28 -0500, Bruno Wolff III wrote:
> On Fri, Apr 08, 2011 at 20:43:05 -0400,
>   Will Woods <wwoods at redhat.com> wrote:
> > 
> > The only thing broken here is the expectation that testing doesn't
> > require your assistance, or isn't your problem.
> 
> Except this affects more than Tom. Some people aren't getting updates because
> of the misunderstanding and/or lack of resources that prevented this update
> from going out in a timely manner. This isn't the first time this kind of
> thing has been reported, particularly with a near end of life release.
> 
> I know there is stuff going on to develop test plans and the like, but it
> still is probably worth asking questions about how we could do things
> better.

You know, F14 went out the door with a *known broken* mdadm because
mdadm sat in updates-testing and didn't get critpath approval for almost
2 months.  And I put out a call for testers on this list when I filed
the update.  As a result, people would install F14 and then have broken
raid arrays on reboot or no raid array at all on reboot.  It was
*horribly* broken.  And the solution was sitting in updates-testing for
months.

And here we are, about to go down the same road again.  I have an update
in updates-testing, it's getting no love, and the package that's in the
release is *known broken*.  It has not been updated for systemd to begin
with.  Nor for tmpfs /var/run.  And just like last time, I put out a
call for testers on this mailing list.

But like I tried to explain after F14's fiasco, most people simply don't
have the knowledge and hardware to truly test mdadm.  No doubt mdadm is
an important boot time process and worthy of special testing so as to
not render a system unbootable, but I would argue that unless you have
testers with this knowledge, then you need to get your critpath process
out of my way and let me make the call on when to update this package.
There is an inherit logical failure in your system if your system puts
the decision making process in the hands of people that aren't
qualified/motivated to make the decision and takes it out of the hands
of the ones that are.

Now I'm seeing new bugs trickle in about mdadm in the live image, and I
have no clue if there is something I need to fix because I haven't
gotten my update pushed to stable yet so these people are running
against a known broken mdadm.  The fixed mdadm makes changes
specifically in the area this bug is about, but how am I supposed to
know if those changes will solve this specific issue when it can't be
tested!

Well, I'm heading out of town for two weeks and will be away from net
connectivity.  This release's mdadm is what it is and it ain't getting
any better.  And it would have been nice to have it get wider testing in
the last 10 days that it's been sitting in updates-testing so I would
know if there is any validity to this live image bug I've got now, but
too late for that.  Of course, it's still sitting in updates-testing,
and I'm not going to be around to push it on out.  At least I enabled
karma automatism this time.  Hopefully, F15 won't be screwed the way F14
was.

You know, I think you guys have this entire critpath thing totally
backwards.  You should *never* be keeping maintainers away from their
testers, but that's exactly what this process does.  People running
alphas and betas and release candidates *are* testers by definition.
You shouldn't be sequestering critpath updates away from the broadest
possible testing audience they can have, you should be pushing them
proactively and getting the broadest testing possible.  If I can get my
packages updated quickly, then at least I can proactively fix any
breakage that a new package causes.  If and only if a package fixes all
the known issues should you freeze it and require anything like this
critpath process.  But as long as the package in the alpha/beta is known
to still be broken, then get the hell out of the maintainer's way and
let us do our job.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110410/6b8d64a9/attachment.bin