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