On Thu, 2015-06-04 at 07:27 -0600, Stephen John Smoogen wrote:
On 4 June 2015 at 06:21, Stephen Gallagher
<sgallagh(a)redhat.com>
wrote:
> On Wed, 2015-06-03 at 08:43 -0400, Stephen Gallagher wrote:
> ==============================
> == Stable API Documentation ==
> ==============================
>
> === Benefits ===
> Having a Fedora-provided repository of the specific set of API (and
> ABI) that we guarantee stability or backwards-compatibility will go
> a
> long way towards addressing the concerns around our lack of an LTS
> release. Additionally, it will make life easier for our users to
> have a
> single source to look for documentation, rather than the current
> situation of having to search out each upstream for documentation.
>
> === Issues/Risks ===
> * Requires a large time commitment from someone on the Fedora Docs
> team to collate the documentation and post it to the Fedora
> Documentation site.
> * Requires developer effort to locate and identify the stable APIs
> * Almost certainly cannot all be done in a single release
>
> === Recommendations ===
> * Locate someone from Fedora Docs to do the collation
> * Start with a set of known-stable APIs (such as glibc and
> systemd)
> and publish those for Fedora 23.
>
What guarentees does systemd have towards API's? They seem to be at
least adding new features all the time which would mean that the API
is getting larger over a release set. Which probably goes towards
having a definition of stable that we 'guarentee' as some see stable
as nothing be added and others see items not getting removed.
systemd has several D-BUS APIs that upstream guarantees will remain
compatible. Yes, new (and often non-guaranteed) APIs are released
regularly. We would be talking about supporting only the stable ones
formally.
Also what level of API/ABI definitions are we looking as being
'published'. Getting a list of calls might be easy, but defining what
each call does would take time. [Past projects of standalone software
was on the order of 3-5 months depending on the level of detail
required.]
Ideally we'd be republishing upstream documentation, just gathering it
for easy access.
>
>
> =========================
> == API break detection ==
> =========================
>
> === Benefits ===
> Provide a taskotron process that will identify API and ABI breaks
> for
> common languages when updates are submitted to Bodhi. If such are
> detected, we should disable autopush-by-karma. This will allow us
> to be
> able to better avoid incompatible updates in stable releases of
> Fedora.
>
> === Issues/Risks ===
> * Tooling needs to be implemented. (Some help may be available
> from
> libabigail[1])
> * Someone needs to write a taskotron process that will run when
> updates are created
> * Available tools for this are currently limited to C/C++ ELF
> libraries
>
> === Recommendations ===
> Search out someone to do this work. It is high value for
> comparatively
> little work (since much of the hard work has been solved by
> libabigail). Volunteers highly requested.
>
> It would be worthwhile to start with C/C++ and see how things
> progress
> from there.
>
>
> [1]
https://sourceware.org/libabigail/
> _______________________________________________
> server mailing list
> server(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/server