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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
