Re: A Proposal to make Experimental API Public in Ostree 2018.5

On Fri, 2018-04-20 at 13:24 -0400, Colin Walters wrote:
On Thu, Apr 19, 2018, at 4:18 PM, Matthew Leeds wrote:

After some discussion with Rob McQueen, Dan Nicholson, Philip
Withnall and
others who are involved with making this happen, I'm proposing that
API be made public (non-experimental) in next week's 2018.5
release, for
the following reasons.

OK.   I'm not entirely sure we can do next week since at least the
staging stuff that landed is still in need of some work and we're
getting really slowed down by some CI issues (being worked on).
I guess we could back it out and do a new release, or actually...mark
the new ostree_sysroot_stage_tree() API experimental.

The situation for us at Endless is that we already have our own
OSTree/flatpak packages with all this enabled; the sticking point is
getting it enabled on flathub. The sooner a release of OSTree and
flatpak is made with P2P enabled, the sooner the packages on the
flathub machines can be updated from their distro. The other option at
the moment is to make a COPR repository for flathub to use with P2P
enabled for OSTree and flatpak, but that’s painful.

I don’t think we strictly need a new release *this week*, but the
sooner the better. I think the motivation behind Matthew’s e-mail was
to try to get the P2P stuff into the *upcoming* OSTree release,
whenever that ends up being. (Rob or Matthew may correct me on this;
they’re more involved with the timeline planning for this.)

I feel like we should do a review of the experimental API bits in
Making the `ostree_repo_lock_*()` and `ostree_remote_*()` APIs
stable should be fairly straightforward for example; after that do
the p2p bits?

I agree that a symbol-by-symbol review of any API which is being un-
marked as experimental is a good idea. Given how the API has been used
a fair bit in eos-updater and flatpak, any such review should be fairly
quick, I think, focussing on things like structure padding,
documentation, consistency and future maintainability.

Starting with the locking stuff and then quickly moving on to the
OstreeRepoFinder core makes sense to me.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]