19:00:40 <decathorpe> #startmeeting FESCo (2021-07-26)
19:00:40 <zodbot> Meeting started Mon Jul 26 19:00:40 2021 UTC.
19:00:40 <zodbot> This meeting is logged and archived in a public location.
19:00:40 <zodbot> The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:40 <zodbot> The meeting name has been set to 'fesco_(2021-07-26)'
19:00:46 <decathorpe> #meetingname fesco
19:00:46 <zodbot> The meeting name has been set to 'fesco'
19:00:57 <zbyszek> .hello2
19:00:58 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
19:00:58 <decathorpe> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, defolos, mboddu, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
19:00:58 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe defolos mboddu mhroncok nirik sgallagh zbyszek
19:01:01 <mboddu> .hello mohanboddu
19:01:02 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
19:01:07 <mhroncok> .hello churchyard
19:01:08 <Eighth_Doctor> .hello ngompa
19:01:09 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
19:01:11 <nirik> morning
19:01:12 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
19:01:16 <nirik> .hello kevin
19:01:17 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
19:01:26 <zbyszek> My internet has problems (there was rain today), so I might drop off at a random point…
19:01:29 <bcotton> .hello2
19:01:29 <decathorpe> #topic Init Process
19:01:29 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
19:01:36 <Eighth_Doctor> same here unfortunately
19:01:42 <Eighth_Doctor> I'm having major internet issues today
19:02:08 <zbyszek> Welcome to the XXI century.
19:02:13 <sgallagh> .hello sgallagh
19:02:14 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
19:03:05 <decathorpe> we're already quorum +2, so I'll just give the others until :04
19:03:48 <decathorpe> codonell, are you here too?
19:03:51 <codonell> I am.
19:04:20 <decathorpe> great, then let's start. I suggest we start with the libffi ticket if codonell is already here.
19:04:41 <codonell> I'm happy to answer questions. Take responsibility for wrong doings. And help :-)
19:04:48 <decathorpe> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P5KOID677ZHCIW4ULTJJIE3OUWZ6IJ4L/ Schedule
19:05:10 <decathorpe> #topic #2650 Late F35 Change: libffi 3.4
19:05:10 <decathorpe> .fesco 2650
19:05:14 <zodbot> decathorpe: Issue #2650: Late F35 Change: libffi 3.4 - fesco - Pagure.io - https://pagure.io/fesco/issue/2650
19:05:54 <mhroncok> so, the plan is to have a targeted rebuild?
19:06:01 <decathorpe> codonnel: I have one concern and one question, would be great if you could answer those
19:06:13 <codonell> decathorpe, First question then.
19:06:16 <decathorpe> oh, sory about the typo.
19:06:41 <decathorpe> question is: do you have a list of packages that will need adjustmens for libffi 3.1 -> 3.4 API changes?
19:07:47 <codonell> decathorpe, No I don't have a list of such packages. In general the API change was neutral, in that the existing users work, so long as you weren't doing something "wrong" which you could previously get away with.
19:08:04 <codonell> decathorpe, And we are *not* turning on static templates which break ghc and gobject-introspection.
19:08:14 <decathorpe> okay, that sounds good, thanks
19:08:40 <codonell> decathorpe, Does that answer your question?
19:08:45 <decathorpe> it does.
19:09:08 <codonell> decathorpe, Do you have a concern you would like to express?
19:09:54 <decathorpe> My concern is that without a rebuild of everything that links to libffi, packages might "accidentally" switch over at any point in the F35 release cycle, even after GA
19:10:39 <decathorpe> This might or might not be what we want, and might or might not introduce issues late in the release cycle
19:11:05 <decathorpe> So I'd rather rebuild all dependent packages now, so potential issues can be ironed out as soon as possible
19:11:27 <mhroncok> is it technically possible to use 2 libraries, each linked to diffrent cffi?
19:11:35 <mhroncok> I mean, from a single app
19:11:43 <mhroncok> *libffi
19:11:47 <decathorpe> mhroncok: yeah, that's a concern too.
19:11:49 <codonell> decathorpe, The cleanest solution, which also avoids two dependent libraries needing different libffi versions in a process, is to do the rebuild. However, libffi3.1 is always required to transition smoothly, and we can remove it before GA if we like.
19:12:09 <mhroncok> that really depends on whether we can do that
19:12:19 <mhroncok> if everything sucessfully builds, IMHO we should
19:12:32 <nirik> if you can quickly identify the packages that need rebuilding, we could do it with the ones that failed to be rebuilt for the mass rebuild...
19:12:35 <mhroncok> but if something fails (even for unrelated reasons), we cannot
19:12:41 <codonell> mhroncok, Yes, such a scenario is possible, but I haven't seen it in practice. The biggest user is python and it's one python in one process.
19:12:56 <mhroncok> codonell: AFAIk Python should be fine
19:13:23 <mboddu> We already have a list of pkgs that got skipped, if we have a list of packages that needs to be rebuild for libffi then we could add it to the list and run the mass rebuild
19:13:25 <codonell> So the open question is: Can we identify all users of libffi, and with that list, "fold" it into the current FTBFS rebuilds?
19:13:36 <decathorpe> nirik: nothing was built against the new libffi version during the mass rebuild, so all dependencies would have to be rebuilt
19:13:36 <nirik> mboddu: great minds think alike. ;)
19:13:49 <decathorpe> and I'd rather not get that mixed up with the mass rebuild fixup
19:14:16 <decathorpe> it's bad enough that the script just "missed" over 1000 packages
19:14:27 <nirik> ok. If we have the list tho we could just as well do them now... but whatever
19:14:27 <codonell> What can I do to help?
19:14:29 * mboddu also wants to bring up the side topic of ghc since we skipped it in the rebuild
19:14:55 <codonell> Would you like a list of all directly dependent packages?
19:15:01 <mhroncok> codonell: can you run the rebuilds, ro do you need relengetc. to do it?
19:15:04 <mhroncok> *or
19:15:11 <mhroncok> *releng/etc.
19:15:37 <codonell> I have never run rebuilds on this scale for packages I don't own.
19:16:02 <codonell> And I lack proven packager.
19:16:18 <codonell> I need to do more work for that.
19:16:19 <zbyszek> Is it just 'dnf repoquery --whatrequires libffi' ?
19:16:41 <mhroncok> not to mess up with the mass rebuild any longer, I propose we do a targeted rebuild in a side tag after the mass rebuild is done (merged)
19:16:44 <mhroncok> I can help
19:16:49 <codonell> zbyszek, That depends what you are asking me to do?
19:16:51 <decathorpe> not true: https://pagure.io/fesco/issue/2513
19:17:15 <zbyszek> codonell: I was just asking if this will generate the correct list of deps…
19:17:49 <codonell> decathorpe, Sorry, you are correct for proven packager.
19:17:50 <decathorpe> dnf yadda yadda repoquery --whatrequires "libffi.so.6()(64bit)"
19:17:55 <decathorpe> gives me 123 packages
19:17:56 <codonell> That is easy to do.
19:17:58 <codonell> I can do that.
19:18:00 <zbyszek> decathorpe: and '21 +1's', people have more faith in codonell than codonell himself
19:18:07 <sgallagh> I think the more important question is whether indirect dependencies can be affected.
19:18:08 <nirik> :)
19:18:12 <codonell> What is harder is embedded structures and the dependent packages.
19:18:16 <codonell> If they exist.
19:18:35 <codonell> I have yet to see an instance of a full libffi structure embedded in another public structure that would expose the ABI change.
19:18:52 <codonell> But this is decathorpe's concern overall during the transition.
19:18:57 <codonell> IIUC.
19:19:05 <sgallagh> When you say "embedded structure", do you mean effectively a copylib/static link?
19:19:10 <mhroncok> decathorpe: $ repoquery --repo=rawhide --whatrequires 'libffi.so.6()(64bit)' --source | pkgname | sort | uniq | wc -l
19:19:11 <mhroncok> 114
19:19:49 <codonell> sgallagh, If you place libffi structures inside another structure, and that *other* structure you pass around, that structure may grow in size, and this cascades out as ABI breakage. I mention only for completeness.
19:20:02 <codonell> e.g. struct foo { struct bar; ... }
19:20:16 <codonell> sgallagh, In practice this is not an issue.
19:20:20 <zbyszek> +1 to mhroncok's side-tag proposal
19:20:31 <sgallagh> So in short: yes, it's possible that indirect usage of this exists
19:20:44 <sgallagh> I'm not sure a side-tag is a sufficient answer in this case.
19:20:49 <decathorpe> (+1 to mhroncok's proposal as well)
19:20:51 <codonell> zbyszek, I can produce the list of all packages to rebuild and provide it to releng.
19:20:52 <mhroncok> ***mboddu also wants to bring up the side topic of ghc since we skipped it in the rebuild
19:20:56 <sgallagh> It might honestly be better to do this as part of a full mass-rebuild.
19:20:58 <zbyszek> Once we merge the tag, if there are unexpected ABI issues, we'll just need to fix/rebuild further packages. But based on what codonell is saying, this sounds unlikely.
19:21:03 <mhroncok> ghs also requires libffi
19:21:14 <codonell> ghc does require libffi.
19:21:23 <nirik> sgallagh: you want another full mass rebuild?
19:21:35 <codonell> And it works with static templates disabled. As we do with libffi 3.4.2 in F35.
19:21:42 <sgallagh> I didn't say I wanted it, I said it might be the only guaranteed-safe approach
19:21:43 <decathorpe> mboddu: ghc rebuilds should be done after libffi rebuilds then
19:21:52 <decathorpe> ?
19:22:10 <sgallagh> But I'm not hard-line on that. If a majority of FESCo is comfortable with the side-tag, I'm not going to vote no
19:22:15 <mboddu> decathorpe: Seems like it
19:22:35 * mboddu is slightly tilting towards full mass rebuild
19:22:40 <mhroncok> sgallagh: it's too late for that. and buildign just the subset in the mass rebuild tag does not bring much beenfit over doing it after
19:22:49 * nirik is fine with the sidetag.
19:22:54 <codonell> mboddu, I see no reason why ghc could not be built in the side tag also with the new libffi 3.4.2 / libffi3.1 ?
19:23:18 <codonell> ghc is one of those packages in the list of --whatrequires libffi.so.x()(64-bit)
19:23:22 <decathorpe> true, it's just the build order that's important
19:23:23 <mhroncok> we would need to do a second full mass rebuild and since mass rebuild builds don't see each other, any "recursive" rebuilds would not work either
19:23:43 <nirik> right, so it wouldn't help much in this case.
19:24:00 <mboddu> codonell: It could, but I like the "guaranteed-safe" approach since we are going to build at least 1000+ pkgs
19:24:05 <sgallagh> mhroncok: I was actually leaning towards postponing this to the F36 mass-rebuild, but as I said: it's not a strongly-held opinion
19:24:23 <mhroncok> I see
19:24:48 * decathorpe grumbles about "Very Late System-Wide Change Proposals"
19:25:12 <codonell> decathorpe, I hear you. June 28th was the libffi 3.4.2 release and we spent a lot of cycles with upstream to try get it ready earlier.
19:25:14 <mhroncok> if only we could see how many packages (from the 114) actually build before we make that decision... ?
19:25:36 <sgallagh> FWIW, our default behavior should be "reject unless there's a really compelling reason to take the risk"
19:25:45 <codonell> mhroncok, I can drive side-tag rebuilds, what would you like to see?
19:25:59 <decathorpe> codonell: that's not what mhroncok is asking
19:26:00 <nirik> mhroncok: could do a quick copr of them?
19:26:21 <mhroncok> nirik: sure.
19:26:33 <mhroncok> codonell: is libffi git rawhide HEAD the new version?
19:26:44 <decathorpe> I can run my COPR test rebuild script for libffi, if I have the candidate packages for libffi 3.4 and libffi3.1
19:26:48 <codonell> mhroncok, It is. With an exit 1 in the spec file.
19:26:56 <mhroncok> omg
19:27:13 <codonell> Hard block to prevent the mass rebuild. I forgot about the other automation blockign file :-)
19:27:28 * decathorpe grumbles about committing stuff to git that shouldn't be built
19:27:47 <mhroncok> :/
19:27:55 * mhroncok build this in copr
19:28:04 <decathorpe> mhroncok++
19:28:11 <decathorpe> can you update the tickets with the results?
19:28:17 <codonell> decathorpe, Yes, it is something I'm going to improve on in the future.
19:28:36 <codonell> decathorpe, Keeping feature branches and waiting for system-wide change requests to get approved.
19:28:52 <decathorpe> what are feature branches?
19:29:32 <zbyszek> decathorpe: any branch other than fNN or rawhide.
19:29:44 <codonell> decathorpe, I will not commit things to rawhide which are not intended to be built, but instead will keep them on another branch that is not rawhide or fNN.
19:29:52 <decathorpe> I thought those were forbidden?
19:30:08 <decathorpe> TIL
19:30:15 <zbyszek> They can be in a different repo than the main one.
19:30:16 <nirik> not blocked, but you can't remove them ever then
19:30:21 <mhroncok> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/builds/
19:30:22 <mboddu> decathorpe: They are not, you can actually make real builds from feature branches
19:30:32 <decathorpe> ew :(
19:30:41 <mboddu> ^ although its better not to do it
19:30:56 <sgallagh> Well, that's a critical piece of Modularity...
19:31:05 * codonell nods
19:31:08 <sgallagh> You can carry feature branches of different releases
19:31:14 <nirik> well, those are 'stream' branches IIRC
19:31:15 <decathorpe> Super-Ew :)
19:31:27 <sgallagh> nirik: Potato potahto
19:32:12 * nirik wonders where we are here? waiting for the copr builds?
19:32:13 <decathorpe> Okay ... Proposal: Wait for results of COPR rebuilds against libffi 3.4, vote in ticket. If libffi 3.4 is approved for F35, then do libffi rebuilds and then GHC rebuilds in a side tag. If libffi 3.4 is not approved, do only GHC rebuilds in side tag.
19:32:15 <codonell> mhroncok, Is there anything I can do to help?
19:32:28 <mboddu> nirik: In modularity terms they are called stream branches, in rpm terms, they are called feature branches
19:32:40 <mhroncok> mboddu: rpm does not know branches :D
19:33:00 <mhroncok> codonell: depends on the results
19:33:27 <zbyszek> decathorpe: what about the copr build results? Is there some critical failure percentage where the feature is rejected for F35?
19:33:28 <mhroncok> decathorpe: +1
19:33:30 <mboddu> mhroncok: rpm maintainer does ;P
19:33:52 <nirik> decathorpe: +1
19:33:59 <mhroncok> I'll bring the list of failures to the ticket, we can discuss then
19:34:07 <codonell> That sounds good to me.
19:34:19 <decathorpe> yeah, failures in ticket sounds good. we can discuss options then.
19:34:20 <mboddu> decathorpe: Who is going to run the side tag rebuild? mhroncok or releng or both?
19:34:29 <mhroncok> I can do it
19:34:37 <zbyszek> decathorpe: +1 too
19:34:51 <mboddu> mhroncok: Okay, please let me know if you need any help
19:34:54 <mhroncok> if it can go trough bodhi :)
19:35:07 <mhroncok> if we want to bypass gating, I will need releng
19:36:05 <decathorpe> can bodhi handle updates with ~1000 builds?
19:36:46 <mhroncok> decathorpe: 114
19:36:51 <mboddu> mhroncok: Sure, maybe rather than using `fedpkg request side-tag` lets create a side tag that doesn't autogenerate the buildroot for every build, like the mass rebuild side tag
19:37:07 <mhroncok> mboddu: I need the buildroot regenrated
19:37:24 <decathorpe> mhroncok: if we build GHC in there too, then it's a lot more packages.
19:37:37 <mhroncok> for packages that require libffi and (other packages that require libffi)
19:37:37 <decathorpe> but we can use two side tags one after the other too
19:37:48 <mhroncok> decathorpe: I do not wish to mic the two
19:37:55 <mhroncok> *mix
19:38:09 <decathorpe> sounds good to me
19:38:11 <mboddu> mhroncok: Why? After libffi build, generate the buildroot and then build ghc, generate buildroot and rebuild everything (maybe its too manual, but it will save some koji cycles, esp for 1000+ pkgs)
19:38:38 <mhroncok> I do not volunteer to rebuild ghc
19:39:16 <decathorpe> ok ... then we use an "on-demand side-tag" for the libffi builds, and a releng-managed side tag for GHC?
19:39:35 <nirik> the ghc maintainer already said they would do a side tag
19:39:35 <mboddu> decathorpe: Okay, I will work with petersen about ghc stuff
19:40:00 <mhroncok> just make sure to start ghc after libffi is done
19:40:15 <mboddu> ^ needs to informed to petersen
19:40:42 <codonell> mhroncok, How long does the COPR build usually take to get results on package failure rates?
19:40:48 <decathorpe> mboddu, sgallagh, ngompa, do you want to vote on my proposal (with the clarification of using two side tags)?
19:40:52 <mboddu> mhroncok: I will give him a heads up, once libffi is done, let him know about it so that he can start his rebuild
19:40:53 <mhroncok> codonell: depedns ont he slowest packages
19:41:03 <mhroncok> codonell: I see pypys there, that'll be couple hours
19:41:12 <mhroncok> mboddu++
19:41:13 <Eighth_Doctor> Fabio Valentini (decathorpe): +1
19:41:13 <zodbot> mhroncok: Karma for mohanboddu changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:41:13 <sgallagh> I don't think it needs a vote, really.
19:41:16 <sgallagh> But sure, +1
19:41:26 <Eighth_Doctor> I think we're overcomplicating things, but ehh
19:41:57 <decathorpe> mboddu?
19:41:59 * Eighth_Doctor grumbles that we should have auto reverse-dep rebuild+submit to deal with this grunge work
19:42:06 <mboddu> Sure, +1
19:42:07 <zbyszek> Yeah, we're making this more complex than we should.
19:42:25 <decathorpe> ok, I'd like to move on to the next topic.
19:43:09 <decathorpe> #info Wait for COPR test builds against libffi 3.4, and vote in ticket after mhroncok gets us results
19:43:14 <nirik> thanks for coming codonell!
19:43:19 <codonell> Happy to help :-)
19:43:31 <decathorpe> #info If approved, do libffi rebuilds in an on-demand side tag, and ghc rebuilds in another side tag after that
19:43:34 <mboddu> Thanks codonell
19:43:47 <mhroncok> the results should be in by tmrw
19:43:48 <decathorpe> #info (Vote was: +7, 0, -0)
19:43:49 <Eighth_Doctor> thanks for coming by codonell
19:44:10 <decathorpe> yes, thanks for coming. I did not anticipate this topic to take so long :(
19:44:30 <codonell> decathorpe, People have feelings, and their feelings are real :-)
19:44:44 <bcotton> Nobody expects the libffi inquisition
19:44:55 <decathorpe> #topic #2636 Nonresponsive maintainer: Conrad Meyer (@konradm)
19:44:57 <decathorpe> .fesco 2636
19:44:58 <zodbot> decathorpe: Issue #2636: Nonresponsive maintainer: Conrad Meyer (@konradm) - fesco - Pagure.io - https://pagure.io/fesco/issue/2636
19:45:08 <mhroncok> obviously, ghc fails, because 8.10 is commited
19:45:15 <decathorpe> mhroncok: you added this to the schedule, your topic
19:45:24 <mhroncok> yeah
19:45:38 <mhroncok> I think as fesco, we should do something
19:45:41 <mhroncok> but I don'T know what
19:46:00 <Eighth_Doctor> what do we do in this situation?
19:46:05 <mhroncok> the issue is open for ~3 weeks
19:46:26 <sgallagh> I previously suggested that we just orphan Conrad's packages, announce it and see what gets picked up or retired
19:46:41 <mboddu> ^ +1
19:46:51 <sgallagh> If he picks them up himself and doesn't do anything with them, revoke his packager status and orphan them again
19:46:59 <Eighth_Doctor> I'm fine with that approach +1
19:47:11 * nirik reads up again on it
19:47:28 <decathorpe> that might be the simplest approach ... leaving bugs un-fixed for years is not a good look
19:47:31 <zbyszek> Hmm, but why? Didn't he add Larry as a co-maintainer?
19:47:57 <mhroncok> there are soem new comments in bugzilla
19:48:37 <mhroncok> https://bugzilla.redhat.com/show_bug.cgi?id=1729652#c28
19:48:39 <decathorpe> looks like dcantrell stepped up to be co-maintainer?
19:48:40 <mhroncok> based on ^
19:48:49 <nirik> yeah
19:48:50 <mhroncok> maybe we should close this?
19:49:05 <nirik> dcantrell (who I think is on pto) should be able to push something fixing it?
19:49:27 <zbyszek> s/Larry/David/
19:49:38 <mhroncok> let's ask the reporter if https://bugzilla.redhat.com/show_bug.cgi?id=1729652#c28 is a satisfactory resolution of this ticket?
19:49:52 <decathorpe> sounds good
19:50:13 <zbyszek> yeah
19:50:19 <nirik> +1
19:50:44 <mhroncok> ok, that's it for the topic, sorry for bringing it here, I could have figuret this out async :D
19:50:52 <mboddu> +1
19:51:07 <decathorpe> #info We will update the ticket and ask submitter if they are satisfied.
19:51:17 <decathorpe> #topic #2646 update meeting process
19:51:21 <decathorpe> .fesco 2646
19:51:22 <zodbot> decathorpe: Issue #2646: update meeting process - fesco - Pagure.io - https://pagure.io/fesco/issue/2646
19:51:48 <decathorpe> I tried to follow the proposed rules for today's meeting, and it looks like they worked fine
19:52:03 <zbyszek> decathorpe++
19:52:14 <nirik> yep. :)
19:52:35 <decathorpe> I'm not sure which documents would need updating, though.
19:52:49 <zbyszek> +1 to the proposal in https://pagure.io/fesco/issue/2646#comment-743791
19:53:01 <nirik> I think just the meeting process wiki page?
19:53:12 <decathorpe> yeah, FESCo meeting process is a wiki page, that should be easy
19:53:18 <decathorpe> and are there docs for the Change process?
19:53:26 <nirik> ah, not sure there... bcotton ?
19:53:35 <nirik> or we could ask bcotton to cc them when making the fesco ticket?
19:53:38 <bcotton> of course there are :-)
19:53:56 <mhroncok> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
19:54:06 <bcotton> nirik: the change owners are mentioned in the ticket, but i cannot subscribe them
19:54:07 <zbyszek> bcotton: it was a rhetorical question obviously, we would never dare doubt
19:54:19 <bcotton> zbyszek:  :-D
19:54:31 <bcotton> (let's not ask about spins docs, then)
19:54:59 <decathorpe> The docs can recommend that change owners subscribe to the tickets for their changes, though.
19:55:46 <decathorpe> (unless somebody wants to implement pagure API to subscribe users to tickets? *wink)
19:55:47 <nirik> bcotton: spins process: see change process. :)
19:57:15 <bcotton> https://pagure.io/fedora-pgm/pgm_docs/issue/6
19:57:29 <bcotton> ^ coming to documentation near you in 2021!
19:57:40 <decathorpe> great, thanks!
19:57:41 <mboddu> What happens if you assign the ticket? Does it make the assignee to subscribe to the ticket?
19:58:38 <bcotton> ooh, that's a possible approach. it doesn't work when there are multiple change owners, but at least there's someone
19:58:46 <nirik> I don't think that works, but I could be mistaken
19:58:53 <decathorpe> Can the assignee be somebody outside FESCo?
19:59:31 <decathorpe> well, but that's something that's at least easy to check.
19:59:46 <mhroncok> decathorpe: they can
19:59:53 <mboddu> decathorpe: Yeah, that should work
19:59:56 <decathorpe> oh, that's good, then :)
20:00:38 <zbyszek> I think we're trying to find a technical solution to a social problems. Let's adjust the docs to ask people to subscribe and move on.
20:00:40 <decathorpe> #agree APPROVED Updated Meeting Process (+5, 0, -0)
20:00:59 <decathorpe> #topic Next Week's Chair
20:01:23 <decathorpe> any victi ... err, volunteers?
20:02:12 <decathorpe> (I really don't want to do this a third time in a row)
20:02:34 <zbyszek> decathorpe: OK, sign me up.
20:02:48 <mhroncok> zbyszek: don't forget to show up :D
20:03:03 <zbyszek> mhroncok: right
20:03:05 <decathorpe> thanks!
20:03:07 <decathorpe> #action zbyszek to show up and chair next week's meeting
20:03:11 <decathorpe> #topic Open Floor
20:03:56 <decathorpe> (going to close at :05 if there's nothing)
20:04:01 <nirik> ok, assigning does appear to work, FWIW
20:04:53 <decathorpe> nice, that simplifies things
20:05:32 <decathorpe> sorry for running slightly long. let me give you back -5 minutes each ;)
20:05:38 <decathorpe> #endmeeting