releng
LOGS
17:00:59 <mboddu> #startmeeting RELENG (2018-03-01)
17:00:59 <zodbot> Meeting started Thu Mar  1 17:00:59 2018 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:59 <zodbot> The meeting name has been set to 'releng_(2018-03-01)'
17:01:00 <mboddu> #meetingname releng
17:01:00 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
17:01:00 <mboddu> #topic init process
17:01:00 <zodbot> The meeting name has been set to 'releng'
17:01:00 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
17:02:00 * nirik is barely here.
17:02:41 <dgilmore> hi
17:02:43 <Kellin> .hello kellin
17:02:44 <zodbot> Kellin: kellin 'Kellin' <kellin@retromud.org>
17:04:15 <dustymabe> .hello2
17:04:16 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
17:05:04 <mboddu> Okay, lets get started
17:05:16 <mboddu> #topic #7301 Remove non-namespaced symlinks to rpms/
17:05:25 <mboddu> #link https://pagure.io/releng/issue/7301
17:06:10 <nirik> This is just a cleanup, we should do it. ;)
17:06:16 * puiterwijk is here and in favor
17:06:22 <puiterwijk> (which is why I suggested it :) )
17:06:24 <mboddu> I am +1 to this change
17:06:46 <mboddu> puiterwijk: What needs to be done and who should do it, is my question?
17:06:55 <puiterwijk> The next steps if it were approved would be: 1. write up a short email to devel-announce, and 2. remove the symlinks
17:07:01 <puiterwijk> I'm fine with doing both
17:07:19 <Kellin> +1 on the change, and puiterwijk dropping a line to devel
17:07:44 <mboddu> puiterwijk: Okay, just to make sure, if people coming from EOL'd versions which has old url, they will get a warning and once adjusted everything should work fine, right?
17:07:55 <puiterwijk> mboddu: yes
17:08:09 <mboddu> puiterwijk: Okay, thats all I need to know
17:08:54 <mboddu> Also, do we need anyone else approval before I say we should do it now?
17:09:01 <puiterwijk> I don't think so.
17:09:07 <mboddu> Okay, thanks for the info
17:09:08 <puiterwijk> I'd say that if releng agrees with it, we're good
17:09:30 <puiterwijk> If people still have a fedpkg old enough that it won't work... It's time to update
17:10:18 <mboddu> Well, sending an email to devel@ will ping the people who wants to talk about it, so we are good
17:10:54 <mboddu> #info puiterwijk will send an email to devel@ about the change and once its done, he will work on removing the symlinks
17:11:27 * dgilmore has never updated old checkouts
17:11:34 <dgilmore> I suspect most people have not
17:11:53 <mboddu> #info people coming from old fedora versions will get a warning about the url and once its updated everything should work fine
17:12:15 <dgilmore> mboddu: get a warning how?
17:12:27 <dgilmore> i use "git pull --rebase"
17:12:32 <dgilmore> that will just be broken
17:12:49 <dgilmore> unless I am missing what the topic is
17:12:57 <puiterwijk> [puiterwijk@workstation koji (master % u=)]$ git pull
17:12:58 * dgilmore assumes distgit
17:12:59 <puiterwijk> WARNING: 'koji' is an alias for 'rpms/koji'
17:13:01 <puiterwijk> Already up to date.
17:13:12 <puiterwijk> dgilmore: ^ we have been sending a server-side warning for a long while now
17:13:17 <dgilmore> puiterwijk: okay
17:13:47 <dgilmore> puiterwijk: and that warning will change to what when the symlinks are removed?
17:14:18 <dgilmore> puiterwijk: I guess we just need to make sure we send plenty of warning to devel-announce witha  cut off date
17:14:35 <puiterwijk> dgilmore: the remote warning wil ldisappear and say "could not find". "fedpkg pull" will tell the git set-url command
17:14:45 <puiterwijk> And yes, I was planning to do devel-announce with cut-off date
17:14:50 <dgilmore> puiterwijk: that will be bad
17:15:02 <dgilmore> I doubt people will think to switch to fedpkg pull
17:15:08 <dgilmore> needs communication
17:15:13 <dgilmore> and lots of it
17:16:15 <dgilmore> anyway carry on
17:16:17 <puiterwijk> Note that it's been >1 year. So only things that people cloned before that would stop working
17:16:18 * mboddu uses fedpkg pull, but I understand people using git
17:16:36 * puiterwijk uses git pull
17:17:18 <mboddu> puiterwijk: Make sure your cut-off date is good enough and probably few emails between now and then
17:17:29 <dgilmore> we have made a simililar change in the past
17:17:38 <dgilmore> a script was provided to update repos
17:18:22 <puiterwijk> dgilmore: right now we have "fedpkg pull" which will tell you what to update things to
17:19:14 <puiterwijk> Anyway, conclusion: needs prior announcement and needs cut-off date.
17:19:26 <puiterwijk> Unless anyone has further issues to bring up, I think I can manage that
17:20:10 <dustymabe> puiterwijk: +1
17:22:02 <mboddu> dgilmore: Your last statement seems incomplete, do you want to add anything before I move to next topic?
17:23:49 <dustymabe> mboddu: lets move on
17:23:49 <mboddu> Okay, lets move on
17:23:52 <dustymabe> :)
17:23:57 <mboddu> dustymabe: haha
17:24:53 <mboddu> #topic #7293 Pull Requests for fedora-release need discussion in larger group
17:24:59 <mboddu> #link https://pagure.io/releng/issue/7293
17:25:38 <mboddu> Kellin: Can you start on this, not sure what are your expectations
17:27:12 <Kellin> mboddu: mostly to find out what if any impacts these requests have, and whether it's going to break anything else
17:27:39 <dgilmore> puiterwijk: https://pagure.io/fedpkg/blob/11f99d50f5d84f3c7bfefe703c635de358a35517/f/src/pyfedpkg/__init__.py#_92
17:28:19 <mboddu> Kellin: https://pagure.io/fedora-release/pull-request/119 is not true atm, as the repo is upstream for fedora-release, unless we decide to use dist-git
17:28:45 <Kellin> mboddu: correct
17:28:46 <dgilmore> main issue will be people mergeing in or commit things that break machines, installs composes etc
17:29:09 <nirik> mboddu: there was a proposal to do that... close the pagure.io repo and only maintain it in src.fedoraproject.org
17:29:37 <mboddu> nirik: Yes, I remember, but not sure whether we decided anything on that
17:29:49 <Kellin> I don't see a reason to do it
17:30:00 <nirik> I don't know that we did...
17:30:00 <dgilmore> I would be for it, if we had sufficent test suites
17:30:15 * nirik doesn't care much either way.
17:30:46 * mboddu is okay with anything, but I like to have things separate as upstream and fedora, but eh
17:30:53 <dgilmore> it wil simplify the process at a cost of a loss of control.
17:31:26 <mboddu> dgilmore: exactly
17:31:31 <dgilmore> I am pretty sure that I made my thoughts clear on devel list
17:32:47 <nirik> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/
17:32:51 <nirik> ^ thats the thread
17:33:29 <nirik> dgilmore: how would test suites work there?
17:33:56 <dgilmore> nirik: start with making sure the formating is valid
17:34:11 <dgilmore> nirik: extended to make sure we do not break composing
17:34:24 <dgilmore> nirik: make sure updates work
17:34:38 <dgilmore> all the things that in the past we have managed to get wrong
17:34:46 <nirik> well, those are all pretty difficult. You would need to make the fedora-release package, compose something with it and test it with openqa or something
17:35:09 <dgilmore> it would need something yeah
17:35:38 <nirik> I mean it would be awesome, but it sounds like a LOT of work. ;)
17:35:46 <dgilmore> right I agree
17:35:52 <Kellin> it seems to me like a lot of work for not much gain compared to other stuff
17:36:07 <dgilmore> Kellin: I disagree
17:36:07 <Kellin> it doesn't seem to solve a current deficiency as far as I can tell
17:36:14 <dgilmore> we should have it regardless
17:36:25 <nirik> well, either way: if it's in pagure.io or in src.fp.o as upstream its really the same work... just location...
17:36:31 <dgilmore> Kellin: it does
17:36:53 <Kellin> nirik: putting it in src.fpo.o allows provenpackagers to update it as well; which is why we would need a test suite to help prevent disasters
17:37:03 <dgilmore> because we currenlt frequently need to have expensive loops in getting changes to fedora-release right when mistakes are made
17:37:19 <nirik> Kellin: sure, althought they can do that now too.
17:37:54 <Kellin> nirik: I had been under the impression from chatting with mboddu that provenpackagers can't commit to it today?
17:38:03 <dgilmore> Kellin: that is not true
17:38:19 <mboddu> Kellin: They cant commit to pagure.io where fedora-release is hosted, but they can make patches and do releases
17:38:30 <nirik> they can... just their changes would be overwritten the next time we do a release from pagure.io and sync it over
17:39:30 <mboddu> So, conclusion or punt?
17:39:48 <Kellin> We need someone to scope the test suite and create a plan for it and get that into Tiaga
17:39:51 <Kellin> Taiga
17:40:01 <nirik> I see dgilmore's reply in that thread asking for a test suite as part of the move, and no reply to that. ;)
17:40:19 <mboddu> nirik: Yeah, thats the last message on the thread :D
17:40:34 <dgilmore> apparently I scared everyone off
17:40:41 <mboddu> dgilmore: haha :)
17:41:23 <nirik> anyhow, I'd say lets keep the status quo until people wanting to do the move step up to help setup a test suite.
17:41:27 <dgilmore> If we could improve the reliability and trust in changes we make, then yep lets do it
17:41:38 <dgilmore> get CI tied into PR's
17:41:45 <dgilmore> nirik: +1
17:41:55 <mboddu> I would go with nirik here
17:42:02 <Kellin> so - to that point
17:42:06 <nirik> we could at least have simple-ci build the package as a start of tests.
17:42:20 <Kellin> we ask sly to make a taiga card for the test suite and then we close these with "when this is done, this can happen"
17:42:30 <Kellin> that way it's on the roadmap but not cluttering issues since it's definitely a long-term item not a breakfix
17:42:52 <Kellin> it also would get it somewhere Fedora leadership can prioritize during F29 /F30 /FXX planning sessions
17:42:59 <nirik> sure. +1 to that.
17:43:17 <mboddu> Kellin: Sure, can you create the taiga ticket?
17:43:19 <nirik> oh, also, we should make a README for the src.fp.o package that tells people to submit pr's against the upstream project
17:43:36 <dgilmore> nirik: yeah
17:43:37 <Kellin> mboddu: sure, add it as an action item
17:44:25 * Kellin thinks it sounds like an epic more than a card with tasks - everyone agree?
17:44:26 <nirik> does someone want to take that as a task also?
17:44:41 <mboddu> nirik: I can
17:44:49 * mboddu adding to the info actually
17:44:50 <nirik> mboddu: great. thanks.
17:45:20 <nirik> Kellin: yeah, likely a initial thing just testing the rpm builds, then something that tests more, then something that tests a compose with it, etc.
17:45:46 <mboddu> #info We are okay with moving fedora-release from pagure.io to src.pagure.io but we want to have the test suits ready
17:46:26 <mboddu> #action Kellin is going to file a taiga ticket with what needs to be done for test suits
17:47:35 <Kellin> as I think about this - one question
17:47:47 <mboddu> #action mboddu will add a README to fedora-release repo on src.fp.o that tells people to submit PR's to upstream fedora-release on pagure.io
17:47:47 <Kellin> if src.fpo.org is the downstream for projects to package into fedora
17:48:08 <Kellin> why are we going to move commit work into src.fpo instead of keeping it in our upstream?
17:48:19 <dgilmore> Kellin: src.fp.o is the authoritative location for all sources in fedora
17:48:39 <Kellin> so wouldn't the workflow still be commit to upstream, then merge into src.fpo?
17:48:51 <dgilmore> thats what we have today
17:48:56 <Kellin> and we're wanting to invert it
17:49:01 <dgilmore> no
17:49:09 <nirik> wanting to kill the upstream and move it to src
17:49:18 <nirik> so src.fp.o is the upstream
17:49:22 <dgilmore> Kellin: the request is to make src.fp.o be the sole canonical location
17:49:22 <nirik> and the fedora package
17:49:50 <dgilmore> pagure.io/fedora-release will cease to be used
17:50:00 <dgilmore> it will reduce some work for us
17:50:49 <puiterwijk> (work that can by the way be pretty much entirely automated with a standard client-side script)
17:51:11 <mboddu> Kellin: Like not building it manually by us when things gets changed that doesn't need our involvement
17:53:08 <mboddu> Okay moving on
17:53:15 <mboddu> #topic Open Floor
17:53:35 <mboddu> I have one, not sure how big of a topic its gonna be
17:53:38 <dustymabe> I have one and I think Kellin has one
17:53:41 <mboddu> Does anyone has anything?
17:53:47 <mboddu> dustymabe: Sure, go ahead
17:54:10 <dustymabe> mine is mostly small, but did want to point people towards it if they have not already seen
17:54:15 <dustymabe> https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.org/thread/637MOWYZWLAL7FKDCLOQEJUIWOB3TBMB/
17:54:21 <dustymabe> related to moving around ostree repos
17:54:26 <Kellin> mboddu: epic https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/epic/986; assigned a card to you for the subtask
17:54:49 <dustymabe> dgilmore: had a suggestion and I'm working to incorporate his request and submit a new proposal and then me and patrick will make it happen
17:55:33 * nirik is fine with it. Make it so.
17:55:42 <dustymabe> +1
17:55:49 <dgilmore> dustymabe: I think we keep it simple and have a unified repo
17:55:54 <dustymabe> I'll work with puiterwijk to make it happen (new proposal email will be later today)
17:56:07 <dustymabe> dgilmore: right. I'm working to incorporate that suggestion in the proposal
17:56:09 <masta> dustymabe, so the ostree is composed in one location, and then a ref is pushed to another repo?
17:56:19 <dgilmore> masta: yes
17:56:26 <masta> that sounds cool
17:56:31 <dustymabe> masta: yes. there is a compose ostree repo and a prod repo (where things are published to)
17:56:33 <dgilmore> though its composed in one repo and its synced elsewhere
17:56:57 <dustymabe> Kellin: want to bring up your topic?
17:57:22 <dgilmore> dustymabe: unrelated, we should work with teh compose team to see if we can redo how we do things, so that we can make s390x possible
17:57:30 <dgilmore> but thats a bit off topic
17:58:03 <Kellin> dustymabe: sure, so basically wrote up the compose monitor idea per our discussions last week
17:58:09 <mboddu> #info dustymabe is working on a new proposal based on dgilmore comments on https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.org/thread/637MOWYZWLAL7FKDCLOQEJUIWOB3TBMB/
17:58:46 <Kellin> I have not submitted a PR yet - dusty approved of it this morning, this is the working draft: https://pagure.io/fork/kellin/releng/blob/compose-monitor-tooling/f/docs/source/projects/compose_monitoring.rst
17:58:46 <dustymabe> dgilmore: yes. let's open a releng ticket for that (if there isn't one already)
17:59:13 <dgilmore> dustymabe: I think it likely just needs one for pungi
17:59:44 <mboddu> dgilmore, dustymabe : Dont you think infra should also be involved?
18:00:13 * dustymabe will try to focus on Kellin's topic for now
18:00:29 <mboddu> #info Kellin wrote up a draft on compose monitor tooling available at https://pagure.io/fork/kellin/releng/blob/compose-monitor-tooling/f/docs/source/projects/compose_monitoring.rst
18:00:56 <Kellin> I guess review and folks come back to us in channel during the week
18:01:05 <dgilmore> Kellin: why is it not in the wiki?
18:01:26 <nirik> I think the tracker dustymabe has setup has been handy... a dashboard would be fine, but... I don't know that it's worth putting a bunch of development into. We don't really need anything too fancy IMHO.
18:01:38 <mboddu> dgilmore: AFAIK, its just a draft and will be moved to wiki, Kellin correct me if I am wrong
18:01:47 <Kellin> dgilmore: had a discussion yesterday in #releng; 95% of our docs live in the sphinx docs
18:01:49 <nirik> but we can gather requirements from the tracker thing we have now
18:02:19 <mboddu> nirik: Yeah, I agree
18:02:31 <dgilmore> Kellin: work proposals are not docs though
18:02:58 <dgilmore> Kellin: I really do not think that it is approporiate to have in releng docs
18:03:13 <dgilmore> but the where and how is a different thing
18:03:14 <masta> so is this proposal to make the pungi logs more accessible?
18:03:47 <dustymabe> masta: i think the idea is to add sanity to our workflow for debugging pungi issues (i.e. let's have tools that help us do our job better)
18:03:51 <nirik> masta: well, to track failures, allow comments and info so people know whats going on...
18:03:55 <Kellin> masta: they are already accessible, it's a proposal to assess and analyze failures over time
18:03:55 <mboddu> masta: Well, not exactly, we are tracking the failures and why it happened and what we did to fix it
18:04:00 <dgilmore> Kellin: so reading though it, I would like to see some details, it's very wish washy, how do we plan t achieve the stated goals
18:04:18 <dgilmore> masta: pungi logs are entirely accesable
18:04:35 <Kellin> so - re-write it.  we can close topic and move it to next week; we're already over time anyway.
18:04:36 <masta> right, so I was wondering why this proposal was wanted
18:04:46 <Kellin> add an action item for me mboddu
18:04:47 <nirik> moving rawhide compose time may need to be a devel list discussion + fesco ticket... since people are very used to the existing time. But I'm definitely open to moving it to whenever would help us best.
18:05:07 <dgilmore> masta: so we know what we are trying to achieve
18:05:20 <dgilmore> masta: and have it turned into a MVP or Epic in taiga
18:05:38 <dgilmore> masta: and have the work scoped, prioritised and completed
18:05:41 <mboddu> #action Kellin will rewrite the draft and put it on wiki
18:05:49 <mboddu> #undo
18:05:49 <zodbot> Removing item from minutes: ACTION by mboddu at 18:05:41 : Kellin will rewrite the draft and put it on wiki
18:06:12 <mboddu> #action Kellin will rewrite the draft on compose monitor tooling and put it on wiki
18:06:15 <dgilmore> Kellin: perhaps we write it up as a MVP in taiga?
18:06:25 <nirik> MVP?
18:06:31 <Kellin> dgilmore: I'm MUCH more aligned to that than with doing it in Wiki
18:06:48 * dgilmore notes we really do not have a good way to propose things like this, so it is very much flying by the seat of our pants
18:06:51 <Kellin> dgilmore: we don't really use wiki anymore and Taiga is a better place for work tracking
18:06:55 <Kellin> dgilmore: (we being releng)
18:07:11 <Kellin> mboddu: undo one more time, I'll write up it up in taiga
18:07:15 <mboddu> #undo
18:07:15 <zodbot> Removing item from minutes: ACTION by mboddu at 18:06:12 : Kellin will rewrite the draft on compose monitor tooling and put it on wiki
18:07:17 <dgilmore> Kellin: internally MVP's are scoped in google docs, and turned into Jira tickets when approved
18:07:18 <dustymabe> nirik: minimum viable product (corporate speak) :)
18:07:32 <dgilmore> Kellin: which is kinda what I was looking to replicate
18:07:36 <mboddu> #action Kellin will rewrite the draft on compose monitor tooling and put it on taiga
18:07:39 <nirik> ok.
18:07:46 <Kellin> so that works for me
18:07:56 <Kellin> I have one other thing, but we're over time. I'll ask about it after lunch in chan
18:08:53 <mboddu> Anyway, lets close the shop now, we are over time
18:09:02 <mboddu> Thanks everyone for joining
18:09:17 <dustymabe> thanks mboddu
18:09:20 <mboddu> If anyone has anything more to talk about, lets talk in #fedora-releng
18:09:23 <mboddu> #endmeeting