15:00:00 <contyk> #startmeeting FESCO (2019-06-28)
15:00:00 <zodbot> Meeting started Fri Jun 28 15:00:00 2019 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2019-06-28)'
15:00:03 <contyk> #meetingname fesco
15:00:03 <zodbot> The meeting name has been set to 'fesco'
15:00:05 <contyk> #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:05 <zodbot> Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:07 <contyk> #topic init process
15:00:10 <contyk> .hello psabata
15:00:11 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:13 <ignatenkobrain> .hello2
15:00:14 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:00:18 <nirik> morning
15:01:02 <mhroncok> hey
15:01:02 <bcotton> .hello2
15:01:03 <sgallagh> .hello2
15:01:04 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:07 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:10 <bookwar> .hello2
15:01:11 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:25 <contyk> ok, we have quorum
15:01:33 <jforbes> .hello2
15:01:34 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:02:05 <contyk> alrighty
15:02:22 <contyk> #topic #2152 "backport" branches in src.fp.o for backports to coreos stable streams
15:02:24 <contyk> .fesco 2152
15:02:26 <contyk> https://pagure.io/fesco/issue/2152
15:02:26 <zodbot> contyk: Issue #2152: "backport" branches in src.fp.o for backports to coreos stable streams - fesco - Pagure.io - https://pagure.io/fesco/issue/2152
15:03:07 <contyk> dustymabe: are you around?
15:03:18 <zbyszek> .hello2
15:03:19 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:03:56 <dustymabe> .hello2
15:03:57 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
15:03:59 <dustymabe> contyk: here
15:04:04 <contyk> cool
15:04:05 <dustymabe> thanks for the ping
15:04:10 <contyk> seems like mhroncok isn't around today
15:04:15 <mhroncok> I am
15:04:28 <contyk> oh right, need to enlarge the window
15:05:03 <contyk> so I see you two continue the discussion in the ticket
15:05:08 <contyk> any highlights?
15:05:24 <mhroncok> I think we have an idea and need to see how tehcnically possible it is
15:05:29 * nirik isn't sure about the tag workflow. Can't you move tags?
15:05:44 <contyk> you can't move them in our infra
15:05:54 <mhroncok> nirik: you can, only if you can --force
15:05:55 <contyk> I can't recall the reason but it's explicitly forbidden
15:05:56 <dustymabe> nirik: yes you can. in src.fp.o
15:06:02 <contyk> hmm
15:06:12 <dustymabe> should we be allowed to? I don't know
15:06:14 <nirik> I'm not sure thats true... well, depends on the kind of tag...
15:06:25 <nirik> annotated tags I think you can move without force...
15:06:46 <nirik> or lightweight. I forget which is which
15:07:32 <dustymabe> so I think we *could* use tags
15:07:42 <dustymabe> but I think we should probably formalize it if we go that route
15:07:55 <dustymabe> one thing I brought up in the ticket is ACLs
15:08:05 <mhroncok> [fedora-productimg-cloud (master)]$ git push origin  --delete test
15:08:05 <mhroncok> remote: Branch deletion is not allowed
15:08:06 <mhroncok> remote: Denied push for ref 'refs/tags/test' for user 'churchyard'
15:08:06 <mhroncok> remote: All changes have been rejected
15:08:06 <mhroncok> To ssh://pkgs.fedoraproject.org/rpms/fedora-productimg-cloud
15:08:06 <mhroncok> ! [remote rejected] test (pre-receive hook declined)
15:08:06 <mhroncok> error: failed to push some refs to 'ssh://churchyard@pkgs.fedoraproject.org/rpms/fedora-productimg-cloud'
15:08:37 <mhroncok> and I'm a provienpackager and now also cvsadmin
15:08:37 <dustymabe> i.e. if we use branches then certain people could be given access, not sure if we can do that with tags
15:09:10 <ignatenkobrain> dustymabe: we actually don't have this feature with branches either
15:09:12 <mhroncok> dustymabe: we don't have per branch access
15:09:14 <zbyszek> Generally we should use branches if we expect the set of commits to change, and we can consider a tag if that set is immutable.
15:09:36 <mhroncok> so you have the same problem. easiest solution is to get provenpackagers on the team ro become provenpackagers
15:09:37 <zbyszek> So the questions becomes whether we ever expect to add new commits to coreos-backport-foo branch?
15:10:02 <mhroncok> zbyszek: in the original proposal yes
15:10:02 <bookwar> zbyszek: you never expect this, but sometimes tou need to fix a hotfix )
15:10:09 <bookwar> you*
15:10:12 <mhroncok> but for the tags, each tag would only be used once and than never reused
15:10:32 <zbyszek> But in this case it seems more natural to use branches.
15:10:48 <mhroncok> and we are back at the UI
15:10:51 <mhroncok> or even UX
15:10:56 <dustymabe> correct. if we use branches then the branches would change
15:11:09 <dustymabe> if we use tags we can name them uniquely and use one for eeach backport
15:11:13 <mhroncok> and we are back at the merge x merge mess
15:11:20 <zbyszek> No.
15:11:24 <mhroncok> no?
15:11:39 <zbyszek> Yeah, so I think the simplest solution of opening a new branch for each backport stream doesn't require any merges.
15:11:48 <jforbes> We do kernel stabilization branch without merge commits
15:12:14 <nirik> well, it will if you reuse it no? or you push a revert commit for your changes and merge back the main branch?
15:12:31 <bookwar> i believe that branches should be unique branches, and problem of having too many old/unused branches should be resolved differently, by "archiving" the branch, and by fixing the ui in pagure to show namespaces for branches
15:12:41 <zbyszek> bookwar: +1
15:12:58 <zbyszek> nirik: yes, I don't think we should "reuse" branches for unrelated stuff
15:13:23 <mhroncok> -1 to reusing branches
15:13:44 <contyk> I'd be fine with reusing branches, personally
15:13:47 <contyk> it depends on how you look at it
15:13:49 <mhroncok> -1 to polluting the repos with increasing number of custom branches
15:14:03 <jforbes> I am also -1 to a bunch of useless branches, as a maintainer of one of the packages this is most likely to touch
15:14:15 <mhroncok> if we can move the branches to a nondefault refs space, good
15:14:32 <nirik> well, we get back to how often this will get used... which is a bit unknown....
15:14:34 <jforbes> Sure, if we could archive, I might reconsider
15:14:36 <zbyszek> Dunno, large number of branches are not such a big problem, I think.
15:14:38 <zbyszek> git branch -a|wc
15:14:39 <zbyszek> 1881
15:14:51 <zbyszek> (In my systemd repo.)
15:14:54 <zbyszek> I don't think I care.
15:14:58 <dustymabe> zbyszek: the tools support it, but people do care
15:15:06 <mhroncok> I care
15:15:26 <zbyszek> Well, then use a unique prefix for the coreos stuff that doesn't cause tab-completion conflicts.
15:15:26 <mhroncok> I have hundreds of branches in my forks or locally, but I keep origin tidy
15:16:01 <zbyszek> OK, so what we set the default clone pattern in dist-git to *not* include the coreos branches?
15:16:01 <mhroncok> however we get into my workflow vs. your workflow
15:16:02 <ignatenkobrain> I think I am fine with reusing branches because there is always only 2 (at max) branches at the same time
15:16:04 <bookwar> mhroncok: there is a difference between "custom" branches, and real branches which were used to release a product
15:16:12 <bookwar> this backport-* branches are real
15:16:22 <bookwar> they deserve their space in the origin
15:16:24 <jforbes> In kernel repo, we have actually addressed every single person who has created an unnecessary branch, and asked them not to ever again
15:16:34 <mhroncok> yet resuing them makes no sense, those are "dead end" branches
15:16:48 <dustymabe> jforbes: in dist-git ?
15:16:52 <jforbes> yes
15:16:59 <dustymabe> you can disallow pushing to create a branch now in pagure
15:17:03 <mhroncok> yes
15:17:09 <jforbes> Yeah, we turned that on when it was available
15:17:11 <dustymabe> +1
15:18:01 <bookwar> jforbes: again, i'd argue what you call "unnecessary". The backport-branch here is not a pull request from someone, it is a release branch.
15:18:16 <contyk> I think the question is whether we focus on the deliverble or the backport in question
15:18:20 <jforbes> I am just saying, realistically, core-os touches a pretty small subset of packages. this is most likely to be used on our package more than any other.
15:18:28 <dustymabe> jforbes: correct
15:18:33 <contyk> if it's the deliverable, re-using branches is fine, much like we "reuse" master for rawhide
15:18:42 <dustymabe> there are very few packages that bump version in the middle of a release
15:18:58 <dustymabe> those are the ones that will most likely require a backport occasionally
15:19:05 <dustymabe> others, probably not so much
15:19:17 <jforbes> Right, so this is a kernel question, not really a rest of the world question
15:19:40 <dustymabe> jforbes: it primarily applies to the kernel, but could possibly happen somewhere else
15:19:44 <dustymabe> probably very rarely
15:19:52 <zbyszek> python upgrades from 3.x.y to 3.x.z during releases...
15:19:56 <mhroncok> contyk: we "reuse" master because rawhide is rolling forward
15:20:00 <dustymabe> zbyszek: we removed python from FCOS
15:20:09 <nirik> so could this be solved by coordination? ie, asking for a delay in a rebase to aline with coreos release?
15:20:18 <contyk> mhroncok: so is coreos
15:20:35 <mhroncok> contyk: we don't "revert a commit, merge some other branch, commit, revert that commit..."
15:20:55 <jforbes> mhroncok: we don't do that with stabilization either. We never revert, we never merge
15:21:04 <jcline> I'm a little confused about that, I never merge in dist-git
15:21:04 <mhroncok> I still thing that the build from a tag approach is easiest and creates less mess
15:21:06 <dustymabe> nirik: possibly, but we'd like to A) not ask maintainers to do anything extra or special for coreos specifically B) not be blocked if we need something soon
15:21:20 <mhroncok> *think
15:22:48 <nirik> perhaps kernel and coreos folks could meet and try and come up with something that works for both of them?
15:22:59 <contyk> nirik: +1
15:23:13 * nirik is fine with the branches, or tags if we test out that they can't be moved around...
15:23:33 <dustymabe> jforbes: correct me if I'm wrong, but we've already talked with the kernel team in the past about needs like this
15:24:01 <dustymabe> that is one of the reasons bgilbert can now build kernels himself (i.e. you need special perms for that)
15:24:02 <jforbes> We did, a while ago when we got them permission to build secureboot builds. We agreed to having a single (or if absolutely necessary a 2nd) branch which was reused
15:24:18 <dustymabe> right, thanks jforbes
15:25:02 <contyk> so you think re-using branches would be the optimal solution?
15:25:08 <jforbes> For us, yes
15:25:28 <ignatenkobrain> FTR, I'm in favor of using branches and reusing them. Creating multiple branches seems like overengineered work. If no reuse, I would prefer tags.
15:25:48 <ignatenkobrain> Using tags might be complicated due to fedpkg support of detached HEAD
15:25:51 <dustymabe> yeah I think I prefer unique tags, then re-used branches
15:26:30 <jforbes> If I could delete the 25 unnecessary branches in kernel I would
15:26:37 <mhroncok> ignatenkobrain:  fedpkg support of detached HEAD should be easy
15:26:39 <dustymabe> jforbes: :)
15:26:58 <dustymabe> mhroncok: yeah. I commented out a few lines in the code and got it to work
15:27:03 <mhroncok> nirik: we cannot  move tags
15:27:14 <dustymabe> mhroncok: i think we can
15:27:18 <dustymabe> i did it the other day
15:27:19 <mhroncok> dustymabe: how?
15:27:22 <dustymabe> you can't delete one
15:27:25 <contyk> I'm fine with tags and re-used branches, too
15:27:30 <jforbes> So, for koji builds for test day, where we need stabilization built against a real release for secureboot purposes 'koji build --dist f30' works fine
15:27:31 <dustymabe> but you can move it to a new commit
15:27:57 <dustymabe> jforbes: i.e. you don't need fedpkg ?
15:28:22 <jforbes> dustymabe: no
15:28:39 <jforbes> err, wait, yes... dedpkg build --dist f30
15:28:39 <contyk> well, moving tags is like using a branch, what's the issue?
15:29:00 <mhroncok> dustymabe: https://pagure.io/fesco/issue/2152#comment-580019
15:29:24 <dustymabe> jforbes: here is my real world experience: https://pagure.io/fesco/issue/2152#comment-579649
15:29:39 <nirik> I guess it no longer matters... koji used to only record the thing passed it... ie, you could pass it HEAD and then you don't know what that is later... but I am pretty sure we fixed that so it records the actual hash...
15:29:48 <zbyszek> mhroncok: and if you try with --force ?
15:29:54 <contyk> nirik: indeed
15:30:11 <dustymabe> mhroncok: right. I forced it
15:30:20 <contyk> it doesn't matter whether you can move tags or not
15:30:21 <nirik> Extra	{'source': {'original_url': 'git+https://src.fedoraproject.org/rpms/kernel.git#7addfa8f743d3685d2c93c38a992699f0b7645c2'}}
15:30:24 <mhroncok> ok, it can be forced, at least forward
15:31:13 <mhroncok> but not backwards: remote: Forced pushes are not allowed
15:31:21 <jforbes> fedpkg --dist f30 build
15:31:21 <jforbes> Could not execute build: Package kernel-5.1.4-300.fc30 has already been built
15:31:22 <mhroncok> my head hurts, but this is safe
15:31:34 <mhroncok> BTW we are on this for  along time
15:31:35 <jforbes> But that would work if we hadn't already built it for test week
15:31:45 <zbyszek> Proposal: fix koji to work with tags, and use unique tags for the coreos backport streams
15:32:02 <contyk> zbyszek: koji can't work with tags?
15:32:06 <jforbes> zbyszek: it isn't necessary
15:32:09 <nirik> one downside of tags is less visibility for users... it's harder to see where the kernel they run is...
15:32:19 <ignatenkobrain> I think whatever involves with "fix koji" will take forever
15:32:20 <nirik> we are ok with tags now.
15:32:26 <nirik> koji is already fixed.
15:32:34 <zbyszek> Proposal: use unique tags for the coreos backport streams
15:32:47 <contyk> I would even use the same tag
15:32:48 <jforbes> zbyszek: koji will point to the commit, what is the point?
15:32:52 <contyk> why do they need to be unique?
15:33:08 <zbyszek> Proposal: use tags for the coreos backport streams
15:33:11 <contyk> :)
15:33:12 <dustymabe> contyk: git could garbage collect a commit
15:33:14 <mhroncok> becasue you don't want to revert and merge and whatnot
15:33:24 <dustymabe> there needs to be a reference to it somewhere
15:33:27 <mhroncok> zbyszek: +1
15:33:37 <contyk> dustymabe: this is a valid point
15:33:50 <mhroncok> that's why you need the tag r branch
15:33:59 <mhroncok> *tag or branch
15:34:01 <zbyszek> dustymabe: as mhroncok showed, you can't move a tag back, so the ref cannot be garbage collected.
15:34:04 <contyk> mhroncok: this I don't understand; if I can move the tag, it doesn't matter
15:34:15 <mhroncok> contyk: what part doesn't matter?
15:34:25 <jforbes> https://koji.fedoraproject.org/koji/buildinfo?buildID=1266753 This was a build for a test day kernel
15:34:27 <contyk> merging and reverting
15:34:39 <mhroncok> contyk: it matters becasue you can onyl move tag forward
15:34:52 <dustymabe> re: merging/reverting - we'd prefer not to do that because the history is really ugly
15:35:09 <mhroncok> so in order to reuse tag, you would need to revert + merge
15:35:13 <mhroncok> it's super ugly
15:35:21 <dustymabe> if we need a new backport we'd prefer to start with the commit that need to apply the backport to, add one commit on top (with fix) and then tag that
15:35:28 <contyk> well, if you think that's a real scenario
15:35:28 <mhroncok> exactly
15:35:36 <zbyszek> Yeah, that's why it'd be reasonable to use a new tag.
15:35:37 <contyk> then whoever builds will have to always specify the tag name
15:35:58 <zbyszek> But I don't think we need to decide this here, it can be decided by whomever is creating the tag.
15:36:05 <zbyszek> s/creating/using/
15:36:08 <dustymabe> no they'll just need to git checkout tag in the repo and do fedpkg --release f30 build
15:36:18 <dustymabe> right
15:36:22 <contyk> but you need to know what to check out, is my point
15:36:27 <contyk> instead of just using the same name
15:36:28 * nirik is ok with tags now... as long as kernel folks are ok with it.
15:36:31 <dustymabe> contyk: i'm creating the commit so it's simple
15:36:40 <contyk> okay
15:36:50 <contyk> so let's get to vote, I'll restate the proposal from zbyszek
15:37:08 <contyk> proposed #agreed Let's use unique tags for the coreos backport streams
15:37:10 <jforbes> kernel is fine with the workflow we agreed to months ago
15:37:15 <dustymabe> Proposal: use unique tags for coreos backport streams, don't overwrite or move tags
15:37:41 <zbyszek> Before voting, let's clarify this one thing.
15:37:43 <contyk> dustymabe: is that patch required?
15:37:45 <nirik> jforbes: but not tags? or you would want to think about it?
15:37:49 <mhroncok> propsal: use tgas, do whatever you want with them
15:38:03 <dustymabe> contyk: patching fedpkg is not required (can be done client side), but it would be nice to do
15:38:05 <jforbes> I don't care either way about tags, we don't use them
15:38:18 <contyk> dustymabe: I mean your patch to the proposal
15:38:30 <contyk> about moving or overwriting; koji records the commit hash
15:38:50 <dustymabe> contyk: oh, yeah it's not required, it's just something we agree to do
15:38:56 <dustymabe> i.e. good practice
15:39:06 <zbyszek> contyk: +1, dustymabe: -0
15:39:17 * nirik is +1 to dustymabe's last. Or mhroncok's last.
15:39:42 * mhroncok could agree to both as well
15:39:56 <contyk> ok, so apparently we're voting on three proposals
15:40:07 <zbyszek> brexit!
15:40:13 <jforbes> =1
15:40:14 <nirik> proposals are great! Everyone should have one!
15:40:23 * sgallagh considers adding "Proposal: start yak farm"
15:40:31 * dustymabe is happy if the moderator would like to take over and make an official proposal
15:40:36 <bcotton> sgallagh: +1
15:40:43 <contyk> we established the tags need to be unique because of the gc
15:40:44 <zbyszek> dustymabe: yep
15:40:45 <sgallagh> jforbes: Was that a typo or a joke?
15:40:45 <nirik> yak++
15:40:47 <contyk> I'd rather keep that in
15:41:04 <ignatenkobrain> +1 to unique tags
15:41:04 <contyk> at the same time I wouldn't want to make the proposal overly specific and include best practices
15:41:07 <zbyszek> contyk: no, they don't need to.
15:41:17 <jforbes> sgallagh: typo, but both
15:41:21 <sgallagh> :)
15:41:37 <zbyszek> contyk: dist-git only allows tags (and branches) to move forward, so no ref can be ever lost.
15:42:02 <mhroncok> so if  a build fails, you could push a fix commit and move that tag forward
15:42:15 <dustymabe> zbyszek: I didn't know that.. but thanks for clarifying
15:42:29 <dustymabe> when I 'moved the tag' it was to a later commit with the same history
15:42:31 <sgallagh> zbyszek: That can't be true
15:42:34 <zbyszek> mhroncok: yeah, that's a good argument against never moving tags. We need to treat them a bit like branches.
15:42:37 <contyk> so the commits used to build things shipped in the past wouldn't be gc'd if I move the tag elsewhere?
15:42:41 <contyk> that was my concern
15:42:43 <mhroncok> and if you actually wan to play revert/merge games, you can already do that on master as well, so I think we are good allowing naything
15:42:49 <sgallagh> I've definitely rewritten history (pushed a fixup) and moved the tag to the new version
15:42:52 <mhroncok> contyk: they won't
15:43:27 <zbyszek> sgallagh: if you move a tag to a child (later commit), you keep a reference to all ancestors.
15:43:29 <jforbes> contyk: the commits never get gc'd, only the actual rpms
15:43:44 <contyk> what if I tag a detached commit?
15:43:52 <jforbes> contyk: I can look at very old test day builds and still see what commit they were built against
15:43:57 <contyk> and then move the tag to another one in a branch or another detached commit?
15:43:58 <mhroncok> contyk: than you push the tags with all it's ancestros
15:43:59 <zbyszek> contyk: that doesn't make any difference
15:44:06 <mhroncok> contyk: you can only move forward
15:44:14 <contyk> okay
15:44:16 <mhroncok> that includes references to all the ancestors
15:44:21 * sgallagh stops trying to understand git
15:44:34 <sgallagh> I'll accept that it's basically magic.
15:44:44 <contyk> okay, another attempt then
15:44:47 <mhroncok> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space
15:45:02 <bookwar> proposal "reuse of branches is discouraged, CoreOS will use unique tags for backports and will not do any git magic while doing so"
15:45:05 <contyk> proposed #agreed Let's use tags. The exact workflow is up to the CoreOS team.
15:45:14 <mhroncok> contyk: +1
15:45:15 <nirik> mhroncok++ great!
15:45:25 <ignatenkobrain> +1
15:45:32 <mhroncok> warning, 2 proposals here
15:45:39 <contyk> please, vote on just one
15:45:42 <mhroncok> ignatenkobrain: make sure you specifiy what are you voting at
15:45:43 <contyk> mine, since I'm the chair :P
15:45:47 <nirik> contyk: +1
15:45:50 <jforbes> contyk +1
15:45:54 <dustymabe> contyk: +1
15:46:02 <mhroncok> contyk: also since it's better :D
15:46:03 <sgallagh> mhroncok: Honestly, I can't tell if you're joking or not :-(
15:46:05 <ignatenkobrain> contyk: +1
15:46:19 <bookwar> contyk: +1, it is the same actually
15:46:20 * dustymabe realizes his vote doesn't count
15:46:31 <mhroncok> sgallagh: I am, that is total bollocks
15:46:39 <zbyszek> contyk: +1
15:46:50 * sgallagh was kidding
15:47:01 <jforbes> dustymabe: perhaps not in an official capacity, but if coreos was against the proposal that would definitely need consideration :)
15:47:03 <contyk> sgallagh: voting?
15:47:11 <sgallagh> Considering.
15:47:33 <zbyszek> sgallagh: see https://git-man-page-generator.lokaltog.net/ after the meeting
15:47:40 * dustymabe has a followup quick question after this passes
15:47:43 <sgallagh> contyk: +1
15:47:48 <mhroncok> I like http://think-like-a-git.net/
15:47:52 <contyk> #agreed Let's use tags. The exact workflow is up to the CoreOS team. (+8, 0, -0)
15:48:12 <contyk> cool
15:48:14 <contyk> #topic #2145 python2 packaging exception for python2-soupsieve, python2-css-parser
15:48:16 <contyk> .fesco 2145
15:48:17 <zodbot> contyk: Issue #2145: python2 packaging exception for python2-soupsieve, python2-css-parser - fesco - Pagure.io - https://pagure.io/fesco/issue/2145
15:48:18 <contyk> https://pagure.io/fesco/issue/2145
15:48:44 <nirik> +1
15:48:53 <mhroncok> +1 in the ticket
15:49:02 <nirik> (disclaimer: I am a calibre maintainer)
15:49:16 <contyk> +1
15:49:16 <dustymabe> i'll ask my followup question in open floor or in the ticket
15:49:18 <mhroncok> (disclaimer: I am a Python 2 deletionist)
15:49:21 <sgallagh> +1
15:49:29 <jforbes> +1
15:49:34 <ignatenkobrain> +1 in the ticket
15:49:37 <zbyszek> I'll not vote, since it's my proposal...
15:49:38 <sgallagh> (disclaimer: I am a Python 2 arsonist)
15:49:38 <nirik> the python3 port is coming along... we need some new python3 packages and it needs a lot more testing.
15:49:52 <zbyszek> ... but I'll say that calibre on python3 mostly runs without issue.
15:49:54 <contyk> bookwar: ?
15:49:58 <bookwar> +1 too
15:50:19 <sgallagh> I'm happy to hear that the Calibre author is back on their meds.
15:50:22 <contyk> #agreed python2 packaging exception for python2-soupsieve, python2-css-parser is approved (+7, 1, -0)
15:50:25 <nirik> zbyszek: we are still needing a few packages right?
15:50:26 <mhroncok> sgallagh++
15:50:26 <zodbot> mhroncok: Karma for sgallagh changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:50:33 * nirik needs to catch up on that
15:50:40 <sgallagh> (Maintaining all of Python 2 just for one project seemed ridiculous to me)
15:50:51 <zbyszek> nirik: no, I think we're all good right now. Just need to do dist-git imports after the ticket is accepted.
15:50:55 <contyk> #topic Next week's chair
15:51:19 <zbyszek> ignatenkobrain hasn't done it for a while ;)
15:51:22 <contyk> so
15:51:26 <sgallagh> Thursday is a US holiday next week, so there's a good chance that US folks will take Friday off. (I am, for instance)
15:51:28 <contyk> it's a holiday week
15:51:43 * nirik was thinking of doing the same
15:51:44 <contyk> that, plus the Friday is a holiday in CZ
15:52:05 <sgallagh> Quorum seems unlikely to me
15:52:19 <contyk> proposal: the next meeting will be held on July 12
15:52:26 <jforbes> +1
15:52:26 <zbyszek> contyk: +1
15:52:28 <nirik> +1
15:52:29 <sgallagh> +1
15:52:34 <ignatenkobrain> I will be around, but I guess we won't get quorum
15:52:39 <ignatenkobrain> contyk: +1
15:52:43 <mhroncok> contyk: +1
15:52:59 <contyk> #info The next FESCo meeting will be held on July 12
15:53:08 <contyk> so, any volunteers? ignatenkobrain? :)
15:53:14 <sgallagh> Oh, actually.
15:53:15 <zbyszek> contyk: what about "agreed" for the previous ticket?
15:53:15 <ignatenkobrain> sure
15:53:28 <sgallagh> We may want to discuss the ticket I opened about the meeting time first
15:53:32 <ignatenkobrain> but please send me some link to the wiki which describes fesco meeting process :)
15:53:34 <mhroncok> i can chair July 12 meeting
15:53:34 <contyk> zbyszek: I think I posted it
15:53:35 <ignatenkobrain> that boilerplate
15:53:38 <zbyszek> contyk: sorry, it's there, somehow I missed it.
15:53:53 <sgallagh> I know ignatenkobrain said this time is okay, but it still might not be a bad idea to see if a better time exists.
15:54:09 <sgallagh> 5pm on Fridays seems unfair to our European members.
15:54:30 <contyk> ignatenkobrain: https://fedoraproject.org/wiki/FESCo_meeting_process
15:54:39 <ignatenkobrain> for me, later it is - better 🙂 so 5pm is actually quite good for me in EU :)
15:54:52 <jforbes> sgallagh: either that, or they have an excuse to drink during meetings, which might help
15:55:06 <nirik> oh, in other python3 news: our builders now only need python2 for our old, being replaced account system package. koji stack is all python3 now.
15:55:09 <bookwar> sgallagh: i am eu and it is ok for me, but i'd look into whenisgood update just out of curiosity
15:55:09 <zbyszek> jforbes: do you need an excuse for that?
15:55:12 <mhroncok> no need for an excuse
15:55:19 <mhroncok> zbyszek: :D
15:55:20 <jforbes> zbyszek: hard to justify at 10AM
15:55:28 <sgallagh> nirik++
15:55:29 <zodbot> sgallagh: Karma for kevin changed to 18 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:55:33 <mhroncok> jforbes: think about it late thursday
15:55:35 <contyk> to make things simpler, can we do the next meeting on Friday, the usual time
15:55:46 <contyk> and do whenisgood for the one after?
15:55:53 <mhroncok> nirik: thanks!
15:55:58 <sgallagh> contyk: That's fine with me
15:56:02 <jforbes> contyk: that works
15:56:06 <mhroncok> contyk: +1
15:56:21 <contyk> awesome
15:56:33 <contyk> #action ignatenkobrain will chair the next meeting, on July 12
15:56:45 <contyk> #topic Open Floor
15:57:00 <contyk> dustymabe had something
15:57:23 <dustymabe> right
15:57:40 <dustymabe> basically now that we have approval - is there somewhere I can document our process/plans
15:58:06 <dustymabe> i.e. if someone notices a tag show up in their repo I'd like to have some page about what it is how it's used and why
15:58:28 <dustymabe> there any pages that mention dist-git and branching etc.. that I could add a section to?
15:58:35 * sgallagh needs to run to another meeting.
15:58:40 <contyk> do you already have something on the docs site?
15:58:52 <mhroncok> sgallagh: see you
15:58:54 <dustymabe> nothing from us
15:58:57 <contyk> sgallagh: o/
15:59:20 <contyk> maybe you could create something about coreos in general
15:59:32 <contyk> include these implementation details, too
15:59:38 <contyk> and then link to it from... elsewhere
15:59:44 <contyk> if necessary
15:59:50 <ignatenkobrain> dustymabe: also put there information how coreos-pool koji tags are used and so on
15:59:50 <bcotton> contyk++
16:00:14 <dustymabe> ignatenkobrain: I can point to some documentation on coreos-pool
16:00:19 <mhroncok> than  a slight note with link can be added to https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Update_Your_Branches_.28if_desired.29 - that the only relevant infor on branches I found
16:00:26 <dustymabe> but in general i think it would be good to link to this information from another page..
16:00:31 <dustymabe> thanks mhroncok, will take a look
16:01:25 <dustymabe> didn't know if there was a place where "not often used but need to be documented" workflows existed
16:01:47 <mhroncok> probably not
16:02:12 <dustymabe> ok. thanks anyway :)
16:02:12 <contyk> the docs site is a good place for that
16:02:43 <dustymabe> I think we should write something up on this and then share it with devel@
16:02:54 <dustymabe> it will at least raise some awareness
16:02:59 <contyk> dustymabe++
16:03:00 <zodbot> contyk: Karma for dustymabe changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:03:18 <contyk> okay
16:03:21 <contyk> anything else for the open floor?
16:03:23 <zbyszek> .fesco 2149
16:03:26 <zodbot> zbyszek: Issue #2149: Proposal to change non-responsive maintainer policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2149
16:03:41 <zbyszek> I updated the proposal based on latest comments, maybe we could vote on it?
16:04:12 <mhroncok> +1
16:04:22 <ignatenkobrain> I promised to shared it with devel@, but didn't have chance to actually do it since last meeting
16:04:38 * nirik hasn't read the lastest comments this morning yet
16:04:52 <contyk> #topic #2149: Proposal to change non-responsive maintainer policy
16:05:28 <zbyszek> OK, do we want to wait for fedora-devel?
16:05:31 <nirik> dustymabe: there's also fesco policy docs: https://docs.fedoraproject.org/en-US/fesco/ could be under one of those...
16:05:32 <contyk> so I don't really have an opinion here so I abstain
16:05:40 <jforbes> Right, the last agreement was fedora-devel discussion
16:05:45 * bookwar is always puzzled why we review comments in tickets and not comment on pull requests in review
16:05:51 <nirik> is there some urgency, lets wait to next meeting?
16:05:58 <contyk> nirik: +1
16:06:08 <nirik> bookwar: good point indeed.
16:06:51 <contyk> let's defer this to the next meeting
16:06:56 <zbyszek> OK.
16:07:03 <zbyszek> But please read up and vote in the ticket ;)
16:07:06 * nirik already sees something he wants to comment on there.
16:07:06 <mhroncok> zbyszek: can you share that on devel?
16:07:10 <contyk> #info Will be discussed in two weeks
16:07:30 <zbyszek> mhroncok: ok
16:07:36 <mhroncok> zbyszek: thanks
16:08:14 <contyk> okay, seems like that's all for today
16:08:17 <contyk> #endmeeting