fedup for F23 and beyond

[Chris Murphy]

On Thu, May 28, 2015 at 2:08 PM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> On Thu, May 28, 2015 at 3:58 PM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:
>> On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
>>> Do you think the tech could stabilize enough to obviate the first
>>> reason? The 6-month workflow cadence remains a good idea, of course,
>>> but  could result in a major offline upgrade, instead of  an entire
>>> new distribution.
>>
>> I think we're already at the point where -- at least for Fedora
>> Workstation (not sure about Server/Cloud), and except for
>> infrastructure issues -- we can stop branding our releases with a
>> version number, and simply have a particularly big offline update every
>> six months. Behind-the-scenes, we still have the six-month cycle, but
>> this is hidden to users. They get Fedora and it's just Fedora, not
>> Fedora 21 or Fedora 22. People stop complaining about the 13-months of
>> support that isn't long enough for them: we wouldn't have that short
>> support window anymore, instead there is *indefinite* support so long
>> as you take your monthly QAed updates pack (five small updates packs,
>> then a big updates pack, then five smaller ones, then a big one, ...).
>> This is the model Windows is moving to, and it makes a lot of sense to
>> me.
>
> I think that is technically possible.  I also think if it were done
> without any sort of ABI/API stability kept in mind, people would be
> irate.  Hiding what amounts to a major version release as an updates
> pack is disingenuous at best, and will break things for users at
> worst.

For users, they mainly need to know if something could break or will
break. If there's a visual and linguistic distinction between update
(bug and security fixes, minimal feature additions) and upgrade
(possible ABI/API breakage, major additions and changes to
functionality) that suggests "could break", that would be the minimum.
Better, if practical, would be listing applications with known
breakage. The problem there is whether this can be a complete list,
and if it isn't then it's not as trustworthy and therefore may not be
worth the effort.

For developers, Fedora needs some policy on ABI/API introduction,
maintenance, deprecation and removal.
For example:
Fedora n = introduction of a new ABI/API
Fedora n+1 = earliest possible deprecation notice but the ABI/API
still works (journald level WARNING or NOTICE)
Fedora n+2 = earliest possible removal of ABI/API.

That's a fairly stable policy. Maybe too stable for Fedora. But at
least some update to Fedora n, making it n+0.5, should be submitted
before just yanking the ABI/API in n+1.


> We cannot do what you describe without a massive amount of
> re-education on what an "update" means in Fedora.  I'm kind of
> surprised you even suggested this, given the focus of Workstation is
> on developers (at the moment) and we're talking in another thread
> about how to provided some kind of API/ABI at the platform level that
> developers can depend on.  Your goal is nice, but we are nowhere near
> the point of actually doing what you just said.

Yes. But aside from the bigger picture of API/ABI stability, even if
there were a clear policy, we still get weird side effects that can
look like breakage (or bugs) that are the result of Fedora releases
being both timed and rolling. The final release is timed, but all
updates for that version are rolling and everyone can have a  system
in a slightly different state depending on what's in the updates repo
and the state of the mirror used. That's pretty messy, pretty often.

There needs to be some sort of versioning indicator. I don't really
care what it is, but the reality is that ABI/API stability and
deprecation are fundamentally necessary. Things will break, and there
needs to be a way of communicating lines in the sand so people can
make informed choices.

-- 
Chris Murphy