Update/install experience

[Kevin Fenzi]

On Wed, 16 Dec 2009 10:00:20 -0500
"Paul W. Frields" <stickster at 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. 

> 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?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20091216/8f59826f/attachment.sig>