18:58:56 <f_g> #startmeeting
18:58:56 <MeetBot> Meeting started Sun Jun 18 18:58:56 2023 UTC.  The chair is f_g. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:37 <f_g> #topic meeting agenda
19:00:08 <f_g> maybe let's start by doing a roll call and a 1 sentence intro why you are here today/what you are doing in the team (or want to be doing ;))
19:01:26 <count_omega> sounds good :)
19:01:39 <ncts> hah, we didn't have a sign-up
19:02:35 <f_g> #info Fabian, mostly working on toolchain stuff and associated crate packaging (rustc, cargo, debcargo)
19:03:01 <jamessan> #info James, mainly working on alacritty and tree-sitter related crates, but try to help out with things in general and sponsor when I have free cycles.
19:04:09 <ncts> #info Blair, at the beginning general stuff that I found useful, now starting on the toolchain
19:04:15 <f_g> (if you prefix lines with #info, they will show up later in the meeting summary, instead of just the logs. there are similar other commands for noting todos and decisions)
19:04:24 <count_omega> #info Matthias, mainly working on the gtk-rs stack and dependencies for GTK rust apps
19:04:44 <f_g> (https://wiki.debian.org/MeetBot in case you've never been in one of these :))
19:07:20 <f_g> any additions to the agenda proposed in the announcement mail? (https://lists.debian.org/debian-rust/2023/06/msg00001.html)
19:07:52 <f_g> besides the transitions count_omega already replied with (I'd say we handle transitions as one single topic, unless there is some bigger issue with one in particular)
19:08:27 <jamessan> Looks good
19:08:53 <ncts> that covers most I know of
19:09:03 <count_omega> +1
19:09:13 <f_g> ack, then let's proceed :)
19:09:21 <f_g> #topic rust toolchain updates
19:09:41 <f_g> #info rustc 1.64-1.66 are in experimental
19:09:57 <f_g> #info 1.64 is prepared for unstable, but not yet uploaded
19:10:18 <f_g> #action mjt Sylvestre should figure out who does the upload
19:10:33 <f_g> #action f_g will monitor the situation and prepare the next uploads
19:10:44 <f_g> #info 1.67 is up for review (thanks ncts!)
19:11:07 <f_g> #info upstream is already at 1.70, so there are three more versions to update/review/upload
19:11:50 <f_g> there is one issue with the current workflow with regards to the patches that I'd like to improve, to reduce the diff for reviewing
19:12:21 <f_g> #action f_g look at gbp pq or other tools for managing the patch queue(s) to have a single, unified format that works for everyone
19:12:39 <f_g> ncts: will you look at the next upstream versions once 1.67 is reviewed and progress on uploads has been made?
19:13:10 <ncts> my latest 1.68 build log doesn't look very bad, albeit generated in april
19:13:54 <f_g> in general I have the feeling that updating itself worked well over the past few months despite Ximin and Sylvestre being completely and mostly out of the picture, the main bottle neck is DD capacity for uploading to bin-NEW
19:14:28 <f_g> #action ncts will prepare 1.68 update once 1.67 has been reviewed
19:15:39 <ncts> the "toolchain" already in place seems like an easy enough routine, but speaking of that, I imagine we can have something similar to x.py upstream
19:16:42 <f_g> for patch handling? or unifying the various other helper scripts for pruning and checking? or for starting the Debianized build? :)
19:17:12 <ncts> unify patch handling and other helpers into a single Debianized build script I guess
19:18:16 <f_g> maybe we can open an issue and collect ideas there? and decouple it from the ongoing updates?
19:18:30 <f_g> there is for sure some potential for deduplication in the helper scripts :)
19:18:50 <f_g> #action f_g ncts brainstorm improvements for rustc packaging helpers
19:19:24 <f_g> with cargo the situation is a bit different - we are at 0.66 (== rustc 1.65), and mostly stayed there because of the freeze
19:20:02 <f_g> I will try to find the time to update in the near future (with cargo we can thankfully skip versions most of the time), mainly for the sparse registry feature
19:20:13 <f_g> unless there is somebody else that wants to drive that?
19:21:01 <f_g> in any case it does require a DD to be around for uploading, as there are usually double digits crates that require updating
19:22:56 <jamessan> I've not been involved in that before, but I could give it a shot
19:23:11 <f_g> ack :)
19:23:40 <f_g> #action f_g jamessan do a walkthrough of src:cargo updating
19:24:18 <f_g> we could split it up into cargo and debcargo updating if you want? they usually (have to) happen in lockstep, but the actual work is fairly independent
19:25:15 <f_g> anything else on the non-debcargo toolchain side?
19:25:17 <jamessan> We need someone to publish debcargo in order to update that, right?
19:25:35 <f_g> yeah, that is its on separate topic :)
19:25:56 <ncts> I can contribute on the cargo side, somewhat
19:26:55 <f_g> #action ncts also offers help for cargo update work
19:27:19 <ncts> Sylvestre might use some help on llvm, but that's a whole different thing
19:28:01 <f_g> yeah, that's another team entirely :) although I am sure they can also use more people ;)
19:28:11 <f_g> maybe let's proceed with debcargo maintainership?
19:28:43 <jamessan> ack
19:28:52 <f_g> #topic debcargo maintainership
19:29:41 <f_g> the main issue here is likely who can cut releases, as that is currently Josh Triplett (not active in Debian anymore AFAICT) and Ximin (currently on vacation, and in general, their involvement has decreased over the last 2 years)
19:31:02 <jamessan> afaik, I have permission to merge to the repo.  The issue is more on the crates.io side, I believe
19:31:15 <f_g> exactly, that's what I meant with "cut a release"
19:31:39 <f_g> most (all?) of the Rust team has push rights on the repo IIRC, it's publishing an "official" version of the crate that is limited
19:31:42 <count_omega> You have to be added on crates.io as maintainer to release iirc
19:31:54 <f_g> and our packaging in turn is based on what's published on crates.io
19:32:16 <f_g> obviously we can work around that for urgent issues and just patch, but that is not a good work flow for whole features or big deltas
19:32:38 <count_omega> maybe we can ask ximin to grant someone from the team access
19:32:51 <ncts> you should ask infinity0 for upload right IMO
19:33:02 <ncts> for being the most familiar with it
19:33:26 <f_g> IMHO the way forward would be exactly that - at least 1-2 people from the team should be granted publish rights, and we should have some sort of decision making for what goes in other than regular cargo and dep version updating and clear bug fixes
19:33:51 <f_g> e.g., if we continue to have these meetings, anything that might be controversial could be agreed upon here first before being implemented
19:34:17 <count_omega> agreed.
19:34:51 <jamessan> speaking of, I'd like to finish off the rust-version MR
19:34:53 <count_omega> #action ask infinity0 to give two team members access
19:34:59 <ncts> otoh, debcargo is used almost exclusively by DRT
19:35:15 <f_g> jamessan: it's on my TODO list :)
19:36:06 <ncts> it's more or less an "debian internal package" that happens to have to be pulled from crates.io because our setup is centered around that
19:37:25 <f_g> yes, so IMHO it makes sense to reduce the scope of the "ownership" on crates.io to make it more of an implementation detail of the "cut a release" procedure, and less of a "these are the people that have to ack and implement any bigger changes"
19:37:48 <ncts> I mean, it's not a bad thing to have it published on crates.io, but as an internal tool, maybe we can shift to an "internal" approach, like how rustc and cargo are done
19:38:43 <count_omega> releaseing tarballs on GL is also an option
19:38:51 <count_omega> * releasing
19:38:52 <f_g> would work as plan B as well (for example, using the local source support). it would be a bit weird to do that without also marking the published crate as no longer being published though
19:39:32 <f_g> it's definitely not only used in Debian itself btw, there are downstreams/derivatives that use it as well ;)
19:39:41 <count_omega> iirc you can't delete crates, only yank them
19:40:11 <jamessan> Do they consume it by importing from Debian or by using the crate, though?
19:40:53 <f_g> speaking for my $dayjob, we basically fork debcargo-conf and patch as needed, and that includes debcargo
19:41:03 <f_g> not sure what others do
19:41:39 <f_g> for me almost all variants are workable
19:41:47 <ncts> I'm not saying to abandon it on crates.io ;) just that it's not the "source of truth"
19:42:41 <f_g> let's see what Ximin thinks about giving access to a few more people, if that works, it's probably the lowest friction variant for now
19:42:51 <jamessan> agreed
19:43:05 <count_omega> +1
19:43:09 <ncts> +1
19:43:39 <f_g> #action f_g write to Ximin+CC about details of transfer/expansion of ownership
19:43:44 <f_g> #topic debcargo changes
19:44:01 <f_g> #info jamessan already mentioned the MSRV translation that is up for review
19:44:28 <f_g> #info mjt proposed an alternative encoding of dependency ranges
19:45:05 <f_g> #info semver_suffix changes need to be implemented in debcargo proper (Breaks+Replaces issue with Provides/virtual packages)
19:45:23 <ncts> #info ncts proposed feature-less packages that encode feature information not in package name but in d/control field
19:45:25 <ncts> ;)
19:45:37 <count_omega> q: could we drop the compat file, use debhelper-compat and but it to the latest (13) ?
19:45:57 <ncts> if so, maybe also update Standards-Version
19:46:14 <f_g> yes and yes, such things are usually done when updating debcargo :)
19:46:16 <jamessan> Yeah, that seems like something that should be reviewed once or twice a Debian release :)
19:46:17 <count_omega> there's a MR by capitol for that
19:46:47 <count_omega> maybe I can look into the compat thing
19:47:09 <f_g> there is a list of smaller and bigger backlogged issues in salsa as well, like allowing bin-only packages
19:47:38 <f_g> support for arch:all -data bin packages and multiple bin packages might also be nice to have at some point
19:47:58 <f_g> I don't think those are filed/spec'ed yet though :)
19:48:14 <ncts> I'd like to also throw in a broad concept that is an overhaul of our setup
19:48:34 <count_omega> yeah I remember filing that; the compat thing might be something I'm competent doing though
19:48:49 <count_omega> ^the bin-only thing
19:49:12 <f_g> ncts: shoot :) or at least, a fix sentence summary maybe ;)
19:49:26 <f_g> #action count_omega potentially will take a look at DH compat changes in debcargo
19:49:42 <f_g> #action f_g will review jamessan MSRV translation MR, which got updated since the last feedback
19:49:59 <ncts> the current one is 1) rustc with a bunch of ad-hoc helper scripts 2) cargo with a bunch of ad-hoc helper scripts 3) debcargo which has a good base concept of overlay but lack quite some pragmatic things 4) a whole pile of package overlays organized under an ad-hoc repo named debcargo-conf
19:51:15 <count_omega> I'd like to throw in that d-c-c is getting quite big
19:51:44 <f_g> ncts: that's a short summary of the status quo, yes :)
19:52:35 <ncts> maybe it belongs to another issue and discussion organized after this meeting
19:52:38 <count_omega> I'd also propose we discuss https://salsa.debian.org/rust-team/debcargo/-/issues/43 (not now though)
19:53:00 <ncts> I have to admit the frequent urge of overhaul despite having no clear clue to implement
19:53:34 <f_g> count_omega: definitely something we should pick up again in the near future, maybe something for the next meeting?
19:53:40 <jamessan> There's also the issue of debcargo's integratinon tests being outdated/broken, and no clear (that I'm aware of) documentation about that process
19:53:52 <count_omega> f_g:  sure
19:54:21 <f_g> ncts: you could also write up a more extensive proposal before a meeting, that way we could read and then discuss it? I know I am not always the best at getting back in a timely fashion to longer mails, but maybe the meeting deadline helps :)
19:54:51 <f_g> #action f_g write more documentation for debcargo integration tests
19:54:58 <ncts> it actually comes out midway, but the writeup, definitely
19:55:00 <f_g> #action unbreak debcargo integration tests
19:55:27 <f_g> #action ncts write up proposal for more fundamental changes in packaging work flow
19:55:56 <f_g> anything else that's needed for debcargo itself before we proceed to the monorepo-related topics?
19:56:11 <ncts> almost forgot the manifest replacement
19:56:51 <ncts> the "a section of debcargo.toml replaces a section of Cargo.toml" thing
19:57:14 <ncts> along with "d/control replacement"
19:57:47 <f_g> yeah, there is a slew of features going in that direction that we should evaluate - like removing targets, removing features, removing benches/examples
19:58:11 <count_omega> +1 for that
19:58:32 <f_g> but that might need a bit more testing before a concrete proposal :)
19:58:33 <ncts> I lean towards the generic approach, plus a spec
19:58:50 <ncts> it's almost too easy to replace a toml section with another
19:59:51 <ncts> specific features, otoh, are impl's of the same underlying thing with different focus
19:59:54 <f_g> that sounds like xpath/xslt :-P
20:00:16 <ncts> in the generic sense, yes
20:00:53 <ncts> ahem but that's also impl detail
20:01:03 <f_g> could be explored as well, but sounds like a bit of an orthogonal feature that could be used for similar goals. my guess is the UX of that would be worse than anything custom tailored for our common problems
20:02:04 <f_g> but if we start generating patches from declarative input, having such a generic option as part of that for those that want to use it could work
20:02:25 <f_g> I'd not see it as replacement for "remove_examples = true" though :)
20:03:18 <capitol> oh, sorry for forgetting about the meeting :( have been running around outside all weekend. I will read the backlog
20:04:05 <jamessan> On to the next topic?
20:04:08 <f_g> #action ncts might explore a "generic semantic toml patching" feature for debcargo, to allow replacing/adding Cargo.toml
20:04:21 <f_g> #topic debcargo-conf tooling/improvements
20:05:14 <f_g> we recently had some reports of friction from people new to rust packaging, but not to packaging/Debian.
20:05:32 <f_g> release.sh was the main culprit, but https://salsa.debian.org/rust-team/debcargo/-/issues/55 was also a result of that for example
20:06:20 <jamessan> I really think release.sh should default to NOUPDATE (as a comment in release.sh suggests)
20:06:42 <jamessan> release.sh should just be about producing the final source package
20:07:21 <f_g> I was always a bit hesitant about changing release.sh as a non-DD
20:07:45 <ncts> so be a DD :P
20:07:58 <count_omega> imho it should default to source-only uploads since most of the times it's just for updates
20:08:09 <f_g> but yeah, that sounds like a good idea, the one below as well. there was also the question of whether the RFS/Uploaders check really makes sense
20:09:48 <jamessan> #action jamessan remove "update" functionality from release.sh
20:11:12 <f_g> count_omega: we basically have the information whether it requires a bin upload or not anyway, so it should be able to do the right thing
20:11:26 <f_g> do you want to take a stab at improving it if it does not handle some case correctly at the moment?
20:11:27 <jamessan> There's been some good progress on documenting workflows, but I agree that there are papercuts we could improve
20:12:09 <jamessan> Yeah, I thought release.sh did default to source-only unless it detected the package was new.  Maybe there are some missing heuristics
20:12:33 <count_omega> f_g:  I can put it on my to-do list but I can't promise I will tackle it soon, maybe once study break rolls around
20:12:55 <f_g> ack
20:13:12 <f_g> #action count_omega (time permitting) will look at release.sh generating/dputting the right kind of changes files
20:14:56 <f_g> anything else for the tooling side of the monorepo? probably filing issues/MRs is a good idea when anybody encounters something that could be improved - it's usually an "in the moment" thing that is forgotten sooner rather than later (at least for me it usually is ;))
20:15:57 <count_omega> clean up deprecated crates (ncts did some work on that)
20:16:21 <ncts> kinda ot but, how do you build a chain of deps?
20:16:37 <jamessan> Sort of.  I think the "no ITP" policy worked ok before we had a significant non-monorepo contingent of packages.  It might be a good idea to revisit that, maybe with some tooling to help file the ITPs, so we play nicer in the broader Debian ecosystem
20:16:58 <f_g> I just put crates and versions into a file and run a shell loop over that :)
20:17:21 <f_g> jamessan: I think the main reason that was not done in the past was the sheer amount of ITP noise that would cause
20:17:29 <ncts> I wrote chain_build.py which you feed crate names and optionally versions in the order you want built
20:17:41 <ncts> but the feeding part is another problem
20:17:44 <jamessan> chain_build.py is handy.  I have a local patch that has a "repackage.sh" mode instead of "update.sh", if people think that's useful
20:18:08 <count_omega> like stated above: dcc is getting kinda big, maybe we need to think about organizing it otherwise sometime in the future
20:18:37 <f_g> jamessan: sounds like a reasonable addition
20:18:46 <count_omega> jamessan:  I agree with f_g here: just this week I'd have to have filed like 8 itps
20:19:11 <f_g> IMHO filing is not really the issue (it's a bit tedious, but fairly mechanical)
20:19:14 <ncts> jamessan: feel free to push it! only until recently did I realize that more than not what I want is repackage.sh, not update.sh
20:19:26 <f_g> it's getting on other people's nerves that would be my concern
20:19:34 <jamessan> That's why I mentioned automating the ITPs.  The perl and go teams do something similar, and that would reduce the animosity (and toe stepping) from non-dcc folks
20:19:35 <count_omega> true
20:19:59 <count_omega> dh_make_rust when :P
20:20:16 <f_g> count_omega: could just be a script in dcc's dev dir
20:20:30 <f_g> ./dev/generate-itp.sh <crate> [version]
20:20:40 <ncts> imagine the scaled up ITP farm
20:21:03 <f_g> and then of course, debcargo or one of the scripts should check for an ITP bug and close it ;)
20:21:06 <f_g> in d/changelog
20:21:24 <f_g> any takers for writing a PoC helper?
20:21:35 <count_omega> I actually tried hacking a dh_make_rust for packaging gui rust apps but failed at writing the dependency translation stage
20:22:06 <count_omega> I can take a stab at it in august
20:22:15 <ncts> I can try that too ;)
20:22:36 <jamessan> ncts: Would you prefer the default to be repackage or update?  Currently, I have it look for REPACKAGE=1 since I didn't want to disturb the default
20:23:02 <f_g> count_omega: file https://salsa.debian.org/rust-team/debcargo/-/issues/56 for that just now so we don't forget
20:23:07 <ncts> generating is not a problem compared to "integrating" it into the workflow
20:24:02 <f_g> #action count_omega will take a look at ITP filing assistance in August, if nobody else does it before that
20:24:23 <count_omega> f_g:  ty
20:24:38 <ncts> jamessan: I hard coded a func to collapse_feature, that requires a update.sh run, other than that I think it's safe to just repackage.sh
20:24:53 <jamessan> Yeah, I skip that part when repackage is in use
20:26:15 <ncts> just punsh it ;)
20:26:33 <f_g> #action jamessan will push some improvements to the chain build script by ncts
20:27:00 <f_g> it's getting late, should we move to transitions/breaking updates? maybe just a short overview of what's going on/planned?
20:27:18 <jamessan> Maybe default to repackage.sh unless =REALVER specs are seen?  That would require more changes.  I'll push what I have and we can improve later
20:27:23 <jamessan> f_g: ack
20:27:35 <f_g> #topic ongoing and upcoming transitions
20:27:51 <f_g> #info base64 seems to be going well, plugwash did most of the heavy lifting
20:28:31 <f_g> #info rust-cargo will happen in the next weeks, and might involve some other transitions as well
20:29:00 <ncts> jamessan: that's a good idea, I'll save it for after this meeting
20:29:04 <jamessan> wayland 0.30 is staged in experimental, but alacritty will need 0.29
20:30:05 <count_omega> that's not that urgent tbh since ashpd will be uninstallable anyway after the gtk upload
20:30:16 <count_omega> I just prepared it
20:30:47 <jamessan> Yeah, it just surfaces another "papercut" of our current workflow, since we don't have distinct branches for the different Debian releases
20:30:48 <f_g> "This can effectively be considered a new crate altogether." how many users are there of <= 0.29 atm ?
20:31:16 <ncts> might be time to start "transition"ing aes, which is a security concern and doesnt affect too many rdeps
20:31:36 <count_omega> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/43
20:32:22 <count_omega> +1 for aes/cipher since I might need it for other packages
20:32:38 <f_g> ncts: will you drive that?
20:32:51 <ncts> can do ;)
20:32:53 <f_g> count_omega: okay, so that one is atm still blocked waiting on upstream changes
20:33:00 <f_g> #action ncts will look at aes transition
20:33:15 <jamessan> I can nudge the alacritty folks to see if they have a plan to get new winit and alacritty releases out that use wayland 0.30
20:33:29 <f_g> #info wayland 0.30 would break winit/alacritty, waiting on upstream developments
20:33:37 <jamessan> That would avoid updating the stack to a newer 0.29 release
20:33:45 <count_omega> yeah no rush on that
20:33:46 <f_g> #action jamessan will nudge alacritty upstream to update
20:34:12 <jamessan> They've already updated winit, iirc, but not released it
20:34:22 <f_g> if there is no progress within a reasonable time frame, semver_suffixing it is also an option (in this case, 0.29 and 0.30 are considered almost different crates by its upstream after all)
20:34:55 <f_g> count_omega jamessan will you keep the tracking issue updated from time to time?
20:35:04 <jamessan> Sure
20:35:08 <count_omega> sure
20:35:20 <f_g> #action jamessan and count_omega will keep wayland transition issue uptodate on salsa
20:35:30 <ncts> btw count_omega I'm interested in packaging wezterm too, daily driver on mac now and will be glad to see it on debian
20:35:36 <f_g> what about gtk, zbus and syn? any problems/blockers?
20:36:09 <count_omega> gtk is ready to go to unstable except 2 armhf failures for gio and glib
20:37:01 <count_omega> I tried setting up a armh qemu autopkgtest today but it failed to start ( on two different machines)
20:37:25 <count_omega> zbus needs only zbus-1 to be accepted from new
20:37:37 <f_g> sounds manageable :)
20:37:47 <f_g> https://release.debian.org/transitions/html/rust.html is also not looking too bad
20:37:51 <count_omega> syn is just waiting for autopkgtest failures/passes
20:37:55 <ncts> ask for a porterbox or something?
20:38:20 <count_omega> hm, yeah. can I run a backtrace there
20:38:22 <count_omega> ?
20:39:24 <count_omega> regarding wezterm: I commented on the dep list but I don't have any time to package /maintain it
20:39:49 <count_omega> I also need to look into the diesel mess
20:40:39 <f_g> count_omega: a binfmt/qemu-user-static env might also work for your test case checking - doesn't allow gdb, but at least debug-by-coding ;)
20:41:37 <f_g> the CI log looks like some derive macro or code generation gone wrong - https://ci.debian.net/data/autopkgtest/unstable/armhf/r/rust-gio/34125397/log.gz
20:42:04 <f_g> #info gtk transition still has some arch related issues to iron out
20:42:16 <f_g> #info zbus is waiting for zbus-1 in NEW
20:42:20 <count_omega> I did that: https://paste.debian.net/1283399/ (except arch set to armhf)
20:42:23 <f_g> #info syn also looks to be on track
20:43:02 <f_g> no, I mean something else :) I'll ping you tomorrow?
20:43:09 <f_g> any other transitions worth mentioning?
20:43:24 <count_omega> no
20:43:28 <count_omega> thanks :)
20:43:37 * f_g also doesn't have any planned
20:44:27 <f_g> #topic future meetings
20:44:57 <f_g> should we keep doing these? with what frequency/schedule?
20:45:20 <count_omega> like at least once a month ?
20:46:01 <ncts> aye, imo it can push some things farther
20:46:05 <f_g> I think once a month is a good frequency, and I do like that they provide a sort of focus point, even if obviously most of the work still happens outside of the meetings
20:46:11 <jamessan> +1
20:46:42 <ncts> monthly is quite standard, haha
20:46:44 <f_g> it would also give us some sort of natural area for discussions and decision making that is not too async and/or verbose
20:46:51 <f_g> any preferences for slots?
20:47:08 <ncts> like last sunday?
20:47:22 <ncts> btw, what's our timezones?
20:47:34 * f_g is in CET, which is UTC+2 atm
20:47:39 <count_omega> any time is fine by me though I'd prefer it not to be wednesday evening
20:47:46 <jamessan> America/New_York
20:47:46 * count_omega too
20:48:53 <ncts> Asia/Shanghai but I now live like Europe/Berlin
20:49:42 <ncts> so still 19:00 UTC?
20:49:54 <f_g> so would 6 or 7 pm UTC work for everyone? that's (late) evening in central Europe early afternoon in NY?
20:50:07 <count_omega> yes
20:50:33 <jamessan> Yeah, that worked fine this time.  Maybe they'll be a little shorter if we have them on a more regular basis :)
20:50:43 <f_g> last Sunday of the month would be 30th of July as next meeting
20:50:58 <ncts> do we have some ical service?
20:51:01 <f_g> jamessan: yes, 1 to at most 1,5h would be my preference/goal ;)
20:51:20 <f_g> ncts: don't think so, but I guess a reminder here and on the list a week before serves a similar purpose :)
20:51:51 <f_g> would 6pm UTC on July 30th work for everybody (present)?
20:51:59 <ncts> I can ofc set up an event on my own cal, but anyway
20:52:32 <count_omega> yeah should have time
20:53:18 <jamessan> Not for me. Week before or after would
20:54:05 <f_g> weekend before or after doesn't work for me, during the week after woul
20:54:20 <ncts> haha the reality
20:54:37 <jamessan> If it's just me, then I can read the notes :)
20:54:48 <ncts> by doesn't work you mean only sunday or the whole weekend?
20:55:08 <ncts> (I guess it's the plural)
20:55:20 <f_g> I'm out of town the weekend prior, I am on my way to the other side of the world the weekend after :)
20:55:38 <jamessan> Currently, it's just that Sunday.  VAC plans that week, starting July 30th
20:55:51 <ncts> would friday evening work?
20:56:15 <f_g> should we do the 27th or 28th? or I could also do another doodle with a deadline of end of this week, with a few suggestions around end of july/start of august
20:56:49 <jamessan> During the week is tougher, due to work, unless we did it later
20:56:59 <ncts> we could just use a team scheduling tool and choose which days are available
20:57:09 <count_omega> +1
20:57:23 <f_g> ack, I'll send out a doodle-thing tomorrow
20:57:30 <jamessan> Thanks
20:57:34 <f_g> ncts: if you have a suggestion for such a tool, drop it here, I'll take a look
20:57:47 <ncts> looks like doodle.com is such a thing
20:57:49 <f_g> #action f_g send out mail with links to meeting notes and call for finding next date
20:58:02 <f_g> with that, I'll head off to bed :)
20:58:25 <f_g> thanks for attending, and see you around!
20:58:34 <f_g> #endmeeting