Change Proposals for Fedora 23

[Stephen Gallagher]

On Thu, 2015-06-04 at 07:27 -0600, Stephen John Smoogen wrote:
> On 4 June 2015 at 06:21, Stephen Gallagher <sgallagh at 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 at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/server
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150604/2413c134/attachment.sig>