Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

[Kamil Paral]

----- "Jesse Keating" <jkeating at redhat.com> wrote:

> On Thu, 2010-03-11 at 12:21 -0600, Matt Domsch wrote:
> > Paul: Jesse Keating provided a draft policy for what updates should
> be
> > done.  Board will take this into consideration, if necessary, in
> > another round of discussions (not this meeting).
> 
> https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal
> 
> Here is the link.  I'm going to start a new thread here.
> 
> Feedback welcome.

Jesse, thank you very much for your proposal. I believe it is
an important piece to our Updates Policy puzzle.

Generally I really like the proposal. A few comments:

1. In order not to have to reference Fedora Audience in the
mailing list archive [1] all the time, I created a new wiki
page "Fedora Audience" with the relevant content [2]. It
seems to me this is too important to have it just in some
mailing list archive.

2. "Both users of the updates and maintainers of packages 
which might need to be rebuilt for your update."
I don't really understand this sentence, I suppose some
words are missing.

3. "Bugs which prevent software from working with external
data / service providers"
I'm very glad you provided this option in the proposal.
But maybe it would deserve a few examples. I understand
this like:
* Pidgin MSN support stopped working because of MSN protocol
change -> Pidgin may be updated.
* Samba didn't work for anonymous logins -> It may be
updated.
But I may be wrong, that's why a little clarification
would come handy. "External data" means exactly what?

4. Regular Data Updates
It should be specified whether the "regularity" of
update releases is also a requirement or not. Antivirus
definitions may be updated every week/day or so. OTOH
e.g. country codes definitions may be updated very 
irregularly, but still I would consider it part of
this category. Is regular release schedule also a
requirement?

5. Targeted Application Updates
Critical infrastructure packages should certainly
be more thoroughly defined. I suppose you intend to
do it in future.

6. New Upstream Versions
"For new upstream versions of packages which provide
new features, but don't just fix critical bugs, an 
update can still be issued, but it is vital that the
new upstream version does not regress or drastically
change a user's experience."
>From the sentence it is not clear if this category
can be used only for upstream versions that *fix
critical bugs AND provide new features*, or *just
provide new features*.
If the latter is the case, then I not quite
understand the purpose. You have carefully specified
several narrow categories for which updates may be
issued and now you just provide an extremely wide
category which can be used almost for any update. It
outclasses all aforementioned categories.


Regarding the proposal as a whole, I'm just afraid
if it does not dispute with the second requirement
of the Vision [3]:
"Stable releases should provide a consistent user 
experience throughout the lifecycle, and *only fix 
bugs and security issues*."

(Is the Vision already cast in stone?)

[1] https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html
[2] https://fedoraproject.org/wiki/Fedora_Audience
[3] https://fedoraproject.org/wiki/Stable_release_updates_vision#Vision_Statement

Kamil