Updates Vision clarification / status

[Kevin Fenzi]

Greetings. 

FESCo has been working on trying to do some concrete implementation of
the Boards Updates Vision. See: 

https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
and
https://fedorahosted.org/fesco/ticket/382

Any feedback or help on those items would be welcome. Are we heading
the right way here? Sadly, we haven't made as much progress as I would
like, but hopefully we will have some more concrete stuff soon. 

Also, I would like to see a bit of (reasoned) discussion on one of the
statements in the Board's vision: 

"Stable releases should provide a consistent user experience throughout
the lifecycle, and only fix bugs and security issues"

I personally think this statement is too strict. (I know we could
provide for exceptions, but I think in general it's too strict). We
cannot force all the upstreams for all the projects Fedora packages to
match our release cycle, so I think we may be able to expand this to be
a bit more forgiving. 

Let me provide some examples: 

1. I (co)maintain the 'calibre' package. This is a ebook
converter/reader/book manager for devices, etc. Upstream releases a new
release about every week. (sometimes more often). These releases are a
mix of small new features or device support and bugfixes. See for
example: http://calibre-ebook.com/whats-new for a list of the latest
changes. Also, they note "Major new features". Under the above vision,
I could not update calibre in a stable release unless I backported all
the bugfixes only. Since I am already busy, it would mean I would
basically just leave a stable release on the version it shipped with. 
Users would only get those bugfixes or new features (including new
hardware support) in 6 months. People upgrading from Fedora N to Fedora
N+1 would get a version thats gone through ~30 releases since they last
saw an update. 

2. Another package I maintain, 'munin' mostly does bugfixes in it's
stable branch, but they do occasionally add new features into those.
Would I need to patch any new feature out? 

3. I don't maintain it, but... KDE. Their upstream doesn't release in a
way that's very compatible with Fedora. When version N+1 is released,
version N is eol and no longer gets updates. Backporting
bugfixes/security to N is not something our very good KDE sig has the
manpower for. So, it seems like updating to N+1 (even though it's not
just bugfixes/security) is the only option left. Granted this could be
a one time per stable release exception, but the above vision statement
doesn't allow for that kind of exception. 

I'm sure other folks could provide more examples. 

I'd like to propose modifying the statement somehow.
Perhaps something like: 

Stable releases should strive to provide a consistent user experience throughout
the lifecycle, focusing on bug and security fixes. 

Then, in implementing this fesco would be able to provide some
tests/guidelines for updates that are a bit more open than "ONLY
BUGFIX/SECURITY. DONE". We could ask people to look at a set of tests
like: "Does this update break ABI?" "Do any other packages depend on
this package? Or is it a leaf node?" "Does this upstream mix small
bugfixes and security updates in with new small features?" "Is the
current version still supported upstream?" etc. 

Thoughts?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100723/69e9afb8/attachment.bin