Update/install experience

[Paul W. Frields]

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

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