<thomasga>
we are still looking for someone to take "human-readable" notes of this meeting, if you are interested please do :-) (and send me a summary to put online)
<thomasga>
Mindy is travelling and asked me to run the meeting
<hannes>
thomasga: amirmc any news on the press release front? I guess the release is more or less tested now, and djs55 and thomasga busily add irmin+fs packages to the beta repo!?
<thomasga>
(which will be released soon)
<mort___>
looks like mostly docs, deployable services, performance harness, blog posts / press releases left.
<mort___>
are we going to hold the release up on the performance harness?
<mort___>
i guess the docs and blog posts are being worked on… ?
<thomasga>
I have just added git.1.10.0, and I am planning to add Irmin.1.0.0 in there at one point (hopefully before the end of the week, but everything takes always more time than I expect...)
<mort___>
i'll pick up getting mirage-perf working again (had forgotten about that)
<djs55>
unfortunately the CI on mirageos-3-beta seems to be out of disk space
<hannes>
I don't think performance was a priority item of Mirage3 (though, intuitively it will be faster) ;)
<mort___>
intuitive speed— the best kind ;)
<thomasga>
djs55: we need to wait for @avsm to come back to fix the CI :-/ we need a more automated solution
<thomasga>
(you can add the feedback on the tracking issue for release, on GitHub mirage#592)
<thomasga>
@amirmc: anything to add related to the press release? everything is under control?
<thomasga>
hannes: are you still planning to work on the blog post "how MirageOS 3 got smaller and less magical"?
<hannes>
thomasga: yes. WIP
<hannes>
draft be there at the end of this week
<thomasga>
@talex5: any chance that you can pick up the ""error handling in MirageOS" draft RFC into currently-accurate document" task?
<seangrove>
Sounds exciting!
<thomasga>
otherwise I can try to do it :-)
<talex5>
Hmm, well my proposal was for something different. I think we should close that PR.
<thomasga>
also, I am planning to write some docs for Irmin 1.0
<thomasga>
@talex5: it's probably useful to document a bit more how the error are now handled in Mirage. @djs55 had some related issues with qcow2
<thomasga>
but I can try to do it
<thomasga>
(I am still reviewing the list of things to do for the release) For the changelogs, I think Mindy has made some toolings, I'll check with her with is the status of that task.
<mort___>
my impression from yesterday evening was that she won't directly include teh changelogs in the blog post but will have something that points to the github provided diffs-between-tags
<thomasga>
ok
<mort___>
(but yes, check with her, she knows :)
<thomasga>
@seangrove is there anything that you would like to see for the release?
<seangrove>
thomasga: No, we're neck-deep in non-mirage-related stuff right now, so just watching from the sidelines
<thomasga>
something that you think will excite potential users?
<thomasga>
ok no pb
<thomasga>
if you think of anything, please tell us :-)
<amirmc>
Sorry, I was afk. Press Release is delayed on getting a date, which means co-ordinating with multiple parties. It's taken a while as there hasn't been a date that works for everyone. I've been chasing it and will let folks know as soon as I have more info. The content of the press release also needs to be reviewed by a bunch of people (e.g. LinuxFoundation, et al). First draft is pretty much ready for that.
<thomasga>
should we still decouple the actual opam release and blog post stream and the press release?
<thomasga>
(it's probably best, right?)
<amirmc>
To summarise, there are two blockers for the Press Release. 1. deciding a date and 2. getting the content approved. I'm working on both.
<amirmc>
Blog post pre-empts the press-release.
<thomasga>
great, thanks
<hannes>
and we plan to have it done before the hack retreat, don't we?
<amirmc>
i.e. if a 3.0 post goes out, then no-one will be interested in writing articles about the release. They're kind of coupled.
<djwillia>
amirmc: would it be possible for you to share the press release draft at this point? I'd still like to get IBM to make its quote :)
<amirmc>
Unless we want to have blog posts about specific features, rather than an overview post. That should be fine.
<mort___>
amirmc: ok— so the press release has to come before the blog posts, but the opam releases could trickle out before?
<djwillia>
and i feel like i've been neglecting that
<amirmc>
djwillia: Yes, I'll share it once I've had various marketing depts sign off on it :)
<thomasga>
I am a bit confused with the dependencies between all the releases. It's a bit weird to just release in opam without publishing a blog post.
<mort___>
it sounds like we're arguing ourselves to a state where everything is gated on the press release then
<thomasga>
so we keep everything in a separate remote until the press release is out?
<thomasga>
and no blog post?
<mort___>
itym: blog post after press release?
<amirmc>
Yes, it would be weird to release that way. We can't release without explain to people what changed. But we can't tell people what changed without pre-empting our own announcement (shrug)
<thomasga>
do we really care about the press release? :p
<amirmc>
yes
<amirmc>
we do
<thomasga>
is there any chance that this will happen before the hackaton?
<amirmc>
We can still do a chai of posts like we did for 2.0 though.
<mort___>
we also care about developer sanity :) so minimising time between packages being ready and release going out would be very useful
<amirmc>
It's only the _announcement_ post (i.e. "here's 3.0!") that we shouldn't do.
<mort___>
given the many api changes, i'm not sure how many pacakges can be released (and thus blogged about) incrementally
<thomasga>
not much
<hannes>
amirmc: for me (at least) it would be helpful to have in some issue a proposed timeline (with as precise dates as possible) for the release
<amirmc>
They can be blogged about in the context of the beta quite easily.
<amirmc>
hannes: I agree. And we keep thinking we had this but dates shift and code wasn't ready.
<thomasga>
code is ready now, so we can have a new timeline :-)
<hannes>
amirmc: then as soon as you have dates
<mort___>
ok. so we start publishing a sequence of blog posts about "Mirage v3 beta components". meanwhile amirmc pushes forwards with the press release and we finally flip the switch in opam and put a summary "we released!" post live when the press release goes out … ?
<hannes>
thomasga: I couldn't find the right irmin release to run canopy on mirage3 yet ;P
<thomasga>
hum. code is "almost" ready now.
<amirmc>
mort___: that would work for me. And means we can link to those posts from the press release itself (which is a nice bonus)
<mort___>
thomasga: yes, so we can start blogging it while the PR catches up (and we find remaining bugs, finish updating docs, etc)
<hannes>
(as stated above, I'll have the post on less magic and less code ready by the end of this week)
<mort___>
amirmc: yes, true
<thomasga>
@mort___ @amirmc: as long as the beta doesn't long for 3 months, that looks good :p
<mort___>
that's what I meant about developer sanity — we don't want things queuing up against the "beta" repos for too long
<amirmc>
In that case we'd explicitly planned a blog post series before the release.
<mort___>
else people feel compelled to submit issues / PRs against v2 versions
<thomasga>
@amirmc: can you sync with Mindy to check how she wants to run things? And try to come up with a timeline?
<amirmc>
I want this announcement (and code) to go out as much as everyone else.
<amirmc>
mindy's in the loop on all that stuff already :)
<mort___>
yup understood :)
<mort___>
cool
<djs55>
I've been merging v3 things to components master branches for v3 now. This means that it's harder to get stuff to build than it was before (missing remote == odd errors). If it's going to be a while before the official release perhaps we should go round and edit all the READMe files
<thomasga>
sure, but it seems that having a timeline and communicating to the team seems to something quite important now :-)
<amirmc>
Blockers are as mentioned earlier 1. Dates and 2. Approvals from various parties. :)
<amirmc>
Unless we decide not to do a Press Release at all.
<mort___>
i think that for graduation from LF it would be nice
<amirmc>
That's off the table for now
<mort___>
(oh, hadn't realised)
<amirmc>
Since no-one really knows what it means :)
<mort___>
amirmc: ok, so i guess the question is: how long until you think you can get a date nailed down from the various parties involved?
<thomasga>
@amirmc: do you have some estimates for the dates? Is that days/weeks/months? (curious about what to expect here)
<mort___>
we can then take a view on whether we can feasibly wait that long given how ready things are
<thomasga>
(we might have lost Amir :p)
<thomasga>
any other topic to discuss for the release?
<amirmc>
I'll work on it and get back to you but the lead time is about a week or two (since people have to co-ordinate with journalists etc).
<mort___>
in the meantime, perhaps we start releasing blog posts referring to components for mirage v3 beta
<thomasga>
ok great
<mort___>
amirmc: that's a week or two until we have a date, which may be some weeks later?
<amirmc>
mort__: It's a minimum amount of time required. i.e. if dates were not a blocker, we could do it in a week or so.
<mort___>
ok cool
<thomasga>
last item in our agenda: progress on Irmin 1.0.
<amirmc>
Let me know if there are points I've not covered. I've been trying to read and type at the same time but I probably missed stuff.
<thomasga>
I have made a new release of ocaml-git (where references can be updated using test-and-set) and with better windows support.
<amirmc>
thomasga: The folks at Ericsson have been using Irmin a lot (v0.11 I believe). Any tips on how to move to the newer version (before release) would be helpful :)
<thomasga>
@amirmc: yes, I am planning to write docs
<thomasga>
but I am focusing first of rewriting everything :-)
<mort___>
thomasga: everything is … everything ;) is there anything that would benefit from wider testing?
<thomasga>
and I will try to update canopy too
<mort___>
(ie., where you don't already need to know irmin :))
<thomasga>
the test suite is pretty complete, so I think that should be ok. I know the Git push/fetch protocol has some issues, this is *not* addressed in that release
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brson has quit [Ping timeout: 260 seconds]
brson has joined #mirage
<hannes>
kensan: thx, fixed!
<hannes>
haesbaert: since cstruct-2.2.0 the set 0 is no longer needed, Cstruct.create will zero out the buffer
<haesbaert>
ah no, I mean cstruct.set_len 0
<hannes>
oh ic... and yes, it is not entirely clear to me where to allocate things... it sounds like allocation a page and filling it should be less pressure on the gc+os than allocating every 2 bytes individually
<haesbaert>
I mean I can precalculate how much I need, and then do one allocation and set some offsets
<haesbaert>
but that is incredibly error prome
<haesbaert>
*prone
<hannes>
and wasn't spiros working on that with faraday, the reverse angstrom.. !?
<haesbaert>
I want to do something like add_byte 7 buf |> add_uint32_t Int32.zero |> add_string "foo"
<haesbaert>
and then get a Cstruct.t in the end,
<haesbaert>
buf could start with lets say 1024, and it grows by 1024 every time there is no space, or something like that
<haesbaert>
hmm I'm not aware
<haesbaert>
like, on decoding I have an awesome idiom:
<haesbaert>
decode_nl buf >>= fun (kex_algorithms, buf) ->
<haesbaert>
decode_nl buf >>= fun (server_host_key_algorithms, buf) ->
<haesbaert>
decode_nl buf >>= fun (encryption_algorithms_ctos, buf) ->
<haesbaert>
I want the inverse in a similar idiom
<haesbaert>
basically it gets what it wants and shifts
<haesbaert>
I want to put and shift now
<haesbaert>
without having to worry about sizes and what not
<haesbaert>
I'm cooking up somehting, lets see how it goes
<hannes>
:)
<haesbaert>
I can't sleep with 4 + mallocs + 1 memcpy to handle 9 bytes