15:02:08 <jsmith> #startmeeting FESCO (2018-04-27)
15:02:08 <zodbot> Meeting started Fri Apr 27 15:02:08 2018 UTC.  The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:08 <zodbot> The meeting name has been set to 'fesco_(2018-04-27)'
15:02:09 <jsmith> #meetingname fesco
15:02:09 <zodbot> The meeting name has been set to 'fesco'
15:02:09 <jsmith> #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek
15:02:09 <zodbot> Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:02:09 <jsmith> #topic init process
15:02:16 <sgallagh> .hello2
15:02:17 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:17 <jsmith> .hello2
15:02:18 <bowlofeggs> .hello2
15:02:19 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:02:20 <zbyszek> .hello2
15:02:23 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:02:25 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:29 <nirik> morning
15:02:37 <jsmith> We have quorum :-)
15:02:47 <maxamillion> .hello2
15:02:48 <jwb> i have a work meeting :\
15:02:49 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:03:06 <jsmith> Let's get started!
15:03:12 <jsmith> #topic #1883 Request for rebase of libdnf/dnf after Fedora 28 GA
15:03:13 <jsmith> .fesco 1883
15:03:13 <jsmith> https://pagure.io/fesco/issue/1883
15:03:15 <zodbot> jsmith: Issue #1883: Request for rebase of libdnf/dnf after Fedora 28 GA - fesco - Pagure - https://pagure.io/fesco/issue/1883
15:03:27 <jsmith> Figured we'd tackle the heavy issue first :-)
15:03:35 <sgallagh> I think this was resolved last week?
15:03:40 <zbyszek> I don't think there's anything to add.
15:03:49 <jsmith> That wasn't clear from the ticket :-(
15:04:02 <sgallagh> jsmith: Yeah, we forgot to update with the resolution until today
15:04:02 <jsmith> Oh, now it is...
15:04:08 <jsmith> OK, moving on...
15:04:09 <bowlofeggs> yeah i think we are waiting on it to go to rawhide and to have an update
15:04:20 <jsmith> #topic #1882 F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK
15:04:20 <jsmith> .fesco 1882
15:04:20 <jsmith> https://pagure.io/fesco/issue/1882
15:04:21 <zodbot> jsmith: Issue #1882: F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK - fesco - Pagure - https://pagure.io/fesco/issue/1882
15:04:21 <bowlofeggs> i will say that some of the comments about the db format changing concern me
15:04:28 <jsmith> bowlofeggs: Me too...
15:04:43 <jsmith> Also covered last week, right?
15:04:48 <zbyszek> I just closed this.
15:04:52 <bowlofeggs> yeah
15:05:06 <zbyszek> maxamillion: you forgot to update bugs
15:05:17 <jsmith> #topic #1877 large number of packages FTBFS in F28
15:05:17 <jsmith> .fesco 1877
15:05:17 <jsmith> https://pagure.io/fesco/issue/1877
15:05:20 <zodbot> jsmith: Issue #1877: large number of packages FTBFS in F28 - fesco - Pagure - https://pagure.io/fesco/issue/1877
15:05:25 <sgallagh> zbyszek: He has a newborn at home. I think we can forgive him :)
15:05:29 <jsmith> OK, as far as I know, this one *hasn't* been resolved :-)
15:05:32 <zbyszek> Oh, right.
15:06:02 <jsmith> I can volunteer to try to fix the nodejs-* packages in the list.
15:06:19 <tyll_> .hello till
15:06:20 <zodbot> tyll_: till 'Till Maas' <opensource@till.name>
15:06:26 <maxamillion> zbyszek: I did, I'm so sorry. Completely forgot, that's on me.
15:06:33 <nirik> not too sure what we can do on this one...
15:06:37 <sgallagh> jsmith: We need to have a conversation in the SIG about whether there is sense in having most of those in Fedora at all
15:06:51 <sgallagh> Since that's not really how Node upstream works
15:07:06 <jsmith> sgallagh: I know, but.... yeah.... let's have the discussion offline
15:07:07 <bowlofeggs> there was some actions we agreed to two weeks ago
15:07:08 <zbyszek> maxamillion: no worries, it was two tickets anyway or something like that.
15:07:14 <maxamillion> +1
15:07:16 <maxamillion> Thanks
15:07:20 <bowlofeggs> AGREED: till will create a list of FTBFS packages, post it to devel and announce that they will be retired in 6 weeks if not being worked on (+6, 0, -0) (tyll, 15:31:57)
15:07:20 * bowlofeggs till will send a list of FTBFS packages to devel and retire them in 6 weeks (tyll, 15:32:13)
15:07:35 <bowlofeggs> (see zbyszek's comment from 13 days ago)
15:07:41 <bowlofeggs> (the shorter one :))
15:07:42 <tyll> yes, this is still on my TODO
15:07:59 <zbyszek> tyll: I think there was a releng ticket about the missing FTBFS tickets for F28... but I can't seem to find it.
15:08:08 <nirik> well, now that f28 is released (almost) we can't really retire them can we?
15:08:11 <bowlofeggs> do we have further need to discuss, or just wait for those proposed actions to take place?
15:08:16 <jsmith> I stand by my comments in https://pagure.io/fesco/issue/1877#comment-505844
15:08:21 <bowlofeggs> yeah we can't retire in f28, but we can in f29
15:08:36 <jsmith> Step one is identifying the broken packages (and hopefully notifying the maintainers)
15:08:54 <tyll> IMHO we can wait, I will follow-up on this
15:08:59 <bowlofeggs> jsmith: +1
15:09:00 <jsmith> Step two is trying to identify packages with lots of dependencies, or common causes of failures
15:09:01 <bowlofeggs> tyll: +1
15:09:12 <tyll> zbyszek: yes, I also need to file that one
15:09:15 <jsmith> Step three is work with the SIGs for the language-specific problems
15:09:35 <bowlofeggs> tyll: if you could use a hand in some way, i might be able to help a bit too :)
15:09:40 <jsmith> Proposal: Wait a week or two, tyll to follow up on this
15:09:45 <bowlofeggs> jsmith: +1
15:09:47 <nirik> sure, +1
15:09:52 <sgallagh> +1
15:09:52 <maxamillion> jsmith: +1
15:09:53 <zbyszek> jsmith: +1
15:09:54 <tyll> let's make it two weeks
15:09:58 <jsmith> ACK :-)
15:10:01 <zbyszek> Ack.
15:10:03 <tyll> there are a lot of public holidays here
15:10:17 <zbyszek> https://pagure.io/fedora-infrastructure/issue/6859 is also related.
15:10:44 <jsmith> #agreed #1877 Wait two weeks, as tyll (perhaps with help from others) will follow up on this (+1:6,+0:0,-1:0)
15:11:01 <jsmith> #info Infra ticket 6869 is likely related
15:11:17 <zbyszek> #undo
15:11:17 <zodbot> Removing item from minutes: INFO by jsmith at 15:11:01 : Infra ticket 6869 is likely related
15:11:26 <zbyszek> #info Infra ticket 6859 is likely related
15:11:38 <tyll> bowlofeggs: thank you for the offer, not sure how to properly split it as it does not make sense for each of us to work on 1000 pkgs or so ;-)
15:11:39 <jsmith> Thanks for fixing my typo :-)
15:11:46 <jsmith> #topic #1872 Disable Test Gating requirements until more UI is enabled
15:11:46 <jsmith> .fesco 1872
15:11:46 <jsmith> https://pagure.io/fesco/issue/1872
15:11:51 <zodbot> jsmith: Issue #1872: Disable Test Gating requirements until more UI is enabled - fesco - Pagure - https://pagure.io/fesco/issue/1872
15:11:52 <jsmith> bowlofeggs: Any update here?
15:12:00 <jsmith> bowlofeggs: I'm assuming you're waiting for the freeze to thaw?
15:12:14 <bowlofeggs> jsmith: actually i sorta feel like this ticket is now a holding pattern
15:12:31 <bowlofeggs> jsmith: it's not worth putting the effort into improving the batching UI unless i feel like fesco is going ot approve batching
15:12:42 <bowlofeggs> but, fesco is waiting to vote on batching for those improvements
15:12:48 <nirik> bowlofeggs: no no... this is not batching...
15:12:50 <bowlofeggs> so... that's not ideal
15:12:54 <bowlofeggs> oooh sorry
15:12:55 <bowlofeggs> hahaha
15:12:59 <bowlofeggs> uh, YES!
15:13:02 <bowlofeggs> there are updates here
15:13:23 <bowlofeggs> pingou and i have been working on a 3.7.0 bodhi release (this very day even) to fix four things
15:13:50 <bowlofeggs> release notes: https://github.com/fedora-infra/bodhi/pull/2331/files
15:13:58 <bowlofeggs> to summarize:
15:14:16 <bowlofeggs> 0) missing test names will be displayed in bodhi (useful for waiving)
15:14:43 <bowlofeggs> 1) existing waivers will be displayed on an update (there was previously no way to see waivers that had been submitted, not even with wavierdb cli)
15:15:11 <bowlofeggs> 2) the waiverDB API call in bodhi will be fixed - this will enable a bodhi UI for waiving updates which i think will help a lot
15:15:50 <zbyszek> bowlofeggs: we voted to wait until bodhi-3.6.2 last week. Should we wait for 3.7.0 instead?
15:16:01 <bowlofeggs> 3) the cron job that polls greenwave can now run in ~15 minutes instead of 2-3 hours. pingou wants us to increase the polling frequency. this one i feel a little ont he fence about because it hammers our production db
15:16:30 <bowlofeggs> zbyszek: 3.6.2 became 3.7.0 because technically two of these things are features - it's really the same patches just a different version string (bodhi uses semver)
15:16:36 <zbyszek> Ah, OK.
15:16:43 <bowlofeggs> so in spirit, it's the same release we discussed before
15:16:49 <zbyszek> What about the integration with fedmsg to avoid polling?
15:17:13 <bowlofeggs> zbyszek: we dont' haev that yet, but that is the right approach instead of #3 in my opinion
15:18:03 <zbyszek> Even without that, things will be improved a lot.
15:18:04 <jsmith> Proposal: Wait a couple more weeks for the 3.7.0 release
15:18:08 <zbyszek> +1
15:18:19 <bowlofeggs> i do think points 0-2 will really help a lot. i'm not sure i'm convinced that we should poll very frequently, though i am glad that the script is more efficient nonetheless
15:18:39 <nirik> even hourly would be better than now (6 hours)
15:18:40 <bowlofeggs> jsmith: +1 - and i anticipate releasing it next week
15:18:53 <bowlofeggs> nirik: yeah i think pingou was proposing hourly
15:19:13 <nirik> anyhow, I am +1 to waiting for these...
15:19:18 <maxamillion> I'm +1 as well
15:19:23 <maxamillion> bowlofeggs: thanks for all the information
15:19:24 <bowlofeggs> that would be a 25% hammering load on the db server. to be fair, we are doing like a 50% hammering load now since it takes 2-3 hours and runs every 6
15:19:37 <bowlofeggs> so if we ran it hourly it would be an improvement over what we currently do
15:19:48 <bowlofeggs> but i still think the fedmsg listener is the proper fix
15:19:56 <sgallagh> +1
15:20:06 <jsmith> #agreed #1872 Wait a week or two for Bodhi release 3.7.0 to get the improvements outlined by bowlofeggs (+1:6,+0:0,-1:0)
15:20:18 <jsmith> #topic #1858 Proposed Fedora 29 schedule
15:20:18 <jsmith> .fesco 1858
15:20:18 <jsmith> https://pagure.io/fesco/issue/1858
15:20:20 <zodbot> jsmith: Issue #1858: Proposed Fedora 29 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1858
15:21:43 <bowlofeggs> i'm +1 to sgallagh's proposal
15:21:51 <bowlofeggs> (one day after final freeze)
15:22:11 <zbyszek> Hmm, "2018-10-11 (one day after Final Freeze)" is wrong, because freeze is on the 9th.
15:22:22 <bowlofeggs> ah true
15:22:33 <bowlofeggs> sgallagh: should we amend it to 2018-10-10?
15:22:43 <sgallagh> uh... Can I blame timezones for that mistake? :)
15:22:50 <bowlofeggs> sure!
15:22:51 <bowlofeggs> haha
15:22:57 <zbyszek> sgallagh: US dates, I'd guess
15:23:06 <nirik> ah, the start of freeze. ok that makes more sense.
15:23:14 <sgallagh> But yeah, I meant the 10th
15:23:25 * sgallagh retroactively edits the comment
15:23:44 <jsmith> Proposal: #1858 Use sgallagh's proposal of having AppStream data freeze one day after Final Freeze
15:23:45 <bowlofeggs> +1 to 2018-10-10 for AppStream data
15:23:50 <jsmith> +1
15:23:55 <zbyszek> +1
15:24:08 <nirik> sure, +1... hopefully the people who do this will know to do it then.
15:24:22 <sgallagh> nirik: The people who do it are kalev
15:24:26 <sgallagh> So... I think we're good
15:25:16 <nirik> sure, and hopefully he can hand it off if he moves to something else. :) (I like like roles for these things rather than specific people, but thats fine)
15:25:36 <maxamillion> jsmith: +1
15:26:23 <jsmith> #agreed  #1858 Use sgallagh's proposal of having AppStream data freeze one day after Final Freeze (+1:6, +0:0, -1:0)
15:26:26 <zbyszek> Who can update https://fedoraproject.org/wiki/Releases/29/Schedule?
15:26:31 * jsmith assumes that sgallagh is +1 for his own proposal
15:26:43 <sgallagh> Yes, I am
15:27:16 <jsmith> zbyszek: The FPM, I would imagine
15:27:18 <sgallagh> zbyszek: I think any of us, but I'll do it if you want
15:27:26 <zbyszek> Oh, I can do it.
15:27:30 <jsmith> #topic #1884 provenpackager request for itamarjp
15:27:30 <jsmith> .fesco 1884
15:27:30 <jsmith> https://pagure.io/fesco/issue/1884
15:27:33 <zbyszek> I'll just update it now.
15:27:34 <zodbot> jsmith: Issue #1884: provenpackager request for itamarjp - fesco - Pagure - https://pagure.io/fesco/issue/1884
15:27:44 <nirik> FPM can also add it to all the other schedules and such.
15:28:07 <bowlofeggs> i should clarify on this ticket - i wasn't exactly -1'ing the proposal, but i did feel a bit concerned about the bz i linked
15:28:19 <zbyszek> nirik: OK, so let's leave it FPM.
15:28:21 <bowlofeggs> i want to be fair and note that that was one and only one example
15:28:25 <nirik> without -1s I was just going to process this later today....
15:28:30 <bowlofeggs> it's also the only example i've experienced though
15:28:38 <bowlofeggs> but i also dont' think one example should be a basis
15:28:44 <bowlofeggs> so i'm +0 on this one
15:29:10 <bowlofeggs> it seems like a lot of other people had different experiences than i did, so i'm happy to be outweighed, if that makes sense
15:29:14 <jsmith> While itamarjp can be frustrating at times to communicate with, I have no qualms about his packaging skills
15:29:21 <zbyszek> I read the ticket, and I didn't think it was anything more than a simple omission.
15:29:24 <sgallagh> OK, so if bowlofeggs isn't -1, then this is solved
15:29:36 <nirik> right.
15:29:39 <jsmith> And I know he's been very frustrated at waiting for PRs to be acknowledged, let alone acted on
15:30:03 <jsmith> Any last-minute objections?
15:30:14 <sgallagh> I think a lot of Fedora packagers still aren't used to that being part of the process either
15:30:30 <jsmith> sgallagh: Good point.
15:30:43 <maxamillion> sgallagh: +1
15:30:54 <jsmith> #agreed itamarjp is approved as a Proven Packager
15:31:00 <jsmith> #topic Next week's chair
15:31:11 <zbyszek> #1767?
15:31:28 <sgallagh> I think there might be value in running a Packager Modernization workshop at Flock around PRs and CI stuff.
15:31:28 <jsmith> zbyszek: Sure... let's get next week's chair, and then we'll do that one next :-)
15:31:39 <bowlofeggs> i can chair
15:31:39 <jsmith> sgallagh: Would love to help with that :-)
15:31:41 <bowlofeggs> it's been a while
15:31:50 <jsmith> #action bowlofeggs to chair the next meeting
15:31:58 <nirik> new docs would sure help too... but we are working on that. ;)
15:32:17 <jsmith> #topic #1767 F28 Self Contained Changes
15:32:23 <jsmith> .fesco 1767
15:32:23 <sgallagh> I can probably take the chair on Star Wars day if we want to book that in advance
15:32:29 <zodbot> jsmith: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767
15:32:33 * jsmith will be out on Star Wars day
15:33:01 <sgallagh> Is there anything to do here?
15:33:03 <zbyszek> proposal: FESCO acknowleges that the Noto Fonts changes were deferred
15:33:07 * nirik is fine that those were deferred.
15:33:08 <jsmith> zbyszek: Is there anything else in this ticket, other than just a note that the Google Noto font changes were deferred?
15:33:19 * jsmith is fine with it too, given the information about disk space required
15:33:20 <sgallagh> effectively, they just activated their contingency plan
15:33:21 <zbyszek> jsmith: no
15:33:51 <bowlofeggs> +1 to deferral
15:34:14 <jsmith> OK, I think it's duly noted :-)
15:34:27 <zbyszek> Or that.
15:34:50 <jsmith> #topic Open Floor
15:35:28 <bowlofeggs> i have a question that i don't have an answer for: i've observed that we often try hard to seek for a unanimous vote even when we have a +5 - is that bad or good or neutral?
15:35:36 <sgallagh> I had something, but I'm trying to remember what it was...
15:36:00 <sgallagh> bowlofeggs: Seeking consensus is a good thing, IMHO
15:36:11 <jsmith> bowlofeggs: For the procedural items, it doesn't bother me that much.  But for other bigger items ,I do like to see a little controversy :-)
15:36:30 <bowlofeggs> maybe you are right, but i can think of three downsides
15:36:40 <bowlofeggs> 0) it takes us longer (maybe that's fine)
15:37:02 <bowlofeggs> 1) we might be making "weaker" decisions (does that make sense? like, less opinionated decisions i mean)
15:37:32 <sgallagh> 1) I think you mean "compromises"
15:37:43 <bowlofeggs> 2) i wonder if we might be each trying to have a "friendly feeling" group at the expense of voicing controversy sometimes, maybe?
15:37:51 <bowlofeggs> sgallagh: yeah
15:37:55 <bowlofeggs> maybe that's not bad
15:38:00 <zbyszek> I think "weak" decisions are good. Almost no decisions are binary, yes/no, but something in between. The fact that everybody is +1 means that all concerns were solved or at least discussed in a satisfactory way.
15:38:01 <bowlofeggs> i just have been thinking about it for a while
15:38:12 <bowlofeggs> yeah true
15:38:24 <sgallagh> I absolutely think that controversy should be voiced if it's believed
15:38:31 <sgallagh> (And notjust for sake of argument)
15:38:32 <bowlofeggs> yeah and maybe it is
15:38:40 <jsmith> bowlofeggs: I've long since given up on "friendly feelings" in FESCo meetings... If I have something to say, I say it :-)
15:38:46 <sgallagh> Because that helps us *reach* a working compromise.
15:38:47 <bowlofeggs> haha
15:38:48 <bowlofeggs> cool
15:38:49 <nirik> I think reaching concensus is much better
15:38:53 <bowlofeggs> so maybe #2 isn't a real problem
15:39:20 <jsmith> For me it's not -- maybe it is for others.  I don't want to put words in anyone else's mouth
15:39:21 <bowlofeggs> cool, well that's all i had to say about that
15:39:38 <sgallagh> And yeah, there are definitely places where compromise will never happen because things are truly binary
15:39:52 <zbyszek> Even for stuff like "orphan all packages of x", if there's disagreement, this most likely means that something is off, maybe we didn't wait the prescribed time or whatever, and with additional delay everybody will be +1. In that case striving for consensus clearly results in a better outcome.
15:40:04 <sgallagh> For example if we were to propose to stop blocking on KDE or Server Edition.
15:40:11 <sgallagh> There's really no middle-ground there.
15:40:23 <sgallagh> zbyszek: +1
15:40:33 <jsmith> sgallagh: What, no "soft blocks"?
15:40:36 * jsmith ducks and hides
15:40:41 <sgallagh> .fire jsmith
15:40:41 <zodbot> adamw fires jsmith
15:40:52 <jsmith> OK, I deserved that :-)
15:41:10 <tyll> I have something to discuss
15:41:24 <jsmith> tyll: Please, go ahead!
15:41:25 <sgallagh> tyll: Go ahead (bowlofeggs said he was done)
15:41:44 <tyll> Currently we are using one ticket for all Change requests instead of one ticket for each change
15:41:54 <sgallagh> Not exactly
15:42:04 <sgallagh> We have a single ticket for Self-Contained Changes
15:42:09 <sgallagh> And individual ones for system-wide
15:42:14 <tyll> IMHO this makes things more complicated because the ticket gets very long and it is hard to see what the actual status is
15:42:19 <sgallagh> The idea being that Self-Contained ones are usually mass-approved.
15:42:22 <tyll> ah, I did not realize this
15:42:35 <zbyszek> Yeah, we should probably start a new ticket for each batch of self-contained changes.
15:42:42 <dgilmore> hi
15:42:45 <sgallagh> But yeah, what zbyszek said
15:42:56 <sgallagh> Rather than reopening the same ticket every time
15:43:18 <bowlofeggs> yeah i've also had this thought
15:43:25 <bowlofeggs> i think it would be nice if they just each had their own ticket
15:43:38 <bowlofeggs> because discussion in ticket can also be noisy if there ever needs to be any
15:43:49 <nirik> the plan for self contained was that usually we could just say 'they all look fine'
15:44:00 <nirik> but we do end up discussing some sometimes
15:44:01 <sgallagh> Hey, time for a compromise!
15:44:16 <nirik> NO! death before multiple tickets!
15:44:16 <sgallagh> For any that we end up discussing individually, we split out into its own ticket.
15:44:20 * nirik kids
15:44:32 <sgallagh> Leaving the mass-approval ticket as-is.
15:44:48 <sgallagh> That will allow us to keep discussion (when warranted) associated with the right items
15:44:53 <tyll> how do we get this implemented? Do we just need to ask jkurik or is there also some docs that need to be updated?
15:44:57 <sgallagh> But then just have one ongoing ticket for rubber-stamped issues.
15:45:09 <sgallagh> tyll: I think we just create a new ticket on the fly when debate occurs.
15:45:22 <zbyszek> bad news: pagure implements the ticket number as int16_t, we need to conserve the numbers
15:45:34 <sgallagh> zbyszek: You're joking, right?
15:45:39 <zbyszek> yes ;)
15:45:41 <bowlofeggs> haha
15:45:45 <sgallagh> please don't do that!
15:45:57 <jsmith> zbyszek: You had us all worried :-)
15:46:01 <jsmith> zbyszek: Good one!
15:46:24 <tyll> sgallagh: ok, this sounds good
15:46:35 * nirik is waiting for... now lets discuss ticket ⛄
15:46:41 <zbyszek> sgallagh: I don't think this is going to work, because by the time discussion occurs, there will be multiple comments on the original ticket
15:46:53 <zbyszek> Then if we create a new one, discussion will be split.
15:47:37 <sgallagh> Well, it's usually US making the comments.
15:47:56 <sgallagh> Can't the nine of us remember to create a new issue and just link it in the original ticket?
15:48:25 <sgallagh> But hey, if you want to just have separate tickets from the start, I'm not strongly opposed.
15:48:33 <jsmith> sgallagh: Actually, I think it's the FPM that usually creates the tickets :-)
15:48:46 <sgallagh> jsmith: I meant when we dissent
15:48:54 <sgallagh> To have the conversation in a dedicated ticket
15:49:01 <jsmith> sgallagh: Ah, yeah -- I like that idea better
15:49:08 <jsmith> sgallagh: I wasn't following, but now I see the light :-)
15:49:09 <sgallagh> jsmith: Which one?
15:49:17 <nirik> right, so when we have 10 of them in the ticket and 1 we want to discuss, we say 'those 9 are ok' and make a new ticket for the other one
15:49:25 <jsmith> I love it
15:49:36 <bowlofeggs> sounds fine to me
15:49:56 <zbyszek> I'm not convinced, but we can try that for a while and see.
15:50:34 * dgilmore thinks its fine but we should discuss in the change ticket :D
15:50:51 <sgallagh> haha
15:50:54 <jsmith> dgilmore: Huh?  Then what goes in the new ticket?
15:50:59 <zbyszek> dgilmore: a single one or one for each of the proposed versions?
15:51:02 <tyll> just wondering, in which cases is a single ticket better?
15:51:03 * jsmith is thoroughly confused again...
15:51:12 <tyll> Is it to make it less work to close it/add the approved stamp?
15:51:14 <sgallagh> jsmith: I think dgilmore was making a joke
15:51:16 <sgallagh> (I hope)
15:51:41 * zbyszek assumed so too
15:51:41 <dgilmore> sgallagh: I was trying to be funny
15:51:47 <tyll> And would you add a single topic to the meeting for each individual item?
15:52:02 <sgallagh> dgilmore: I thought it was funny. Then I started worrying it was serious and got nervouse.
15:52:04 <sgallagh> *nervous
15:52:04 <tyll> Because then it is more work to get through the ticket instead of just query the tickets once
15:52:06 <jsmith> Everyone's a comedian today...
15:52:17 <nirik> I think we should form a subcomittee to discuss discussing in tickets tickets where we discuss.
15:52:41 <jsmith> Who's going to open a ticket to assign the tickets to the tickets subcommittee?
15:52:50 <dgilmore> perdóname jsmith
15:52:54 <bowlofeggs> we need a committee to decide what color of labels we should put on the tickets
15:52:59 <bowlofeggs> and a committee to oversee that committee
15:53:11 * jsmith thinks we're nearing the end of the useful discussion...  and lights the fuse
15:53:16 <bowlofeggs> lol
15:53:30 <jsmith> Last chance for open floor discussions...
15:53:45 <maxamillion> light the fuse :)
15:53:48 <tyll> I had some serious questions about it
15:53:49 <sgallagh> #info Congratulations on shipping F28!
15:54:06 <maxamillion> yesss!!!
15:54:08 <jsmith> Yay!
15:54:12 <maxamillion> oh man, first time on-time in how many releases?
15:54:16 <sgallagh> ah, yes. tyll did have a couple other questions
15:54:16 <zbyszek> We did not get a chance to discuss #1878, but I think it's better to continue the discussion in the ticket.
15:54:20 <jsmith> maxamillion: Ever, according to adamw
15:54:20 <dgilmore> tyll: what is your serious questions?
15:54:25 <sgallagh> maxamillion: According to adamw on the mailing list... first ever
15:54:26 <zbyszek> maxamillion: adamw says the first, on phoronix
15:54:32 <tyll> just wondering, in which cases is a single ticket better?
15:54:37 <tyll> Is it to make it less work to close it/add the approved stamp?
15:54:42 <sgallagh> tyll: Yes, mainly
15:54:43 <tyll> And would you add a single topic to the meeting for each individual item?
15:54:47 <dgilmore> tyll: likely when it is contentious
15:54:49 <tyll> Because then it is more work to get through the ticket instead of just query the tickets once
15:55:11 <sgallagh> No, we are supposed to mass approve those that make sense and only create individual items for those that have a disagreement raised
15:55:12 <dgilmore> tyll: I would think you would work as we have until something had to be seperate
15:55:30 <tyll> ok
15:55:39 <jsmith> zbyszek: Sorry, didn't see the meeting tag on that one... we already have the concept of "enchilada", maybe we just call it "taco" or "burrito" or something obtuse...
15:55:51 <jsmith> zbyszek: Let's discuss in ticket, and bring up again next week
15:55:55 <sgallagh> ?
15:55:56 <jsmith> zbyszek: I don't think there's any rush on it
15:55:58 <nirik> it would allow moving discussion out of the main 'self contained' ticket
15:56:18 <zbyszek> jsmith: yes, agreed.
15:56:30 <dgilmore> a good point to make the change woule be in rawhide right after branching
15:56:53 <dgilmore> give as long as possible to weed out any issues
15:57:37 <jsmith> Going once....
15:58:01 <sgallagh> Thanks for chairing, jsmith
15:58:03 <jsmith> ... going twice ....
15:58:26 <jsmith> ... and sold to the highest bidder.  Thanks everyone!
15:58:29 <jsmith> #endmeeting