Updates Vision clarification / status

[Mike McGrath]

On Fri, 23 Jul 2010, Kevin Fenzi wrote:

> 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.
>

<not a board member but commenting anyway>

To me the quote above is a goal, not a rule.  There will be exceptions,
but they should be exceptions and not the norm.

> 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.
>

If no one has a particular bug open and the bug fixed isn't substantial,
I'd sit on the update or send it to testing at most.

> 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?
>

Nope, not feasible / practical.

> 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.
>

The act of releasing N+1 doesn't mean that N is busted.  I think it'd take
an educated eye to determine if the update is worth it.  But again, the
update should be the exception and not the rule.  Do what is practical to
reach the goal in the quote.

Side note: Dear KDE.  You have an inconvenient release process.

>
> 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.
>

I don't think this conveys the negative connotation that was intended with
regards to feature only and major updates.

> 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.
>

I think a set of tests is an excellent idea "make sure you say no to all
of these before doing your update" but exceptions are always going to
happen.  I'd hate for fesco to be a sort of gate there for all of Fedora
(crit path I assume already has some process).  It's unfortunate that
there's no facility to make decisions on the devel list.

	-Mike