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