15:02:40 <pingou> #startmeeting [fedora-ci] UX for rawhide package gating
15:02:40 <zodbot> Meeting started Wed Mar 20 15:02:40 2019 UTC.
15:02:40 <zodbot> This meeting is logged and archived in a public location.
15:02:40 <zodbot> The chair is pingou. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:40 <zodbot> The meeting name has been set to '[fedora-ci]_ux_for_rawhide_package_gating'
15:03:51 <pingou> ttomecek: bookwar: adamw: Son_Goku: tstellar_: bowlofeggs dperpeet Evolution  :)
15:04:04 <dperpeet> .hello2
15:04:05 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
15:04:06 <Son_Goku> .hello ngompa
15:04:09 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
15:04:10 <adamw> coremodule: ping
15:04:12 <zodbot> adamw: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
15:04:24 * adamw is sorta around
15:04:30 <bookwar> .hello2
15:04:31 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:04:35 <adamw> .hello adamwill
15:04:36 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
15:04:41 * nirik is also sort of here
15:04:53 <pingou> .hello2
15:04:55 <zodbot> pingou: pingou 'Pierre-YvesChibon' <pingou@pingoured.fr>
15:04:59 <tstellar_> .hello tstellar
15:05:00 <zodbot> tstellar_: tstellar 'Tom Stellard' <tstellar@redhat.com>
15:05:12 * Son_Goku is here for a while
15:05:53 <Evolution> .hello jperrin
15:05:54 <zodbot> Evolution: jperrin 'None' <jperrin@redhat.com>
15:06:22 <Son_Goku> Evolution, you should fix that :)
15:07:05 <pingou> alright, let's wait a couple of minutes more
15:07:16 <adamw> why did jim get renamed after an email client
15:07:31 <pingou> adamw: I've been wondering that for a while, but was too afraid to ask
15:07:33 <Evolution> adamw: I had this name before the email client. they're ruining my rep
15:07:37 <Evolution> :-P
15:07:51 <Evolution> (yes, I'm old)
15:07:53 <pingou> hi mhroncok :)
15:08:02 <adamw> Evolution: i mean, you can ask which of the two I prefer, but I wouldn't recommend it ;)
15:08:05 <adamw> <ducks>
15:08:10 <mhroncok> pingou: hi, sorry for being late, was typing some code and not checking time
15:08:34 <Evolution> adamw: huh, I always picked you for a gmail web interface kinda guy
15:08:36 <pingou> mhroncok: no worries, we haven't started yet
15:08:37 * Evolution flees from adamw
15:08:43 * adamw waves white flag
15:08:50 <adamw> uncle!
15:09:21 <pingou> alright, let's get started and if more people show up they'll join then :)
15:09:33 <pingou> so first of all, thanks for being here
15:10:19 <pingou> we've managed to kick off the discussion over emails in the last two days and I was hoping that a more dedicated time (such as a meeting) could help improving the current proposal
15:11:17 <pingou> my concerns are mostly around what the user experience should be
15:11:36 <pingou> what we would deem acceptable changes to the current workflow and what we really do not want
15:13:04 <pingou> does someone want to start poking holes into the current proposal?
15:13:46 * pingou re-reading the last email from tibbs
15:13:54 <mhroncok> pingou: why is the single package / multi package thing separated?
15:14:02 <Evolution> pingou: for those who aren't on the email thread, maybe a quick elevator pitch?
15:14:13 <Evolution> since we're logging this meeting, might help for posterity
15:14:16 <mhroncok> so we support some kind of easy fedpkg build --nogate when i want to do chained builds?
15:14:22 <pingou> Evolution: good point, I'll start with this then go to your question mhroncok :)
15:14:49 <pingou> so, during the discussion about https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates on the fedora-devel list
15:14:57 <pingou> there were some concerns raised
15:15:14 <pingou> some about the CI system and its capabilities (or in some cases lack thereof)
15:15:26 <pingou> some about the opt-in/opt-out possibilit
15:15:28 <pingou> +ies
15:15:47 <pingou> some about the distinction between single-build updates and multi-builds updates that this proposal introduces
15:16:01 <pingou> I believe we were able to answer some of the concerns raised, but not all
15:16:33 <pingou> and the idea was to gather us to see if we could adjust the proposal in such a way that these concerns are no longer true or considered acceptable
15:16:53 <pingou> so mhroncok regarding your question about the distinction b/w single and multi-build updates
15:17:05 <pingou> we did this split for two reasons:
15:17:39 <pingou> - we have experience with doing single-build gating in koji and know how to do it
15:18:10 <pingou> - it's technically quicker to implement, thus given us a quick turn around for testing, validations and improvements
15:18:20 <mhroncok> both makes sense
15:18:47 <bookwar> pingou: can we promise that once koji part required for multi-package changes is done, the single package workflow will be merged into the multi-package one
15:18:59 <bookwar> so in the end there will be just one multi-package workflow
15:19:14 <bookwar> single-package gate is just a milestone to achieve it
15:19:24 <pingou> bookwar: I'd question is this is something we want or not?
15:19:24 <mvadkert> 09:37 < pingou> mvadkert: ok, so in your opinion, should bodhi check greenwave even for updates that passed greenwave?
15:19:27 <mvadkert> no
15:19:41 <bookwar> pingou: i think it is
15:19:47 <mvadkert> or ... in our case, we notify the user that somethin spooky is going on
15:19:52 <mvadkert> pingou: but we do not change the gate
15:20:02 <mvadkert> pingou: decision
15:20:07 <pingou> bookwar: that means: creating a side-tag for every update, regardless of the number of builds in it
15:20:12 <bookwar> yes
15:20:25 <bookwar> and providing sidetag for testing for CI pipelines
15:20:41 <bookwar> this way we unify also how CI pipelines work with the inputs
15:20:41 <pingou> I'm fine with this, but it does impact, potentially more, the packager workflow, unless we have a way to automate it
15:20:51 <Son_Goku> which at the moment, we do not
15:21:05 <pingou> I like tibbs' suggestion in email to have fedpkg chain-build do the side-tag creation, so two steps in one command
15:21:15 <Son_Goku> we don't have any automation around packager workflows, which is why this gets really hairy
15:21:21 <pingou> but I'm not sure we want fedpkg build to do side-tag creation
15:21:39 <Son_Goku> pingou, where would it go, then?
15:22:13 <pingou> Son_Goku: the way I saw it, for multi-builds, was a separate command (or as tibbs suggested, in chain-build)
15:22:24 <Son_Goku> there are two classes of multi-builds
15:22:35 <Son_Goku> one class is where you know all the stuff is going to work, so you chain-build it
15:22:37 <tstellar_> Having fedpkg chain-build do side-tag creation would be a generally useful feature in my opinion, even without gating.
15:22:45 <pingou> tstellar_: +1
15:22:48 <Son_Goku> another class is when you don't know, and you're doing it one by one
15:23:10 <Son_Goku> my understanding is that the latter happens more often in rawhide, and the former happens more often in stable releases
15:23:11 <bookwar> pingou: i dont' think automation is the problem here, we can have various subcommands for different use-cases - chain-build, one by one build, ...
15:23:25 <bookwar> the idea is that the sidetag is the unit of work for a gate
15:23:46 <Son_Goku> ^ this makes sense
15:23:49 <bookwar> gate won't see things as builds, it will see them as tags with repos
15:23:51 <pingou> I do like the idea
15:23:52 <Son_Goku> it's functionally equivalent to a PR
15:24:33 <pingou> my question is more: how to make this as easy as possible to get in the packager's workflow
15:24:42 <Son_Goku> and that gets us miles closer to doing stuff like this: https://build.opensuse.org/project/staging_projects/openSUSE:Factory & https://build.opensuse.org/project/staging_projects/openSUSE:Leap:15.1
15:25:29 <Son_Goku> pingou, for now, if we're talking about minimal disruption right now, make it opt-in for everybody
15:25:30 <bookwar> but that's a step two, which requires koji changes, while in step one we can do the bodhi part with providing gating interface and operations on a single build level, and then transfer this to sidetags when they are ready
15:25:47 <bookwar> Son_Goku: the question is, what does opt in means here?
15:25:56 <adamw> i think the 'it needs to do reverse dependency builds' response is interesting because of what it implies
15:26:24 <Son_Goku> bookwar, that means the rawhide-gating target must be specified to use it
15:26:33 <adamw> i think what those responses are really telling us is "i am probably not going to bother with this because it won't test the thing that breaks most often"
15:26:45 <Son_Goku> adamw has it right on the money
15:27:00 <pingou> Son_Goku: so you'll opt-in at the package (gating.yml in dist-git) + at the build (fedpkg build --target=rawhide-gated)?
15:27:05 <bookwar> Son_Goku: why? what are you opting in for? ihaving pre-tag doesn't affect your workflow unless you have test resuired
15:27:06 <adamw> if that's true, it doesn't matter a lot how easy it is to put this into your workflow as a packager, if you think it's just not going to help a lot anyway
15:27:09 <bookwar> required*
15:27:22 * cverna joins
15:27:28 <Son_Goku> pingou, there are packages where other people have put in the gating.yml file
15:27:39 <Son_Goku> that doesn't mean everyone is equipped to deal with the consequences of it
15:27:48 <pingou> bookwar: ^ I think this was for you :)
15:27:48 <tstellar_> Another benefit as having sidetag as the unit of work is it's easier to integrate modules, since modules come with their own tag.
15:27:50 <bookwar> if you have no tests configured - gating doesn't affect you, so there is no need to opt-in for gating, you opt-in for tests
15:28:00 <Son_Goku> Atomic WG likes putting CI in stuff that no one can deal with, for example
15:28:24 <Son_Goku> and when you're trying to fix the main Fedora deliverables, it sucks that the Atomic-only CI stops you
15:28:24 <pingou> adamw: this is an interesting point
15:28:36 <Son_Goku> and you can't even fix atomic stuff anyway
15:29:02 <pingou> bookwar: dperpeet: is the reverse dependency testing something that's in the roadmap for the CI system?
15:29:05 <Son_Goku> bookwar, and lets not forget that taskotron and bodhi can enforce all kinds of checks irrespective of gating.yml for failing a build for CI
15:29:23 <pingou> Son_Goku: that's not correct :)
15:29:39 <Son_Goku> pingou, they don't right now, but they *can*
15:29:44 <pingou> taskotron doesn't enforce anything
15:29:52 <pingou> Son_Goku: no really, taskotron cannot :)
15:30:00 <Son_Goku> well, yes, strictly speaking, taskotron can't do much except run what it's told to run :)
15:30:21 <pingou> only bodhi can enforce either based on its logic or relying on greenwave's decision engine
15:30:24 <dperpeet> pingou, bookwar I'd say reverse dependency testing is something that's proven well for other established systems, so yes it should be there
15:30:45 <pingou> dperpeet: there being on the roadmap?
15:30:50 <mhroncok> can we go back to workflow?
15:30:51 <dperpeet> yes
15:30:57 <pingou> dperpeet: ok thanks
15:31:00 <bookwar> Son_Goku: that's why we need a gating: to let various systems which run something to make use of those runs
15:31:02 <pingou> mhroncok: please :)
15:31:25 <Son_Goku> bookwar, also, lets not forget how little of these tests can be run locally :)
15:31:26 <mhroncok> let's assume I've opted in for gating for my package
15:31:38 <mhroncok> so I do: fedpkg build
15:32:01 <mhroncok> the package is built, tagged into some gating tag or whatever, all the different kinds of tests are started
15:32:40 <mhroncok> 1st, I want to get an instant feedback about the bodhi update - but the build is async, so teh feedback is async as well
15:33:00 <pingou> correct
15:33:24 <mhroncok> 2nd, in bodhi, I need to see what kinds of tests will run (or are already running), being able to click on them and see the details
15:33:37 <pingou> well the bodhi update will be automatically created right after the build, so it'll not be instant but still quite quick
15:33:56 <mhroncok> pingou: but how do I know about the bodhi update?
15:34:08 <mhroncok> do i get an e-mail? is it linked from koji build?
15:34:11 <pingou> mhroncok: how would you like to know?
15:34:23 <pingou> just going to the UI would work or would you like something else?
15:34:37 <mhroncok> what UI - that's where I'm heading
15:34:50 <pingou> bodhi.fp.o
15:34:52 <mhroncok> so i do fedpkg build --nowait
15:34:53 <Son_Goku> alright folks, I gotta go, I'll be back in a bit
15:34:58 <mhroncok> and i geta  koji link to probe
15:35:21 <adamw> well, we already *have* koschei doing reverse build tests, right? have we thought about just having koschei file results to resultsdb?
15:35:21 <mhroncok> I shouldn't need to rememeber to go to bodhi and see my updates if it is there yet
15:35:36 <pingou> adamw: kicked an email just on that question this morning :)
15:35:53 <adamw> great
15:36:05 <pingou> mhroncok: you shouldn't have to go there at all if the tests pass
15:36:35 <mhroncok> pingou: the tests will take days to finsih, especially if we do the koschei thing
15:36:42 <pingou> unless you want to monitor them indeed
15:36:46 <mhroncok> I want to be able to monitor the progress, as I'm with the build
15:36:47 <bookwar> mhroncok: if you do --nowait, you need to remember that you are not done yet anyway, how would you like to get reminded about it?
15:37:09 <mhroncok> bookwar: I have the link for koji right away - that's one place I check
15:37:20 <mhroncok> now I need to figure out the second link
15:37:38 <pingou> mhroncok: I believe bowlofeggs' idea was to have comment be added for messages from the CI system about running, passed/failed
15:37:58 <pingou> so the bodhi notifications about new comment would kick in there and let you know about this
15:38:15 <mhroncok> I don't get bodhi notification for updates soembody else created
15:38:19 <bookwar> mhroncok: how does it work for builds to stable branches currently? where you need karma?
15:38:38 <mhroncok> bookwar: for stable, i create the update - that's the current workflow
15:39:05 <mhroncok> for rawhide, i don't - and that's what everybody is used to - so we need to remind them -> bah, here's your bodhi update
15:39:14 <bookwar> if you get email when bodhi update is created, will it be sufficient?
15:39:20 <pingou> mhroncok: I'll follow up on this with bowlofeggs but one option would be to have the update be created under the user who made the build
15:39:35 <mhroncok> see this tab? it says 5 tests are running, 3 are already OK and 15 more will yet to strat
15:39:53 <mhroncok> click on this test to see what's going on
15:40:39 <mhroncok> oh, it errored because whatever? click this "restart test" button to make it run again or check this "ignore result" checkbox if you know what you are doing
15:41:25 <bookwar> mhroncok: this are points to bodhi interface, before you were saying you need a way to _get_to_ bodhi interface in the first place
15:41:54 <mhroncok> bookwar: yes, i'm still saying that
15:41:57 <pingou> (good ones nonetheless)
15:42:04 <mhroncok> I need both
15:42:37 <bookwar> ok
15:42:54 <mhroncok> the updates ebing created under my user probably solve the "get the update link" problem
15:43:00 <cverna> so we need to tell the the packager which update was automatically created
15:43:15 <cverna> so he can go there and check the status of the tests
15:43:20 <cverna> to summarize
15:43:22 <pingou> yes
15:43:23 <bowlofeggs> .hello2
15:43:24 <mhroncok> or debug
15:43:25 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:43:42 <pingou> Hi bowlofeggs, we were just thinking about you :)
15:43:54 <nirik> depending on your FMN settings, you could get an email about  the update create even if you don't create it...
15:43:54 <mhroncok> cverna: yes
15:43:56 <bowlofeggs> mhroncok, pingou: actually, sebwoj wrote a patch for bodhi that comments when the test gating status changes, so it's not just an idea, it's implemented (not released yet, will be in 4.0.0)
15:44:00 <nirik> if you just own the package
15:44:43 <bowlofeggs> mhroncok, pingou: yeah i think we would show the user who build the package as the one who created the update
15:44:46 <mhroncok> nirik: you can. that's good, but we want this to be easy, so unless this is the default, it's not very helpful
15:44:48 <bowlofeggs> so you should get an e-mail
15:45:22 <mhroncok> and than you get 85 more e-mails at the tests pass/fail?
15:45:25 <nirik> sure, I am just also saying some people could opt out if they deliberately do so...
15:45:43 <pingou> bowlofeggs: do you remember if the comment on gating status changes include a link to the corresponding jenkins' job?
15:45:50 <mhroncok> I don't think the test results should comment, you should just be able to see it
15:46:07 <pingou> mhroncok: one doesn't go against the other
15:46:09 <bowlofeggs> mhroncok: well if it's one update you should only get one e-mail when the tests pass/fail
15:46:14 <bowlofeggs> a mass build should go into one update
15:46:28 <mhroncok> bowlofeggs: so it's always just one test?
15:46:31 <pingou> but the commit gives you this notification/states of thing while not making you go to bodhi's UI
15:46:42 <mhroncok> I assumed the idea is that you can have plenty different tests in gating.yaml
15:46:46 <mhroncok> incl. reverse deps
15:46:50 <bowlofeggs> pingou: no link to a jenkins job is in the e-mail - it's just a comment telling you that a gating decision was changed
15:46:56 <bowlofeggs> you'd have to click to the update to see more
15:47:18 <pingou> roger
15:47:20 <bowlofeggs> mhroncok: it's not a comment per test, it's a comment per gating decision
15:47:27 <mhroncok> so it's just one absolute gating decision you'll get via comment? that's good
15:47:28 <bowlofeggs> so ideally, you'd just see it once
15:47:42 <bowlofeggs> in reality, the gating system is flaky and that could generate multiple e-mails
15:47:53 <mhroncok> heh
15:47:57 <mhroncok> but I get it
15:48:09 <mhroncok> so I go to bodhi and I see that there are tests that will run?
15:48:18 <mhroncok> or i only see the tests that already started?
15:48:35 <bowlofeggs> mhroncok: currently you can only see the tests that finished
15:48:37 <mhroncok> aka do I get instant feedback on: what is this update waiting for?
15:48:45 <bowlofeggs> so you can't see planned ones or currently running ones, unfortunately
15:48:48 <bowlofeggs> i would like that though
15:49:04 <mhroncok> that's IMHO a must for good UX of this
15:49:04 <pingou> the CI pipelines announces when it starts a new run
15:49:18 <bowlofeggs> mhroncok: yeah i've long wanted that too - otherwise you can't know if the system is stuck or not
15:49:23 <adamw> taskotron does not, at present
15:49:25 <mhroncok> if I see an automatic update stuck in bodhi for 3 days I want to be able to see what's going on
15:49:36 <adamw> there is an interesting problem there too: for some taskotron tests it's difficult or impossible to do
15:49:55 <mhroncok> well we know what the package is being gated on
15:49:56 <adamw> because the test job runs on an entire tag, and you can only figure out what packages it ran on *when it's done*
15:50:03 <pingou> adamw: it kinda does via execdb
15:50:11 <adamw> but yeah, listing tests expected for the gating would be easy
15:50:15 <mhroncok> so at least we can say: this is gated on taskotron.whatnot.lint and it is yet to be started/finsihed
15:50:20 <bowlofeggs> mhroncok: yeah that's a good point, we could at least say we are waiting on the ones we gate on
15:50:46 <mhroncok> and while the update is being gated
15:50:47 <pingou> I believe greenwave does give us that info
15:50:55 <pingou> we may just not be showing it right now
15:50:57 <mhroncok> is it, or is it not available in the buildroot?
15:50:57 <adamw> pingou: ok, i meant it does not do it via the 'standardized' fedmsgs :)
15:51:06 <pingou> adamw: fair :)
15:51:46 <pingou> mhroncok: for me, as long as the update isn't stable it's not in the buildroot
15:52:05 <pingou> (just like side-tag currently are)
15:52:14 <mhroncok> and i can do buildroot override if I need to? so the experience is similar to stable releases
15:52:44 <pingou> with side-tags you can't quite buildroot override, you could rebuild the package in your own side-tag though
15:53:05 <pingou> then there may be a conflict when merging the two side-tags (because one will have a newer build)
15:53:14 <mhroncok> so each update gets it's own side tag by magic?
15:53:34 <pingou> at this point, the second side-tag being merged will need to rebuild that package again
15:53:43 <mhroncok> (I'm lost)
15:53:46 <pingou> mhroncok: that's the idea for multi-build updates
15:53:59 <mhroncok> and what's the idea with single package updates?
15:54:06 <pingou> which is what you're describing (if you need a buildroot override, you're in a multi-build update)
15:54:06 <mhroncok> so I do a build, it gets and update
15:54:16 <mhroncok> gating fails - oh, i need to rebuild this as well - what do i do?
15:54:36 <pingou> create a side tag, move your build to it, rebuild this in that side-tag
15:54:40 <mhroncok> unpush and start over with a different approach?
15:54:57 <mhroncok> err
15:55:12 <pingou> bowlofeggs: would we be able to edit an existing update to replace a build (or list of builds) by a side-tag?
15:55:37 <pingou> or should we open a new update from this side-tag that will deprecate the existing update?
15:56:16 <bowlofeggs> pingou: hmm, i hadn't considered this problem, but yeah i agree we need to do something
15:56:37 <bowlofeggs> it might be nice to allow converting an update to a side tag
15:56:48 <bowlofeggs> and it'd be nice if bodhi could move that build for you in doing so?
15:57:16 <pingou> should bodhi then create the side-tag as well?
15:57:26 <pingou> so you build, it creates an update, tests fail
15:57:35 <pingou> you go to the ui and click on "convert to side-tag" ?
15:57:39 <bowlofeggs> our original plan had bodhi creating side tags, but we had decided that fedpkg would do it via a koji plugin more recently
15:58:03 <pingou> one isn't against the other
15:58:08 <bowlofeggs> if we make it so you can create it either way, i guess that's ok (but more work for bodhi ☺)
15:58:14 <pingou> esp in the case where you know in advance you'll need a side-tag
15:58:32 <mhroncok> I like the  "convert to side-tag" idea
15:58:42 <mhroncok> and when I build in the side tag, it gets added to the update
15:58:56 <mhroncok> so i don't have to do anything
15:59:10 <mhroncok> other than click "ready/submit" in the update
15:59:21 <bowlofeggs> yeah we were going to have a "create update from side tag" which was going to work like this
15:59:48 <bowlofeggs> but it wasn't going to create the side tag itself. i guess we could make it do that, but then we diverge from what bookwar is working on a bit
16:00:06 <pingou> I don't think so
16:00:15 <pingou> because you still need fedpkg side-tag create
16:00:39 <pingou> what the bodhi "convert to side-tag" gives us is a shorter way to do: fedpkg side-tag create
16:00:48 <pingou> koji move tag1 tag2 <build>
16:00:59 <bowlofeggs> yeah
16:01:19 <tibbs> Are normal users allowed to run koji move?
16:01:32 <bowlofeggs> nirik: ^?
16:01:41 <pingou> so convert-to-side-tag sounds like a good improvement, but likely something for a 1.1 or 1.2
16:01:57 <pingou> assuming the answer to tibbs' question is yes :)
16:03:27 <mhroncok> what's the UX of seeing the test run, being able to restart them and being able to waive them?
16:03:33 <cverna> I might have got it wrong but if a single build update fails gating and you need to build a second package to fix the tests, then it becomes a multi build update right ?
16:03:37 <nirik> I assume if they have perms to both tags
16:03:41 <pingou> cverna: yes
16:04:01 <cverna> ok so we need multi-build for the first release
16:04:24 <pingou> cverna: or you waive that build and opt-out for the other ones
16:04:50 <cverna> then better not opt-in at all if you can fix the tests
16:05:23 <cverna> that frustrating to be able to fix something
16:05:26 <cverna> not*
16:05:31 <pingou> fair
16:05:49 <bookwar> mhroncok: waiving is centralized, it is integrated with greenwave, there is a cli to waive, but i guess bodhi button to issue a waiver is also possible. For retrigger CI system must provide a "rebuild" link  in the message when it sends a result
16:06:06 <mhroncok> messages, clis, uaaa
16:06:14 <bookwar> cverna: you can retrigger failed test once  the other fix has landed
16:06:48 <bowlofeggs> mhroncok: bodhi has a button to waive tests, but i've never witnessed that working correctly and haven't heard of anyone else who has so…
16:06:56 <bookwar> mhroncok: remember that the other half of the community reacts the same way on "bodhi, click, interface, AAA"
16:06:57 <pingou> bookwar: we're in the case where there is no side-tag, so all builds are considered independently
16:07:00 <mhroncok> I see a fialure in bodhi, I want a [restart] button and an [ignore] checkbox - of course being able to do this via command line is a good thing, but I don't want (as a packager) to think about builds, messages, greenware, etc.)
16:07:33 <bowlofeggs> mhroncok: +1
16:08:09 <pingou> mhroncok: anything else on your list?
16:08:18 <pingou> otherwise I'd like to try to summarize what I wrote down
16:08:26 <bookwar> mhroncok: i was providing the background, but yes, all actions are available, it shouldn't be a big deal to add them in the ui
16:08:38 <mhroncok> there was no answer for "how do i see the test run, its progress"
16:09:03 <mhroncok> but that I guess is more of a question for individual tests systems
16:09:15 <bookwar> currently we don't have requirement on CI systems to send a test running message
16:09:25 <pingou> one thing we could do it comment on the update with links to the tests
16:09:27 <bookwar> we have this message defined, bt it is considered optional
16:09:44 <pingou> (for the systems that do support these messages ^)
16:10:14 <bookwar> generally we need to work on a CI system requirements doc, i think
16:10:17 <mhroncok> (getting a linkt ot he test is one thing, seeing some output form the tast is a second thing)
16:10:55 <mhroncok> anyway, pingou, I'll let you summarize :) thanks
16:11:05 <pingou> so;
16:11:39 <pingou> - I want to be informed about the bodhi update that's created for my build (let's agree to inform only at the point there is something of interest for the packager: tests started, tests completed)
16:12:02 <pingou> - I want to see what is blocking the update from going through (pending test results)
16:12:12 <pingou> - I want to retest/waive from the UI (and the CLI)
16:12:38 <pingou> - I would like to be able to convert a single build update into a side-tag-based update
16:13:07 <pingou> - I would like to be able to follow the progress of test system
16:13:46 <pingou> mhroncok: did I miss anything ?
16:14:12 <mhroncok> I don't think so
16:14:38 <pingou> based on this, I think we may want to merge back the two proposals into one
16:15:09 <pingou> so we have multi-builds update available to fix unexpected but valid issues with single-build
16:15:12 <cverna> mhroncok: would you be able to give some priorities to these ( must have, can be done in a second phase)
16:15:42 <mhroncok> single build update into a side-tag-based update is probably a good candidate to "nice to have"
16:15:54 <pingou> for me the last two are nice to have
16:16:07 <pingou> (thus would like), while the top three are must (thus want)
16:16:08 <mhroncok> I want to retest/waive from the UI (and the CLI) - having at least UI or CLI is a must, having both is nice
16:16:56 <mhroncok> I would like to be able to follow the progress of test system - that is a very very nice to have - it should probobly not block the thing but it is very bad UX to wait in the dark
16:17:01 <pingou> mhroncok: would one be in the CLI and the other in UI, be good?
16:17:11 <mhroncok> pingou: sufficient
16:17:28 <pingou> mhroncok: well, you would know what you're waiting on, but not what it's doing
16:17:31 <pingou> mhroncok: ok
16:18:46 <cverna> I think this is the type of thing you want to do at the same time anyway ( adding support to the UI and CLI) so that when you develop the change you have the context
16:19:06 <cverna> would be weird to come back after few weeks to add support to the CLI or UI
16:20:12 <pingou> cverna: there are sometime challenges around authenticated to other applications via a website :)
16:20:34 <pingou> for some reason people do not like that we send requests pretending to be them to other websites :]
16:20:48 <pingou> anyway, technical details to be sorted out
16:21:08 <pingou> do we want to add anything?
16:21:22 <pingou> otherwise, we've been at this for over a hour and I think we deserve a break :)
16:21:49 <pingou> I'll be trying to send a summary of all this tomorrow and see how to adjust the proposal based on these feedback :)
16:21:53 <mhroncok> I still have concerns about the actual CI
16:22:23 <mhroncok> there was no reply on devel
16:22:27 <pingou> mhroncok: do you think you could gather them all in an email?
16:22:39 <mhroncok> I have
16:22:49 <pingou> your email to the thread about gating?
16:22:54 <mhroncok> yes
16:22:59 * mhroncok looks for a link
16:23:03 <pingou> I've forwarded it already, I'll ping again asking for their inputs
16:23:22 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QUDIXHS4EWJFILODUL6JZJOAWCQ5M5L7/
16:23:29 <pingou> thanks :)
16:23:35 <cverna> I think these concerns should be directed to the council, since the CI  is a council objective
16:23:52 <cverna> we should seek council support to address these
16:24:17 <pingou> let's me try a more diplomatic way first and if there is no response we could consider this :)
16:24:43 <mhroncok> pingou: what's the diplomatic aperoach?
16:24:47 <mhroncok> *approach
16:24:55 <cverna> works for me, I saw the council as diplomatic :)
16:25:04 <pingou> mhroncok: I'm going to email them again asking them to reply :)
16:25:24 <mhroncok> I think the problem is that we need more people to work on this (and be responsible for it) - should we e-mail Red Hat instead?
16:25:32 <pingou> cverna: about as diplomatic as going to your boss asking for your attention :)
16:25:54 <cverna> pingou: not really because the CI lead is part of the council
16:26:36 <pingou> mhroncok: I'll try to get more eyes on this email
16:26:38 * cverna considers the council as helper rather than bosses
16:26:39 <mhroncok> anyway it would be nice to hear what the "CI people" actually need, if it is people, money, machines, time...
16:26:51 <mhroncok> pingou: thnaks
16:27:13 <pingou> I wonder if time machines would help with the money angle :-p
16:27:23 <pingou> sorry, disgressing :)
16:27:31 <bookwar> mhroncok: we need to build CI people community to start hearing from "them" i think
16:27:32 <pingou> should we end here ?
16:27:46 <mhroncok> pingou: good for me
16:27:50 <mhroncok> bookwar: but how?
16:27:51 <cverna> thanks pingou
16:27:58 <mhroncok> pingou++
16:28:02 <pingou> #endmeeting