FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-09-2011, 01:55 AM
Adam Williamson
 
Default critpath approval process seems rather broken

On Fri, 2011-04-08 at 20:43 -0400, Will Woods wrote:

> The only thing broken here is the expectation that testing doesn't
> require your assistance, or isn't your problem.

Well, F13 does tend to get pretty backed up; few people are running it
any more. I boot a virt instance of it and do a fedora-easy-karma run
every so often, but that's only every month or so, and I can't upkarma
*every* update because some I don't have an appropriate setup to test
(though this one I would do next time I get to doing an F13 run). I
think we've kicked around a few ideas for dealing with this problem with
the 'current minus one' release, but nothing definite has come of it
yet.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 02:28 AM
Bruno Wolff III
 
Default critpath approval process seems rather broken

On Fri, Apr 08, 2011 at 20:43:05 -0400,
Will Woods <wwoods@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 03:32 AM
Kevin Kofler
 
Default critpath approval process seems rather broken

Will Woods wrote:
> In fact, there's plenty of approvers available, but you're not engaging
> with them. They might not know how to test libtiff, or what needs
> testing, so other stuff gets tested first.

The fact is, this is a SECURITY UPDATE and as such it should go out even
without testing. It's not acceptable to sit on security updates for weeks.
And it's just a FACT that Fedora n-1 gets near-zero testing.

> The solution is simple: ASK FOR HELP.

The solution is simple: The red tape on update pushing needs to be repealed.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 03:38 AM
Kevin Fenzi
 
Default critpath approval process seems rather broken

Related to this, fesco wanted to look at some changes for security
updates for stable releases:

https://fedorahosted.org/bodhi/ticket/581

Hopefully something like this would help the above case.

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 10:57 AM
Tomasz Torcz
 
Default critpath approval process seems rather broken

On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
> Will Woods wrote:
> > In fact, there's plenty of approvers available, but you're not engaging
> > with them. They might not know how to test libtiff, or what needs
> > testing, so other stuff gets tested first.
>
> The fact is, this is a SECURITY UPDATE and as such it should go out even
> without testing. It's not acceptable to sit on security updates for weeks.

No, security updates are not _that_ special. For example, there's
an avahi update in pipeline. It has broken dependencies. Pushing this
would broke some systems. I'm talking about:
https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14

--
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzichubg@chrome.pl "God is more forgiving."

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 11:07 AM
Kevin Kofler
 
Default critpath approval process seems rather broken

Kevin Fenzi wrote:
> Related to this, fesco wanted to look at some changes for security
> updates for stable releases:
>
> https://fedorahosted.org/bodhi/ticket/581
>
> Hopefully something like this would help the above case.

While I welcome those changes, I don't understand why we need to make the
update rules to be enforced by Bodhi more and more complicated (and in fact,
too complicated for Bodhi to implement correctly, there are already several
corner cases in which the implementation in Bodhi differs from what FESCo
requested) when we could just ask maintainers for a bit of common sense and
do without any software enforcement.

As you're seeing from all those proposals being floated for various special
cases, there are many factors to consider in the tradeoff between getting
important fixes out quickly and getting changes tested. I think there's a
lot to gain from being flexible. No hardcoded policy will do the right thing
in all cases. This thread is just one of the many cases where it goes wrong.

Homo sapiens sapiens has an organ called the "brain", which is very
effective at making decisions. We have many of those available, one per
maintainer. Why not use this processing power for decision making?

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2011, 11:31 AM
drago01
 
Default critpath approval process seems rather broken

On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz <tomek@pipebreaker.pl> wrote:
> On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
>> Will Woods wrote:
>> > In fact, there's plenty of approvers available, but you're not engaging
>> > with them. They might not know how to test libtiff, or what needs
>> > testing, so other stuff gets tested first.
>>
>> The fact is, this is a SECURITY UPDATE and as such it should go out even
>> without testing. It's not acceptable to sit on security updates for weeks.
>
> *No, security updates are not _that_ special. *For example, there's
> an avahi update in pipeline. *It has broken dependencies. *Pushing this
> would broke some systems. I'm talking about:
> https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14

Packages with broken dependencies should just be unpushable (autoqa
was supposed to fix this but not sure what happend to it ...)

We really should do an automated dep check before pushing updates (and
reject those with broken deps).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-10-2011, 05:11 AM
Adam Williamson
 
Default critpath approval process seems rather broken

On Sat, 2011-04-09 at 13:31 +0200, drago01 wrote:
> On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz <tomek@pipebreaker.pl> wrote:
> > On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
> >> Will Woods wrote:
> >> > In fact, there's plenty of approvers available, but you're not engaging
> >> > with them. They might not know how to test libtiff, or what needs
> >> > testing, so other stuff gets tested first.
> >>
> >> The fact is, this is a SECURITY UPDATE and as such it should go out even
> >> without testing. It's not acceptable to sit on security updates for weeks.
> >
> > No, security updates are not _that_ special. For example, there's
> > an avahi update in pipeline. It has broken dependencies. Pushing this
> > would broke some systems. I'm talking about:
> > https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
>
> Packages with broken dependencies should just be unpushable (autoqa
> was supposed to fix this but not sure what happend to it ...)
>
> We really should do an automated dep check before pushing updates (and
> reject those with broken deps).

autoqa is doing this since recently, but only as an advisory check until
we make sure it's running smoothly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-10-2011, 06:41 AM
TASAKA Mamoru
 
Default critpath approval process seems rather broken

Tomasz Torcz wrote, at 04/09/2011 07:57 PM +9:00:
> On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
>> Will Woods wrote:
>>> In fact, there's plenty of approvers available, but you're not engaging
>>> with them. They might not know how to test libtiff, or what needs
>>> testing, so other stuff gets tested first.
>>
>> The fact is, this is a SECURITY UPDATE and as such it should go out even
>> without testing. It's not acceptable to sit on security updates for weeks.
>
> No, security updates are not _that_ special. For example, there's
> an avahi update in pipeline. It has broken dependencies. Pushing this
> would broke some systems. I'm talking about:
> https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
>

So as a result we are just leaving this security issue unresolved
more than one month? Okay, it is all very well that we try to explain
why the new updates request is not yet pushed, however then people
would ask, "so why can't Fedora try to fix such issue like broken
dependency ASAP? Short of man power? Is Fedora just making light
of security issues?"

Who is responsible for this issue?

Regards,
Mamoru


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-10-2011, 04:45 PM
Doug Ledford
 
Default critpath approval process seems rather broken

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@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@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org