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 Advisory Board

 
 
LinkBack Thread Tools
 
Old 12-16-2009, 05:16 PM
Josh Boyer
 
Default Update/install experience

On Wed, Dec 16, 2009 at 10:50:59AM -0700, Kevin Fenzi wrote:
>ok, so perhaps it's this planning that I am wondering about, and should
>ask on the test list.
>
>So, not sure if this is just a rephrasing of this proposal, but:
>
>- All updates need to spend time in updates-testing unless they are
> security related.

Sounds like exactly what EPEL does. I think enforcement is manual
there still, and that isn't going to scale to Fedora. The change
should be fairly minimal though.

>- All updates must have N karma to push to stable updates. Or some kind
> of checkoff for QA.

Code changes already have to be made for the similar critpath QA/releng
signoff. Hopefully this would just be another simple todo there.

>- updates-testing pushes are daily. stable updates pushes are weekly.

I could do this right now with no change to any code. It could also
be done independently of the rest of the above.

josh

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-16-2009, 07:45 PM
"Paul W. Frields"
 
Default Update/install experience

On Wed, Dec 16, 2009 at 10:50:59AM -0700, Kevin Fenzi wrote:
> On Wed, 16 Dec 2009 10:00:20 -0500
> "Paul W. Frields" <stickster@gmail.com> wrote:
>
> ...snip...
>
> > I would think it's more of both -- the latter in the short term, being
> > able to effectively test something after release day; and in the
> > longer term, the ability to grow a QA community as a result of more
> > discrete tasks available that can be accurately described, documented,
> > and picked up by willing contributors. Right now, once a release is
> > out the door, there's no effective way to test the stable release
> > midstream, and have that be meaningful for other people.
>
> Thats not entirely true... we do have updates-testing and bodhi karma.
> I run with updates-testing enabled here, and when I had a broken
> initramfs recently I tracked it down to a dracut update. I then added
> my -1 karma and it was the last one needed for it to be unpushed from
> updates-testing.

What I mean is, the meaningfulness is decreased with a constantly
moving package set. We absolutely do have resources for doing per
package (or even per-bunch in a couple cases) testing, but it's not
coordinated in an entire set from top to bottom. And there are
reasons for that, which come from the way we currently aim to provide
Rawhide and updates.

> > Problems in the help channels sometimes come down to users having to
> > run 'rpm -q <bunches_o'_stuff>' because when you ask "What Fedora are
> > you running?" the answer isn't all that helpful starting a few weeks
> > after release day. (Or maybe even the day after, for that matter.)
> > The first answer is, "Have you updated?" when there's no real answer
> > to whether that will actually help the situation, or might cause an
> > unrelated problem -- typically it's asked because the helper is using
> > latest updates, and this advice is the only way to make sure the user
> > is on the same set of software. I'm not saying that's not a sane
> > approach the way things are right now, and this is not a slam in any
> > way, shape, or form toward the intrepid folks who help users with
> > problems. They're doing the best they can based on the way our
> > releases and updates run right now.
>
> Yeah, but you will always have to ask that.
> I don't think having a '12.1' and '12.2' would help much... as people
> install stuff from testing, 3rd party repos, koji, or make their own.
> Just saying "I am updated to 12.2" won't really say they are on only
> the exact update set from 12.2.
>
> > But what if we did start offering a collection on a regular basis that
> > rolled in these updates? Reducing the multiplicity of updates and
> > resulting test matrices could make it possible for us to start
> > cataloging fixes and catching regressions before they impact users.
> > There'd be more certainty when helping a user as to what components
> > they actually had installed. Perhaps this wouldn't look like a
> > respin, so I'm purposely not calling it that.
>
> I don't know that it really helps out...
>
> > > How many problems or bugs are due to integration with other updates?
> > > In the cases of new package A using new package B, wouldn't you
> > > currently have to have both installed to test A anyhow?
> >
> > Which is, I think, one reason why we could, for the moment, step away
> > from thinking about packages and just consider components as the
> > original whiteboard suggested.
>
> ok. How do we define components then? "KDE" is a component?
>
> > Hopefully, having updates out on a more predictable, less frequent
> > basis would make it easier to break time off for security update
> > testing. It's not a matter of creating more time with a miracle, just
> > being able to better plan the teamwork. I can't speak for the QA
> > folks, but I would think that a constantly moving target (such as
> > daily updates to a stable release) makes it really difficult to
> > accurately plan in that way.
>
> ok, so perhaps it's this planning that I am wondering about, and should
> ask on the test list.
>
> So, not sure if this is just a rephrasing of this proposal, but:
>
> - All updates need to spend time in updates-testing unless they are
> security related.
>
> - All updates must have N karma to push to stable updates. Or some kind
> of checkoff for QA.
>
> - updates-testing pushes are daily. stable updates pushes are weekly.
>
> If thats the case, I think it would be a fine idea, I'm perhaps just
> getting confused on all the high level talk. Or is there more to it
> than this?

I think there is more to it -- again, I'd point back at the
whiteboard[1] that covers more than just additional testing time and a
more regulated pace of updates. I enjoyed reading this whiteboard and
hearing the presentation at FUDCon because it jibed with my desire for
Fedora to deliver a superior experience to anyone using it, including
both our core contributors and also people who are potential
contributors. After all, we have a lot more in common than not.


--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-16-2009, 08:14 PM
Mike McGrath
 
Default Update/install experience

On Wed, 16 Dec 2009, Josh Boyer wrote:

> On Wed, Dec 16, 2009 at 10:50:59AM -0700, Kevin Fenzi wrote:
> >ok, so perhaps it's this planning that I am wondering about, and should
> >ask on the test list.
> >
> >So, not sure if this is just a rephrasing of this proposal, but:
> >
> >- All updates need to spend time in updates-testing unless they are
> > security related.
>
> Sounds like exactly what EPEL does. I think enforcement is manual
> there still, and that isn't going to scale to Fedora. The change
> should be fairly minimal though.
>

Dennis can speak to this better then I can but as I understand it several
people try to go around the policies and go straight to stable
immediately, even after it's been explained to them. Bodhi itself doesn't
quite have that workflow built into it so I think at times dennis and the
packager have gotten into a "It's stable" "It's testing" "it's stable"
fight.

-Mike

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-16-2009, 11:50 PM
Paul Frields
 
Default Update/install experience

On Wed, Dec 16, 2009 at 4:14 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
>
> On Wed, 16 Dec 2009, Josh Boyer wrote:
>
>> On Wed, Dec 16, 2009 at 10:50:59AM -0700, Kevin Fenzi wrote:
>> >ok, so perhaps it's this planning that I am wondering about, and should
>> >ask on the test list.
>> >
>> >So, not sure if this is just a rephrasing of this proposal, but:
>> >
>> >- All updates need to spend time in updates-testing unless they are
>> > *security related.
>>
>> Sounds like exactly what EPEL does. *I think enforcement is manual
>> there still, and that isn't going to scale to Fedora. *The change
>> should be fairly minimal though.
>>
>
> Dennis can speak to this better then I can but as I understand it several
> people try to go around the policies and go straight to stable
> immediately, even after it's been explained to them. *Bodhi itself doesn't
> quite have that workflow built into it so I think at times dennis and the
> packager have gotten into a "It's stable" "It's testing" "it's stable"
> fight.

I actually did this once myself, inadvertently, because I didn't
understand the workflow (it was a new package). I guess technically it
wasn't a fight but more like a tug of war you don't realize you're in
at first. :-) But I think the discussion is getting away from the
topic a bit.

Paul

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-17-2009, 12:40 AM
Mike McGrath
 
Default Update/install experience

On Wed, 16 Dec 2009, Paul Frields wrote:

> On Wed, Dec 16, 2009 at 4:14 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> >
> > On Wed, 16 Dec 2009, Josh Boyer wrote:
> >
> >> On Wed, Dec 16, 2009 at 10:50:59AM -0700, Kevin Fenzi wrote:
> >> >ok, so perhaps it's this planning that I am wondering about, and should
> >> >ask on the test list.
> >> >
> >> >So, not sure if this is just a rephrasing of this proposal, but:
> >> >
> >> >- All updates need to spend time in updates-testing unless they are
> >> > *security related.
> >>
> >> Sounds like exactly what EPEL does. *I think enforcement is manual
> >> there still, and that isn't going to scale to Fedora. *The change
> >> should be fairly minimal though.
> >>
> >
> > Dennis can speak to this better then I can but as I understand it several
> > people try to go around the policies and go straight to stable
> > immediately, even after it's been explained to them. *Bodhi itself doesn't
> > quite have that workflow built into it so I think at times dennis and the
> > packager have gotten into a "It's stable" "It's testing" "it's stable"
> > fight.
>
> I actually did this once myself, inadvertently, because I didn't
> understand the workflow (it was a new package). I guess technically it
> wasn't a fight but more like a tug of war you don't realize you're in
> at first. :-) But I think the discussion is getting away from the
> topic a bit.
>

I agree but it does get to kind of a core of the problem, that's forming a
message about best practices around updates. I think in many ways that
starts at the packager and providing a proper framework for updates (I'm
thinking a level above bodhi where bodhi is the implementation layer of
that framework), then providing proper incentive to follow that framework.

That last one is especially tricky because the more rules we have and the
more complex we are about updates, the less volunteers will be apt to
follow the guidelines. Though putting some sort of guardian in the middle
might be welcome as it'd allow the packagers to not have to directly
follow the process. More "here's my update" kind of thing, then let QA,
releng, whoever else take it from there.

-Mike______________________________________________ _
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 10:22 AM.

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