Hi,
On Fri, Dec 16, 2016 at 10:42:43AM +0000, Michael Meeks wrote:
> Hmm ! ;-) My concern would be that removing the 'published' tag
> everywhere would end up making it much harder to change all UNO APIs.
> There is a spectrum of views on how conservative (or otherwise) we
> should be around changing published APIs ATM, and how to do that but
Maybe we should change the meaning of "published" then? Currently, "published"
means a onesided promise to each and eevery person on this planet -- people
that we have
no relation with at all -- that we will never ever change this API and we dont
ever get anything in return. This is painful, as a feedback channel with
"everyone on this planet" is kinda hard to come by, much less so driving
conclusive negotiations on it.
So how about this instead:
1/ We unpublish all API
2/ We give UNO user an opportunity to ask for republishing specific parts of
the API, when they provide a reasonable use case and promise to be the
"client steward" for these.
3/ We continue to change unpublished API as core developers see reasonable. We
promise to release changes to these newly republished APIs only after
checking back with the "client steward" for that part of the UNO API for
advisory _non-blocking_ input[1].
I see multiple advantages to this:
- we (core devs) still retain the perogatibve to do the ultimate decisions on
UNO API changes
- UNO clients have an incentive to get closer to upstream (us)
(we might even get some to become interested in core development)
- UNO clients learn about the rationale for UNO changes early on -- this might
help reduce flaming and butthurt
- we learn what parts of the API are actually externally used
- UNO clients are able to get early prerelease heads-up on API changes and have
adapted by the time the change is released to the world => Less stuff broken
on release day.
There might be some hope that UNO API users like WollMux, Mendeley, Zotero
might be interested in this -- and by talking to them instead of with
$ANONYMOUS_GUY_ON_THE_INTERTUBES we might get a sensible feedback channel and
bring out ecosystem closer together -- as they have incentives to join this
discussion.
Best,
Bjoern
[1] Note this doesnt mean you cant change published APIs on master before
getting feedback as releases are at least 2-3 months off from release to
public.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
