----- "Jesse Keating" jkeating@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.... [2] https://fedoraproject.org/wiki/Fedora_Audience [3] https://fedoraproject.org/wiki/Stable_release_updates_vision#Vision_Statemen...

Kamil