15:00:22 <mboddu> #startmeeting RELENG (2020-07-28)
15:00:22 <zodbot> Meeting started Tue Jul 28 15:00:22 2020 UTC.
15:00:22 <zodbot> This meeting is logged and archived in a public location.
15:00:22 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:22 <zodbot> The meeting name has been set to 'releng_(2020-07-28)'
15:00:22 <mboddu> #meetingname releng
15:00:22 <zodbot> The meeting name has been set to 'releng'
15:00:22 <mboddu> #chair nirik sharkcz pbrobinson pingou mboddu dustymabe ksinny jednorozec
15:00:22 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson pingou sharkcz
15:00:22 <mboddu> #topic init process
15:00:31 <nirik> morning
15:00:37 <mboddu> Morning nirik
15:00:37 <sharkcz> hi
15:00:42 <pingou> ó/
15:00:46 <mboddu> Morning sharkcz and pingou
15:00:49 <mboddu> How goes?
15:00:57 <pingou> so far so good :)
15:00:59 <jednorozec> hello
15:03:21 <mboddu> Since pingou is here, lets get started with
15:03:24 <mboddu> #topic #9631 flatpaks: move from 'master' to 'stable'
15:03:30 <mboddu> #link https://pagure.io/releng/issue/9631
15:04:00 <mboddu> I want to bring up the discussion and see if we can come up with a plan (or at least a plan for the plan :) )
15:04:21 <mboddu> This needs lot of changes
15:04:53 <mboddu> If we are doing it for everything
15:05:34 <mboddu> From pagure, dist-git over pagure, koji, fedpkg, fedscm-admin, releng, bodhi and other tools that we use
15:07:15 <pingou> we could do: mv master main, ln -s main master
15:07:30 <pingou> and set the default branch to be main
15:07:32 <nirik> I don't think we should do everything at once.
15:07:39 <pingou> this way, we keep backward compat
15:07:49 <pingou> but still change the default
15:08:08 <pingou> I don't know that koji will care in this list, will it?
15:08:40 <nirik> it shouldn't I wouldn't think
15:08:53 <mboddu> I dont think koji cares, it uses the hashes to build from not branches
15:09:12 <mboddu> (But its good to run a impact check with them)
15:09:42 <mboddu> Same with bodhi as well
15:10:11 <pingou> mboddu: and even when it uses the branch, since it's provided, it shouldn't matter
15:11:13 <mboddu> Okay
15:11:56 <mboddu> So, whats the plan here?
15:11:57 <pingou> I wonder if we could use monitor-gating and the tests packages there to do a basic/sanity check
15:12:06 <pingou> do we want to wait for stg to be back?
15:12:18 <nirik> yes, I would...
15:12:33 <nirik> well, I suppose we could do the flatpak part anytime...
15:12:34 <mboddu> Yeah, testing in stg would be better
15:12:40 <nirik> but stg would be very helpful for trying things.
15:13:24 <pingou> I'm wondering: will we have time to do things in august? (as in: should we target things for August, or directly aim for September?)
15:15:04 <nirik> well, I think we can do flapak anytime, but dist-git is going to be another thing...
15:15:17 <nirik> thats going to probibly take an outage?
15:15:33 <nirik> I guess it depends on how we do it
15:15:34 <mboddu> If for flatpaks, we can try Aug, but for entire dist-git change, we need Sept or maybe later
15:15:50 <nirik> I was thinking after f33?
15:15:59 <pingou> not sure we need an outage
15:16:04 <nirik> there was talk about doing it at branching...
15:16:11 <pingou> (esp confisdering the load on flatpaks)
15:16:19 <nirik> but I worry there, as we already have 1000 things to do and it's a bunch more complexity on top
15:16:40 <mboddu> nirik: branching time is very near and I agree with the complexity
15:16:44 <jednorozec> we should do the dist-git after f33
15:16:48 <pingou> we could do just before or shortly after, but during branching sounds risky
15:17:28 <mboddu> Can I use my veto power not to use it on or before branching? :D
15:17:35 <nirik> if something goes sideways I wouldn't want to delay f33 or cause schedule issues.
15:17:44 <mboddu> Agreed
15:17:56 <jednorozec> +1
15:18:38 <pingou> so post F33 release?
15:18:54 <nirik> thats what I would prefer... but thats a short time...
15:19:01 <nirik> with holidays, etc...
15:19:11 <pingou> or post F34 branching, say 1 or 2 weeks after?
15:19:18 <pingou> (around bodhi activation point)
15:19:32 <nirik> I would prefer outside release...
15:19:55 <nirik> if we do it in nov... that gives lots of time for people to adjust thigns and us to fix things.
15:21:23 <pingou> nov is post F33 release, pre f34 branching?
15:21:26 <pingou> right?
15:21:29 <jednorozec> yes
15:21:31 <nirik> yeah
15:21:39 <pingou> sounds good to me!
15:21:50 * nirik looks at the schedule
15:21:55 <mboddu> Yeah, post 33 release seems good to me
15:22:20 <mboddu> Current target for f33 release is Tue 2020-10-27
15:22:31 <mboddu> So, we can plan working on it in Nov
15:22:35 <nirik> pingou: does pagure have a way to specific 'default branch' ? could it?
15:22:38 <pingou> looking at the schedule, we do have a nice down time about there
15:22:54 <pingou> nirik: we do, we should expose the setting in the API though
15:23:15 <pingou> (there is already a ticket asking this)
15:23:15 <nirik> yeah, that would be ideal. then pagure.io projects could do as they like...
15:23:31 <pingou> it's in the settings of the project
15:23:33 <pingou> (in the UI)
15:25:11 <nirik> cool. you keep adding things I don't know about. :)
15:25:13 <nirik> keep it up.
15:25:24 <mboddu> pingou++
15:25:55 <pingou> nirik: that one has been there for a long long time :D
15:26:12 <mboddu> I remember seeing it a while ago, but never used it :D
15:26:23 <nirik> so, we could also try this on some of our projects / come up with a process?
15:29:34 <mboddu> +1
15:29:48 <pingou> the big question is: do we keep master as a symlink or do we drop it entirely?
15:29:51 <mboddu> But I will change them after f33 release in releng
15:30:08 <nirik> the flatpak ticket here is suggesting keep it with a readme
15:30:31 <mboddu> Which means drop it completely
15:30:32 <nirik> mboddu: yeah, we should not disrupt the release... but other projects we could
15:30:44 <nirik> no?
15:30:55 <nirik> * Remove the the existing master branch content, add a pointer to the stable branch in README.md
15:31:11 <nirik> so there is still a master branch... it just has 1 file in it
15:31:23 <mboddu> Right, which means *drop it* as per pingou'
15:31:25 <mboddu> s question
15:31:44 <nirik> well, I read that as does it exist or not.
15:31:59 <mboddu> If we drop it, people can do whatever they want
15:32:00 <nirik> there are a lot of options.
15:32:05 <pingou> pagure will show the default branch
15:32:15 <pingou> so there is no need to keep a master if we don't make use of it
15:32:33 <nirik> delete it, might confuse some people. make it a branch with a readme, means it's still there...
15:32:34 <pingou> if you set the default branch to be develop, it'll show develop by default
15:33:00 <nirik> I guess the only reason to keep it might be people who have existing checkouts...
15:33:31 <mboddu> So, instead 3 part approach (but add more work)
15:33:38 <mboddu> 1. symlink for few months
15:33:49 <pingou> though if we want to have people stop using it: we shouldn't allow people to push to it
15:33:52 <mboddu> 2. Add readme after that and leave it for few months
15:33:59 <mboddu> 3. remove it entirely
15:34:13 <nirik> yeah, thats an option...
15:34:50 <jednorozec> pingou, well I would be really angry if my autopackaging scripts and work-flow just stop working because someone decided I dont want to use master branch.
15:34:53 <nirik> on the other hand... if you 'git pull' and it says 'no master branch' you likely would 'git branch -a' and look at the changes and see that it was removed and checkout develop or rolling or whatever
15:35:11 <mboddu> (Now I think about it, its more work and more confusing) ¯\_(ツ)_/¯
15:35:33 <pingou> jednorozec: that is precisely what is being discussed here :)
15:35:57 <jednorozec> we should not force people to stop using it, just switch default
15:36:24 <nirik> sure, owners should have the say, but we are 'owners' of a number of things ourselves.
15:36:58 <mboddu> The best option that I can think of is, symlink it and change the default to main for future
15:37:25 * nirik isn't sure he likes the symlink. Thats just keeping it around...
15:38:10 <mboddu> I dont like it either, but people might loose their workflow and I dont know how much of a rumble it will be
15:38:43 <pingou> I do think having the same default branch across the entire dist-git is desirable
15:39:02 <pingou> then we can roll-out in phases and start with flatpaks
15:39:06 <nirik> the only thing I can personally think of that I would need to change is 'git merge origin/master' ... but ... I can do that, it's only one command.
15:39:55 <pingou> so should we table that until we have a consensus for the entire dist-git?
15:40:17 * pingou kinda think this is change-proposal worthy
15:40:33 <nirik> I guess. I also see the argument that flatpaks are different too... they don't really have a 'rawhide' 'develop' branch...
15:40:40 <jednorozec> will we ever have that? does the flatpak vs fedora release cycle get ever synced?
15:40:58 <pingou> nirik: I'd favor "main"
15:40:59 <nirik> yes, in the fesco ticket on this it's supposed to be a change...
15:41:30 <nirik> but it's a bit weird for me, because till is the one who asked for it, but isn't going to be doing any of the work
15:42:02 <pingou> reminds me of another one
15:42:05 * pingou ducks
15:42:10 <nirik> jednorozec: I thiink they always build against the 'stable' platform... so yeah, no. ;)
15:43:41 <mboddu> Or, we could put out our options to devel and ask people to vote or suggest any better plan
15:43:49 <mboddu> And then we decide
15:44:14 <mboddu> (or work on the decision that community has suggested)
15:44:15 <nirik> well, I am not sure we have enough here for a plan... :)
15:44:33 <nirik> perhaps someone wants to write up a proposal and then we can try and discuss/adjust that?
15:45:16 <mboddu> I can help with anyone who wants to take up the job
15:45:44 <pingou> what's the idea? bringing this to the devel list?
15:45:52 <jednorozec> yup
15:46:08 <pingou> mboddu: want the two of us to draft something?
15:46:14 <mboddu> pingou: Sure
15:46:22 <mboddu> So, the plan:
15:46:30 <nirik> no....
15:46:40 <mboddu> 1. Send a devel@ list email with our options
15:46:48 <nirik> IMHO, we should come up with a plan/schedule. THEN mail devel about it.
15:46:49 <mboddu> 2. Create a change request with that option
15:46:55 <mboddu> 3. Work on it
15:47:29 <jednorozec> indeed, if we bring the discussion without plan it will take ages to agree on something.
15:47:44 <nirik> nothing will be agreed on. ;)
15:47:56 <mboddu> nirik: We could do that, for each option how long is it going to take
15:48:07 <jednorozec> nirik, yup we will all just disagree
15:48:28 <mboddu> nirik: Or you are saying not to provide any options to devel@ list and just provide a concrete plan and schedule?
15:48:53 <nirik> ok, how about this: let me draft something and we can discuss it/tweak it, and also ask till to look at it...
15:49:11 <pingou> nirik: don't you have a DC to rebuild? ;-)
15:49:12 <nirik> then it can get converted into a change and will then be discussed on the devel list. ;)
15:49:16 <pingou> (other than that, wfm :))
15:49:54 <nirik> yep, I do. If someone else wants to thats fine too... or I we can all work on it?
15:49:55 <mboddu> nirik: Sure
15:50:20 <jednorozec> nirik, that chain of events may get us some result
15:50:21 <mboddu> nirik: I am happy to help
15:50:45 <nirik> cool. lets make a hackmd and dump things in there?
15:50:49 <pingou> +1
15:50:55 <mboddu> +1
15:51:02 <nirik> perhaps split by section/thing or... timeline? not sure.
15:51:45 <mboddu> #info nirik is going to create a hackmd document and everyone can work on the draft for the change
15:52:21 <mboddu> Okay, moving on
15:52:25 <mboddu> #topic Open Floor
15:52:29 <mboddu> I have couple of questions
15:52:39 <mboddu> or 1 update and 1 question
15:52:54 <mboddu> #info Mass rebuild started yesterday and seems to be going great
15:53:06 <mboddu> It was at perl* today morning
15:53:27 <mboddu> And it still is :)
15:53:43 <nirik> well...
15:53:55 <nirik> I just noticed eln folks pushed their own mass rebuild.
15:54:00 <nirik> So, that will slow us down
15:54:28 <nirik> although, it looks like it's all waiting on s390x
15:54:32 <mboddu> mass rebuild, I thought only few packages, but didn't realize its their own mass rebuild
15:55:08 <nirik> looks like about 1400
15:55:15 <sharkcz> do they do mass rebuild or the does their automation pick just finished builds?
15:55:42 <nirik> sharkcz: I am not 100% sure, but all these are owned by tdawson...
15:55:58 <sharkcz> nirik: aha, then it will be manual, I guess
15:56:36 <mboddu> Oh great, I saw some builds, but I didn't check how many builds they submitted :(
15:57:00 <mboddu> On the question part
15:57:15 <mboddu> nirik: Do you know if we ever shipped debuginfo rpms of openh264?
15:57:38 <nirik> I recall there was some request for it...
15:57:59 <mboddu> I just realized that what Dennis handed over me doesn't ship debuginfo rpms
15:58:38 <nirik> I thought we fixed that... :(
15:58:46 <nirik> I guess not
15:58:58 <pingou> if you don't need me, I'll have to step out
15:59:07 <mboddu> pingou: Sure, thanks for joining
15:59:13 <pingou> see you later!
15:59:32 <mboddu> nirik: Do you remember the ticket/discussion? Like, where it happened
15:59:38 <mboddu> Its not in releng issues
15:59:47 <nirik> I'm looking and not finding it yet
16:00:39 <mboddu> nirik: Okay, please forward me if/when you find it
16:00:47 <mboddu> Thanks everyone for joining
16:01:00 <mboddu> #endmeeting