Desktop Proposal

[Jesse Keating]

On Mon, 2009-10-12 at 13:26 -0500, Mike McGrath wrote:
> Once it's in rawhide, it'll end up in F12 no matter what we do.  Even if
> it was a mistake.  

That's not true.  A rollback + epoch can be done in cases where it is
deemed the "going backwards" will cause less harm than "trudging
forward".

> That's a separate issue from doing major updates in
> F-11.  Perhaps this whole need / niche market (wanting a stable desktop +
> a couple of selected updates from my suggested experimental repo) will
> disappear when rawhide isn't so messy.
> 
> But if I am concerned about quality, and if doing weird mashup repos that
> provide stable software for all and less stable software for those that
> want it isn't going to help.  What is?

If you're concerned about quality, we need to shift the desires of
packagers away from always having the latest software and into a more
conservative approach to our packaging, avoiding picking up beta
releases of software, or betas that aren't expected to go "final" before
we ship which ever distro we're working on at the time.  Adding more
repos for people to potentially push things, and more buildroot
confusion makes it /harder/ to test things, not easier.

> 
> > >
> > > Additionally stuff "working" in testing and being pushed to stable is the
> > > problem.  The firefox example is a good example of this as is the
> > > thunderbird update mentioned on fedora-devel.  Thunderbird should never
> > > have been pushed to F-11 under this proposal.  The new thunderbird would
> > > be released and updated in the experimental repo.  The old thunderbird
> > > would continue to get updates in F-11 proper.
> >
> > This makes a big set of assumptions.  A) the developer had foresight
> > enough to see late changing highly disruptive UI changes in the future
> > for the build.  B) The beta period for thunderbird would last beyond the
> > development period for Fedora 11.  C) the developer had foresight enough
> > to see that the older thunderbird code would remain usable and keep
> > getting bug fixes.  None of these is terribly good assumptions to make.
> >
> 
> But had we made them, it's possible the broken Firefox and newer
> thunderbird wouldn't be in F-11 right now and it would have provided a
> better experience for our users.  There are certainly problems with my
> proposal but I've not seen any alternatives.  Even if this suggestion
> wouldn't have done it, what would have?  We have no way to fix mistakes we
> make.

If we had them, what's to stop the maintainer from getting good feedback
on the experimental repo, and pushing it along to the stable repo, given
that it's the only upstream code getting work?

> 
> > In the particular thunderbird case, I think this whole mess would have
> > been avoided if the maintainer had simply patched the F11 build to
> > retain the previous UI defaults, while enabling the choice for
> > interested people to experiment with the new options.  The F12 (or F13
> > build by now) build would enable the new UI by default to match
> > upstream.  I really don't think we need to create a ton of extra repos
> > and logistics issues to avoid a maintainer having to think a little bit
> > about what it is they're updating and how it will effect users.
> >
> 
> In this particular thunderbird case and in all packages we have no
> procedure in place to determine what might be right, what might be wrong
> and how to fix mistakes.  I think there's a strong argument that
> thunderbird should not have been updated in F-11.  But we can't fault the
> packager because they were likely doing what they thought was best.  They
> had no direction on whether to update it or not.  And no options to bring
> an updated thunderbird to F-11 while leaving the old one alone. 

https://fedoraproject.org/wiki/Package_update_guidelines if followed,
would have gone a long way to prevent the thunderbird situation.  This
is a people/policy issue, not a technical issue.  In my opinion,
thunderbird /should/ have been updated, however it should have been
modified to retain the old UI style, as opposed to forcing the new UI on
all existing users.

You can most certainly bring a new thunderbird to updates-testing, and
just leave it there.  Those who want it can get it there.  Trying to
keep both a new thunderbird up to sync as well as continue to do bugfix
releases on the "old" thunderbird runs into a lot of problems though,
starting at the source control level.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20091012/7827d510/attachment.sig>