hannes changed the topic of #mirage to: bug cleaning day every first friday in month (14:00 UTC - late, next: 2nd Mar) - this channel is logged at http://irclog.whitequark.org/mirage/ - MirageOS 3 is released - happy hacking!
jnavila has joined #mirage
jnavila has quit [Remote host closed the connection]
mort___ has joined #mirage
mort___ has quit [Client Quit]
AltGr has joined #mirage
argent_smith has joined #mirage
mort___ has joined #mirage
mort___ has left #mirage [#mirage]
mort___ has joined #mirage
mort___1 has joined #mirage
mort___ has quit [Read error: Connection reset by peer]
mort___1 has left #mirage [#mirage]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
Kensan_ is now known as kensan
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
yomimono has joined #mirage
TImada has joined #mirage
olle has quit [Quit: olle]
TImada has left #mirage [#mirage]
TImada has joined #mirage
<yomimono>
hello!
<yomimono>
I think it's about time for our biweekly catchup :)
<yomimono>
nobody's added anything to the head of the list, so I guess I'll start -
<yomimono>
next bug cleaning day is friday :) I don't know whether anyone else is committed to attend but I'll be on IRC and digging through old issues starting around 15.00 UTC
<mato>
I might be around, but will be distracted by packing &c
<mato>
However, I hope to have a bunch of Mirage/Solo5 PRs ready for review by then
<yomimono>
yeah, I think between hack retreat travel and upcoming ICFP deadline attendance might be kind of thin
<yomimono>
if you get them in before you leave, I'll try to have a look at them before I leave (if they're anything I can comment on intelligently)
<mato>
Yes, these will be mostly in OCaml-land (adaptations for the API changes) + a bunch of cleanups
<yomimono>
but no rush, we can discuss them just as well (maybe better) in person I guess
<mato>
So review much appreciated. Also from people who know the OCaml/C interface. I've OCamlized a bunch of the stubs better now.
<yomimono>
that's excellent :D
<thomasga>
I will try to be around as well
<thomasga>
(for the bug cleaning day)
<thomasga>
(and to review PRs :p)
<thomasga>
did you discuss about autoCI already?
<yomimono>
no, was just about to -
<yomimono>
on friday I'm going to run some scripts to overwrite a bunch of CI config
<yomimono>
so there'll be a whole mess of PRs across the mirage repositories
<thomasga>
about this: I was wondering if we should add some timestamp or whatever in these files
<thomasga>
to remember in a year when they will be outdated
<thomasga>
(and to remember how they were generated)
<mato>
is this just "config churn" or functional changes as well?
<yomimono>
in most cases it's config churn, in some cases it's fixes to the config
<yomimono>
I wrote the thing motivated by a bunch of common CI misconfigurations I saw
<thomasga>
so maybe just a first comment line saying: generated by autoCI **some options** on the **date**
<thomasga>
(with maybe some version number for autoci)
<yomimono>
it also switches stuff to the container-based builds which are usually 3-4 minutes faster
<mato>
Travis builds have been awfully unreliable of late (had to restart a job just now due to failed to fetch whatever). Any improvements on that front?
<thomasga>
btw, I think that's a great idea to autogen these files :-)
<yomimono>
mato: they've always been pretty unreliable :(
<mato>
+1, yes, and container-based builds on Travis will also help
<yomimono>
but more reliable than running our own infrastructure ;)
<mato>
I have this bunch of shell scripts called vm which seem to be pretty reliable :)
<mato>
(just trolling)
<yomimono>
I am very happy to use CI that other people manage, but after having seen this attempted several times I'm convinced that the difficult bits are on the ops side, not the dev side, of this devops-y thing
<mato>
Agreed
<yomimono>
and so I think whoever manages it should think of it as an ops-y thing and guard their time/attention accordingly :)
<yomimono>
thomasga: I think what you suggest might be best as a commit message rather than in the body of the file
<yomimono>
then you don't get pointless diffs
<yomimono>
but it's a good idea to have that information attached somewhere, so I'll make sure it's in there
<thomasga>
ha yes, the commit message could work as well
<mato>
minor note - if a "regen" results in nothing except a metadata change (version 1.1 -> 1.2) then there's nothing to commit
<yomimono>
issues/prs welcome to the thing over at https://github.com/yomimono/autoci btw. jpdeplaix has already submitted lots of helpful things :)
<yomimono>
mato - yes, which is fine
<yomimono>
so that's probably enough about that :) want to tell us about what's going on in solo5, mato?
<mato>
yup
Khady_ has joined #mirage
<mato>
so, lots of progress on a major api refresh/refactoring. this has been in the pipeline since like last june, so very happy to finally see it merged!
<mato>
the new solo5.h now reads like proper documentation too.
demonimin_ has joined #mirage
demonimin_ has quit [Changing host]
demonimin_ has joined #mirage
mort___ has quit [Quit: Leaving.]
<mato>
I have the downstream Mirage changes mostly pre-prepared, will try to get PRs open by Friday for leisurely review.
hnrgrgr has joined #mirage
<mato>
(then travelling from Saturday until arriving Marrakesh on Thursday 8th)
hnrgrgr is now known as Guest68064
<yomimono>
excellent :D
<mato>
I'd also like to create a feature branch for mirage/mirage related Solo5 changes. Any preferences for what the branch should be called? "dev-solo5" ok?
<yomimono>
LGTM
<mato>
The idea is to PR most of the changes into that, then merge in one go.
<thomasga>
what will be the version number for the solo5 release?
<mato>
Dunno yet. 0.3.0 is what's been earmarked. Will probably still stick with 0.x as there will be more changes to come.
<mato>
But the release is some way away yet, importantly "The great renaming" needs doing.
<thomasga>
ok. if you know it before Friday maybe try to stick it in the branch name. Otherwise dev-solo5 is fine :-)
<thomasga>
ha ok
<mato>
I guess this would become a Mirage 3.1 release from that PoV
<mato>
Also, another question, I'd like to get end to end CI of at least mirage-skeleton building off this branch.Should I do that on a branch there (mirage-skeleton) or muck with the CI on the mirage/mirage#dev-solo5 branch?
lars_kurth_ has joined #mirage
mort___ has joined #mirage
<yomimono>
a branch on mirage-skeleton, please
<mato>
ok. I'll name the branch identically to the mirage/mirage branch
<yomimono>
excellent, thank you :)
<mato>
that's all from me then, unless others have any questions on this...
<yomimono>
saving my questions for github :P
Khady has quit [*.net *.split]
demonimin has quit [*.net *.split]
<mato>
cool :) looking forward to review of my ocaml code
hnrgrgr_ has quit [*.net *.split]
lars_kurth has quit [*.net *.split]
rektide has quit [*.net *.split]
lars_kurth_ is now known as lars_kurth
<yomimono>
a short, punchy list of new features would be great to have
rektide has joined #mirage
<yomimono>
from the solo5 side, for us to refer to in the mirage release notes
<mato>
yes, sure
<mato>
will do
<yomimono>
anything else for this catchup?
<yomimono>
that's the end of the agenda :)
<yomimono>
...and it sounds like the end of the meeting!
<yomimono>
next one is 14 March, which is during the hack retreat
<mato>
good thing this is not a video call then :)
<mato>
looking forward to seeing a bunch of you next week, safe travels!
<yomimono>
you too! enjoy your meander southward :D
<thomasga>
thanks, see you maybe in a few days (still nothing confirmed for me unfortunately)
TImada has quit [Ping timeout: 260 seconds]
thomasga has left #mirage [#mirage]
yomimono has quit [Quit: Leaving]
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
smkz has quit [Read error: Connection reset by peer]
smkz has joined #mirage
jnavila has joined #mirage
mort___ has quit [Quit: Leaving.]
mrgrieves has quit [Remote host closed the connection]
AltGr has left #mirage [#mirage]
jnavila has quit [Remote host closed the connection]