Desktop Proposal

[Mike McGrath]

On Mon, 12 Oct 2009, Jesse Keating wrote:

> On Mon, 2009-10-12 at 10:42 -0500, Mike McGrath wrote:
> > This is not what updates testing is for.  Stuff in updates testing for F11
> > is for packages that are, ultimately, destined for F-11.  The experimental
> > repo for F-11 would be for packages that are destined for F-12 if at all.
>
> Isn't that what rawhide is for?  If you're on F11, but want to test
> experimental stuff, well install it from rawhide.  You'll get to keep
> all the pieces.  If we're concerned about quality, I really don't think
> adding some weird mashup repos to the mix is going to help that at all.
> The more repos you throw out there, the more complex an environment may
> be and the complexity of the test matrix exponentially increases.
>

Once it's in rawhide, it'll end up in F12 no matter what we do.  Even if
it was a mistake.  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?

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

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

	-Mike