Proposal for the future of Fedora

[Tom "spot" Callaway]

On 08/23/2010 05:22 PM, Jesse Keating wrote:
> On 8/23/10 1:55 PM, Tom "spot" Callaway wrote:
>> I think part of this may simply be a need to set expectations appropriately.
> 
>> There is some irony in the fact that the most common questions I get
>> asked are "What is new in Fedora $CURRENT?" and "What is coming in
>> Fedora $CURRENT+1", and the most common complaint I hear is "Why did you
>> change $FOO in Fedora $CURRENT?!?".
> 
> When I get these questions they generally are of this long form:
> 
> What is new in Fedora 13 compared to Fedora 12 or older?
> 
> What is coming in Fedora 14 compared to Fedora 13 or older?
> 
> Why did you change the behavior of $FOO in Fedora 13 updates compared to
> Fedora 13 release?

For what it is worth, I don't usually get this level of granularity
here, although, it has happened before.

I certainly think that there are very few valid reasons to do a major
enhancement update in mid release, although, there are some. They should
be the exception, rather than the rule.

For example, one of my packages is R. The user community for R expects,
almost universally, to be able to have access to the most current
release of R shortly after it is available. They are usually willing to
test it in updates-testing, and the upstream maintainers have
established a reputation for well tested (upstream), stable releases
that ensure practical compatibility with R scripts and programs (and 9
times out of 10, R addon modules). When I waited to push a new R for a
new Fedora release, my inbox filled with unhappy Fedora users. Usually,
there is at least one new R release during every Fedora release cycle
(between Fedora VER and VER+1).

So, I push them as updates. Technically, they do fix bugs, but they're
closer to enhancements. R's target audience is narrower than other
Fedora packages though, so the impact of this is lessened. I'm not sure
how to quantify that into a broader rule though, but I would definitely
be interested in reading that from of anyone who could.

I continue to believe that, in the space of updates, the key problems are:

* The quality of released updates (and the general lack of community
testing of updates)
* The number of users affected by significant changes in updates

I do not think that the quantity of the updates is of itself a problem,
because if they were well tested, and did not cause significant change
to a majority of Fedora users, then the quantity would be irrelevant
(except perhaps from a bandwidth perspective).

The efforts around auto-QA are solid first steps towards improving
quality. I would welcome suggestions on improving updates QA and testing
(as long as they are respectful).

As to the number of users affected, I suspect it would be worthwhile to
try and setup some sort of anonymized tracking on the mirrors at the
package level to see how many packages they hand off to yum/PK for
installs on Fedora systems, understanding that it is not perfect, but
better than nothing.

IMHO, if a package is installed on a majority of Fedora systems, it
should be more strictly managed from an updates perspective (e.g.
critical path) than those packages with less impact. Not from a quality
perspective (all updates should just work), but there should be more
tolerance and understanding that they can do enhancement releases mid-cycle.

It is also my opinion that while packages like R qualify for that,
high-impact and high-visibility packages like GNOME and KDE do not, and
that we should build infrastructure to support mid-stream enhancement
package trees in separate repos, as opposed to the official updates, so
that the users who experience major change in those updates do so
willingly and consciously.

~spot