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 this 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 deploy 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 groups. 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. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part