18:00:34 <mmaslano> #startmeeting FESCO (2014-01-15)
18:00:34 <zodbot> Meeting started Wed Jan 15 18:00:34 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:38 <mmaslano> #meetingname fesco
18:00:38 <zodbot> The meeting name has been set to 'fesco'
18:00:42 <mmaslano> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:00:42 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:54 <nirik> morning
18:00:54 <t8m> hi again
18:00:57 <pjones> hello again.
18:00:58 <mmaslano> hi
18:01:02 <mmaslano> #topic init process
18:01:04 <sgallagh> .hellomynameis sgallagh
18:01:05 <abadger1999> greetings
18:01:09 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:01:14 * notting is here
18:01:37 * sgallagh is splitting his attention with the Cloud WG meeting.
18:01:38 <mitr> Hello
18:01:40 * jsmith lurks
18:01:44 * mmaslano has only one hour, so there will be end in 60 minutes (or someone could take it after me)
18:01:58 <mmaslano> #topic 1197 Procedure for suggesting/approving different Products and/or WGs?
18:02:03 <mmaslano> .fesco 1197
18:02:05 <zodbot> mmaslano: #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo - https://fedorahosted.org/fesco/ticket/1197
18:02:39 <mmaslano> jreznik: do you think we need to solve it now?
18:02:41 <mmaslano> and how?
18:02:44 * mattdm is here
18:03:06 <mattdm> I have what I think is a pretty clear picture in my mind for this.
18:03:25 <mattdm> Basically, if you want to make a new product, you start with a SIG
18:03:26 * jreznik is here
18:03:29 <notting> as the guy that filed it, i think we need to solve it before f21. maybe not *today* - could be solved post PRD-approval and F21-plan approval
18:03:37 <mattdm> and follow the same process -- formal membership, governance, prd
18:03:55 <mattdm> and then start as a "secondary product".
18:04:00 <mmaslano> mattdm: sounds good
18:04:05 <t8m> mattdm, that looks good
18:04:11 <drago01> notting: can't we keep the other spins as is for f21 ?
18:04:15 <mattdm> then as with arches, we promote to primary when it's demonstrated to be ready and long-term viable
18:04:27 <notting> drago01: that implies the repo they're pulling from will be the same
18:04:47 <drago01> notting: the questions is ... will it be the same?
18:04:54 <drago01> (I don't know)
18:04:55 <jreznik> mattdm: do currently pre-approved products have to demonstrate the same?
18:04:55 <nirik> the spins process isn't so great currently, IMHO
18:05:05 <abadger1999> drago01: That really depends on the implementation of F21 which we don't know yet.
18:05:15 <jreznik> nirik: it is not but it could be use as base for this process
18:05:16 <mattdm> jreznik which? long term viability?
18:05:40 <jreznik> mattdm: yep, fulfiling PRD etc
18:05:43 <nirik> I'd prefer a new process personally... one that doesn't depend on one person.
18:06:09 <mattdm> jreznik yes. happening now, right?
18:06:17 <notting> drago01: it's certainly not required that way. mattdm's original proposal of rings would obviously break spins pretty hard. the three-product plan allows walking that back somewhat
18:06:24 <mitr> notting: We've had about zero changes to the product delivery mechanism / repos etc. so far; so either we can continue to use the existing spin process, or planning for how to reuse some future currently-nonexistent mechanism for additional spins is going to be si vague that detailed discussions are probably premature.
18:06:51 <mitr> nirik: The alternative being depending on may persons none of which feels responsible?
18:07:15 <nirik> no.
18:07:32 <t8m> I think we could agree on the mattdm's proposal or rather encourage him to make it a formal one.
18:07:38 <nirik> the alternative being some process with things defined and putting the burden on the spin owners to move those forward.
18:07:55 <mattdm> t8m do I have to write all of that up in a one-liner? :)
18:08:05 <Viking-Ice> nirik, I thought that was the plan as well as for the WG's output
18:08:17 <notting> mitr: we haven't changed it yet, but we also haven't ruled out changing it. so it may be too early to say, but i think saying 'use the existing spins process' today won't work for the same reason
18:08:21 <Viking-Ice> anything on top of base they have to handle themselves
18:08:22 <t8m> mattdm, noep
18:08:22 <nirik> I think a wiki page would be good with any plan at least...
18:08:25 <t8m> mattdm, nope
18:08:48 <nirik> Viking-Ice: I am talking process, not packages.
18:08:50 <t8m> mattdm, I meant a proposal for further meeting to be formally accepted
18:08:57 <mitr> notting: Are we considering killing the existing spins?  If not, the new process will have to accommodate them and then we can fairly naturally reuse them for proto-products
18:09:01 <mattdm> nirik do you mean a wiki page for the overall plan, or a wiki page for "what might happen to spins", or a wiki page for specific spins?
18:09:08 <Viking-Ice> nirik, right sub-community handle their own process regardless if it's a product or a spin
18:09:19 <Viking-Ice> on top on base
18:09:56 <nirik> mattdm: for the plan for new products/adding products/what secondary products are... then existing spins people could use that process? or are we saying spins != product?
18:10:14 <jreznik> Viking-Ice: but first these sub-communities has to come with product and product has to be somehow approved as fedora product - that's what we are talking about right now
18:10:28 <Viking-Ice> jreznik, spins are existing products
18:10:43 <Viking-Ice> not in the next wg's effort sense but in community sense
18:10:46 <mattdm> nirik we were kind of informally overloading the word spin for different varients of the cloud image
18:11:05 <pjones> jreznik: they're existing /things/ yes, but we're choosing to say "product" means something specific.
18:11:20 <nirik> pjones: +1
18:11:21 <mattdm> I think it makes sense to move the existing spins to being "secondary products"
18:11:24 <jreznik> two of existing spins became products already
18:11:39 <jreznik> mattdm: yep
18:11:40 <Viking-Ice> secondary products <sigh>
18:12:00 <mmaslano> #action mattdm will create proposal for spins/secondary products
18:12:04 <Viking-Ice> let's continue with discrimination shall we
18:12:06 <mattdm> we have "secondary architectures" and it's very successful and also clear what they mean
18:12:08 <jreznik> Viking-Ice: with a way how to promote these products to primary, it would be actually step forward
18:12:08 <abadger1999> mattdm: tentative +1 to that...  similar to ssecondary arches... but I think a lot depends on the implementation.
18:12:18 <t8m> jreznik, +1
18:12:22 <nirik> yeah. but I think its a good place to start...
18:12:25 <abadger1999> <nod>
18:12:35 <Viking-Ice> jreznik, having to promote anything from c or b to a is a mistake
18:13:11 <mmaslano> mattdm: do you need more input for your draft?
18:13:21 <mitr> Viking-Ice: It isn't.  The Linux kernel is clearly not equal to the toy kernel I wrote years ago, and they shouldn't be treated equally.
18:13:22 * jreznik always try to call it multiple products effort than 3 products effort
18:14:15 <mattdm> three is a magic number. :)
18:14:47 <abadger1999> mattdm: which makes it dangerous if you want to leave room for expansion ;-)
18:14:48 <notting> mattdm: and i'm just a bill.
18:14:50 <jreznik> mmaslano: well, the first thing would be to create wiki for this process, then interested people could join, I'd invite spins sig guys, other spins guys to the process... I can help mattdm with that
18:15:00 <sgallagh> I wonder if we had originally called these "Featured Spins", if this would have resulted in fewer flamewars. Probably not.
18:15:05 <mattdm> notting +1
18:15:11 <mattdm> also jreznik :)
18:15:13 <Viking-Ice> mitr, Fedora is an open community last time I checked and whether you come here to maintain an application or application stack or want to participate contribute your work in sub-community which outputs something call it product,spin or whatever, you should get equal presentation
18:15:21 <Viking-Ice> after all these are community contributed times
18:15:44 <mmaslano> #action jreznik will help mattdm wiht proposal (invite interested people...)
18:15:45 <jreznik> Viking-Ice: but that's something that's not true now!
18:15:52 <Viking-Ice> jreznik, right
18:16:11 <Viking-Ice> jreznik, and cannot be change due the mindset of the people steering the project
18:16:15 <nirik> there's no way everything can always be equal. They aren't, and resources are finite.
18:16:20 <sgallagh> Viking-Ice: I think that the quality of your work should be the thing that elevates you, not some external categorization.
18:16:21 <nirik> in any case this is offtopic.
18:16:23 <jreznik> Viking-Ice: so let's change it and make sure these sub-communities could be that featured products if they show interest, quality...
18:16:35 <sgallagh> There are plenty of people who are very well-respected for their work on secondary architectures
18:16:41 <Viking-Ice> jreznik, the wg's and the next effort does not do that
18:16:42 <jreznik> Viking-Ice: I hope it can be changed, if not, we're really doomed
18:16:43 <Viking-Ice> far from it
18:16:51 <notting> sgallagh: i think 'featured spins' changes the meaning of what the plan is - it pushes the "product" at hand back to just being the repository itself, which the idea of the rings/products was (in theory) moving away from
18:17:07 <Viking-Ice> jreznik, if the root is rotten the tree wont grow
18:17:10 <sgallagh> notting: Yeah, I was just musing. I don't really think it was the right choice.
18:18:41 <mattdm> I don't think Fedora has rotten roots. I think this approach is a great one for growing the whole project and the community as we go forward.
18:18:53 <mmaslano> no new ideas, so let's move to another topic
18:18:55 <mmaslano> #topic #1218 Before this starts causing us in QA serious headache there should be manatory description on copr repos
18:19:00 <mmaslano> .fesco 1218
18:19:01 <zodbot> mmaslano: #1218 (Before this starts causing us in QA serious headache there should be manatory description on copr repos) – FESCo - https://fedorahosted.org/fesco/ticket/1218
18:20:01 <sgallagh> As noted in the ticket, I'm in favor of asking the COPR developers to amend the %{dist} tag they use to make it highly visible when using a non-Fedora package
18:20:16 <sgallagh> I'm also in favor of changing the default empty description message
18:20:20 <nirik> I'm not, but will bow to the will of others.
18:20:51 <abadger1999> sgallagh: We've always said that dist tag is not meant to be used that way.
18:20:51 <Viking-Ice> mattdm, it has rotten roots the thought of self and employer dominates those steering the ship hence we get no where. You have to put fedora and it's community well being first in your heart before yourself or your employer
18:21:01 <mmaslano> I don't like dist, I would be fine with description message
18:21:06 <abadger1999> sgallagh: ie: dist means what the package is built for, not where it comes from.
18:21:12 <mitr> sgallagh: +1 to dist tag; re: description, like that but perhaps we don't need to vote on such details
18:21:12 <t8m> sgallagh, +1 to both changing the dist tag and default description
18:21:15 <notting> sgallagh: amend in adding 'copr' somewhere? the prefix needs to remain for obvious reasons
18:21:16 <abadger1999> sgallagh: So I would be -1 to that suggestoin.
18:21:20 <pjones> sgallagh: I'm not so happy with that - %{dist} changing means rpmvercmp sort order changes.  So then the question is: for which overlayed repos are which new dists valid?
18:21:31 <pjones> sgallagh: and now you've got a giant matrix you're having to work on constantly.
18:21:33 <sgallagh> notting: Yes, I suggested .fc20copr as an example
18:22:04 <sgallagh> pjones: I meant a single universal appended value, not a different one per repo
18:22:16 <nirik> it only slightly helps the issue in some cases.
18:22:26 <mmaslano> as abadger1999 said, we never used dist tags to make difference between repos
18:22:26 <mitr> Given that (rpm -q $packagename) is pretty much the best we can hope for in a bug report, I can't see a reasonable alternative to changing the dist tag
18:23:00 <drago01> mmaslano: "we have not done so in the past" does not mean that we can't do it
18:23:04 <abadger1999> I believe for the RHEL/EPEL split RHT eventually created a tool that checked package signatures to do that.
18:23:12 <t8m> mitr, +1
18:23:14 <nirik> yes, keychecker
18:23:31 <mattdm> Viking-Ice All I can say is that I am quite certain that that is actually the case, and that I know that everyone involved has their heart in the right place and wants the best for the project. (I know that's off topic in the conversation at hand; we can take it up later some time.)
18:23:40 <nirik> but really it's always going to be a dialog between reporters and maintainers/qa to find out what they have from where.
18:24:01 <abadger1999> nirik: +1
18:24:17 <t8m> abadger1999, msuchy suggested changing vendor tag
18:24:40 <drago01> nirik: having to ask the reporter "did you use a copr" version every time is going to be annyoing
18:24:43 <mattdm> changing the vendor tag occurred to me too but it's not readily visible
18:24:47 <sgallagh> t8m: That doesn't really help, since the Vendor tag isn't visible
18:24:57 <mitr> nirik: That _shouldn't_ be a a dialog at all; the bug reporting mechanism should include all of that info automatically.  (No, we aren't there and can't get there; but using the existence of a dialog to accept making the dialog more complex and likely to miss something doesn't work.)
18:25:05 <t8m> sgallagh, better rpm -qi than additional tool such as keychecker
18:25:09 <nirik> drago01: along with: did you install from source, did you use rpmfind.net, did you use pip, did you use gem install, do you have one in /opt...
18:25:20 <sgallagh> t8m: Better still is just 'rpm -q' :)
18:25:23 <drago01> nirik: way less comon
18:25:25 <t8m> sgallagh, sure
18:25:30 <nirik> mitr: if you have such a tool, make it check key
18:25:31 <mattdm> um. I guess we could do %_rpmfilename   %%{NAME}-%%{VERSION}-%%{RELEASE}.COPRS.%%{ARCH}.rpm
18:25:38 <abadger1999> t8m: I don't have the same objection to vendor as I do to disttag... But I do remember that this discussion in other venues lead to the conclusion that gpg keys were the only method that made sense.
18:26:01 <mmaslano> to quote msuchy: Changing the dist tag is not a great solution, because it means the copr owner must adjust all specs that use dist tag in conditionals.
18:26:03 <pjones> mattdm: that won't help
18:26:06 <sgallagh> mattdm: That's functionally identical to changing the DIST tag
18:26:13 <mattdm> pjones i guess not with rpm -q
18:26:15 <nirik> drago01: incufficent data. I have had 0 reports on any of my packages so far that turned out to be from a copr. ;)
18:26:16 <pjones> mattdm: as mitr so unfortunately points out, it needs to show up in rpm -q
18:26:23 <sgallagh> mmaslano: Read further. We determined there are exactly 9 packages doing that
18:26:24 <pjones> sgallagh: it ain't.
18:26:39 <abadger1999> drago01: I've definitely closed my share of bug reports due to those reasons.
18:26:40 <mattdm> we could change the default output of rpm -q
18:26:42 * mattdm ducks
18:26:43 <sgallagh> pjones: Ok, "nearly identical"
18:26:49 <mitr> pjones: that, or mandate filing bugs through abrt only <runs/>
18:26:52 * mattdm notes all the scripts that broke last time we did that.
18:26:53 <pjones> that's a nice way of saying "not" ;)
18:27:03 <nirik> drago01: but I have had many the other things... oh, I forgot I installed from source, Oh, I got this from pkgs.net or rpmfind... etc
18:27:07 <Viking-Ice> mattdm, I'm quite certain it's not for example like continual checking on rhel and epel in spec files
18:27:14 <t8m> sgallagh, I am +1 to changing dist tag but if it doesn't pass then vendor might be acceptable
18:27:31 <sgallagh> t8m: Yeah, I'm pretty much in the same boat
18:27:36 <pjones> mattdm: that won't help either, because we'll have some tool like abrt that's doing the /right/ thing and querying the database and grabbing the info directly, and it won't know to use the new format.
18:27:36 <nirik> so, do we have votes for any action on dist? or is anyone wanting more info?
18:27:48 <drago01> nirik: ok how about we add a field to the generic bugzilla questions like "version, how to reproduce etc"
18:27:56 <pjones> sadly I think sgallagh might be right and release is the right place :/
18:27:57 <mattdm> sgallagh wait are you saying that only 9 packages are conditional on dist right now?
18:27:59 <nirik> drago01: sure, but many people just delete that text.
18:28:01 <pjones> (I don't have to like it...)
18:28:04 <nirik> 'foobar crashes'
18:28:07 <sgallagh> Proposal: COPR repos should amend %{dist} to include "copr" after the distribution version.
18:28:10 <t8m> abadger1999, the gpg key method solves the problem of 'rpm built at 3rd party which copies all the tags as is from fedora'
18:28:13 <nirik> sgallagh: -1
18:28:15 <sgallagh> mattdm: yes, I said exactly that.
18:28:20 <mattdm> okay then.
18:28:22 <pjones> sgallagh: make it .copr and I'll be closer to agreeing.
18:28:26 <mattdm> in that case, I am +1 to changing dist.
18:28:31 <mattdm> exact proposal tbd
18:28:33 <sgallagh> pjones: .copr is fine
18:28:50 <t8m> sgallagh, +1
18:29:00 <abadger1999> sgallagh: -1
18:29:07 <sgallagh> Proposal: COPR repos should amend %{dist} to include ".copr" after the distribution version. Example: pkgname-1.0.0-1.fc20.copr.x86_64
18:29:10 <mitr> sgallagh: +1
18:29:25 <mattdm> sgallagh +1
18:29:26 <mmaslano> -1
18:29:27 <notting> so, 'always newer'?
18:29:37 <drago01> do we have to chnage %dist itself or can't we just tell maintainers to append .copr to the version (after dist)
18:29:39 <notting> (than the corresponding fedora build)
18:29:56 <mitr> (Actually not sure about the ".", will it confuse some stupid heuristics looking for the dist tag?)
18:29:58 <sgallagh> drago01: I figured asking COPR to do that would lead to fewer mistakes.
18:29:59 <mattdm> notting - I think that's actually positive side effect
18:30:14 <drago01> sgallagh: but does break conditionals
18:30:15 <mattdm> drago01 I think we'd have to have someone enforcing that for it to be useful
18:30:17 <notting> mitr: tags are '.'-delimited, and then compared in chunks
18:30:17 <pjones> sgallagh: the . is important - it'll cause rpm to separate it into a separate alphanumeric segment for comparison
18:30:31 <t8m> sgallagh, +1 againt
18:30:34 <abadger1999> drago01: Right :-(
18:30:36 <sgallagh> drago01: I can live with possibly breaking nine packages
18:30:41 <t8m> again that is
18:30:47 <pjones> mitr: should have aimed that at you I guess
18:30:57 <notting> so
18:31:00 <notting> if you have:
18:31:08 <mattdm> i think the gpg idea is interesting but doens't address the basic problem of easy visibility when filing bugs
18:31:09 <mitr> notting, pjones: I was thinking about "dist_tag = release[last_index_of_dot + 1:]" and the like
18:31:13 <notting> Requires: foo > 1.0-1.%{release}
18:31:14 <t8m> mitr, it should not confuse anything that is not already extremely broken
18:31:17 <drago01> mattdm: don't know the code but doesn't sound like a hard thing to do
18:31:22 <notting> 1.0-1.fc20.copr *satisfies* that
18:31:30 <pjones> mitr: yeah, I don't know how to avoid that
18:31:31 <notting> so, -1 to the change
18:31:37 <pjones> notting: indeed.
18:31:40 <mattdm> drago01 which code, though.
18:31:52 <pjones> yeah, that's awful.
18:32:00 <mmaslano> more votes?
18:32:10 <mattdm> notting meh. do people really do that? => ftw
18:32:11 <nirik> are we at -4+4?
18:32:12 <sgallagh> notting: Why is that an issue?
18:32:22 <pjones> mmaslano: it would be nice if you would let the discussion happen before trying to tally the votes.
18:32:36 <sgallagh> Yeah, I'm withholding my vote for that reason :)
18:32:37 <pjones> anyway, -1
18:32:54 <pjones> given notting's point it's not going to work effectively.
18:33:02 <sgallagh> notting: Presumably someone who is using 1.0-1.fc20.copr is doing so because it's a compatible replacement
18:33:04 <notting> sgallagh: if you're requiring a newer build than X-Y, then an unchanged copr rebuild of X-Y now satisfies that requirement.
18:33:16 <notting> sgallagh: as opposed to a straight rebuild of 1.0-1.fc20?
18:33:18 <sgallagh> ahh, I see what you mean
18:33:22 <pjones> sgallagh: right, the problem is that it needs to be compatible with a /newer/ version
18:33:44 <sgallagh> I'd like to know how many people do > rather than >= for comparisons like that.
18:33:46 <t8m> This is already broken condition
18:33:48 <notting> (admittedly, versioned requires/provides/etc. when coprs are in the mix is a giant minefield
18:33:51 <sgallagh> I still think it's likely a broken situation
18:33:56 <t8m> sgallagh, +1
18:34:25 <mitr> notting: I'd expect >= to be the only reasonable thing to do - our mass rebuilds increase %release in a way that is unpredictable in advance already.
18:34:29 <sgallagh> I know I at least always use >= to ensure I'm getting a compatible version
18:34:30 <Viking-Ice> notting, right 1.0-1.fc20.copr *satisfies* that ( reporters run rpm -q <package> and copy paste the output from that to the report )
18:34:45 <t8m> you should always require some known good release and not anything that is newer than bad release
18:34:58 <sgallagh> t8m: Exactly
18:35:02 <pjones> sgallagh: "Obsoletes: foo <= 1.0-1.fc20" is also hit
18:35:07 <mattdm> maybe we should ask for something like that to be added to the packaging guidelines?
18:35:22 <pjones> sgallagh: and the worse way - suddenly the new package doesn't obsolete a rebuild of the old one
18:35:35 <drago01> random question how does ubuntu handle that with ppas?
18:35:40 <drago01> do they just ignore it?
18:35:41 <mattdm> drago01 terribly!
18:35:51 <Viking-Ice> components in copr repository's always have to carry their own spec files right?
18:35:57 <drago01> mattdm: which means?
18:36:05 <sgallagh> drago01: They just ignore it, mainly.
18:36:09 <drago01> ...ok
18:36:13 <sgallagh> If you're using a PPA, you're taking your life in your hands
18:36:28 <t8m> pjones, Packaging guidelines suggest using obsoletes < $obsEVR
18:36:36 <sgallagh> I'm personally in the camp that we should try to trust people not to do stupid things in COPR
18:36:38 <t8m> pjones, so again <= should not be used with obsoletes
18:36:46 <sgallagh> And remind everyone that if stupid things happen, they're not our responsibility.
18:37:03 <pjones> t8m: ... that has the exact same problem, just offset by one.
18:37:24 <t8m> pjones, no, the $obsEVR should be the release you provide
18:37:55 <pjones> but also you're saying "suggest", which I'm taking to mean "do not require"?
18:38:09 <mattdm> pjones but this will happen with any incremented release in coprs, regardless of dist, right?
18:38:22 <jwb> i think you are all just agreeing that 3rd party repos providing things that match conditionals in the fedora repos is hard and bad and you aren't going to sovle it here today.
18:38:30 <sgallagh> mattdm: Yes, so this isn't addressing the issue at all
18:38:45 <jwb> and maybe you can just move on without fixating on the actual problem you were supposed to solve?
18:38:55 <jwb> er, s/without/by
18:38:58 <mmaslano> jwb: :)
18:38:59 <abadger1999> Quick search brought me this thread: http://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html
18:39:03 <mattdm> I am still for the dist tag. I think it makes life easier for maintainers
18:39:11 <pjones> fenchurch:~/devel/rpm.org/rpm$ rpm -qa --qf "[%{Obsoletename} %{obsoleteflags} %{obsoletenevrs}\n]" | grep '<=' | wc -l
18:39:12 <pjones> 419
18:39:14 <pjones> so yeah, that's not great.
18:39:32 <Viking-Ice> jwb, spec files in Fedora official repository should be crystal clean without any external warts downstream 3party repo's copr scl and what not
18:39:48 <drago01> Viking-Ice: on paper
18:39:54 <Viking-Ice> that how you solve that problem
18:39:57 <Viking-Ice> drago01, in reality
18:39:58 <abadger1999> There's a lot of reasons people mention that I'd forgotten about why disttag wouldn't be a good idea.. I'd have to sift through that thread to remember all the arguments and what was addressed by later refinements.
18:40:20 <Viking-Ice> drago01, but currently it is not
18:40:27 <sgallagh> As mattdm pointed out, this is still moot any time a COPR bumps release anyway, can we get past the comparison discussion?
18:40:27 <drago01> Viking-Ice: who does review every change? I don't ;)
18:41:12 <Viking-Ice> drago01, coming up with script that parses spec files and greps out of it conditionals is no rocket science
18:41:17 <t8m> abadger1999, but that discussion was for epel which is completely different beast than copr
18:41:22 <mitr> Viking-Ice: but it hasn't happened
18:41:25 <mattdm> abadger1999 there was a whole thing about disttags vs. repotags that once occupied a portion of my brain which is now apparently busy with other things....
18:41:30 <abadger1999> t8m: Not in this regard.
18:41:30 <notting> did the vote pass, fail, or are people still considering?
18:41:37 <Viking-Ice> drago01, and then we simply block the build process for that component ;)
18:41:47 <sgallagh> notting: Last count was +4/-4 I think
18:41:56 <mattdm> sgallagh are we waiting on you?
18:41:58 <sgallagh> But we should probably just call a re-vote at this point.
18:42:03 <mmaslano> probably
18:42:03 <nirik> perhaps we could revote?
18:42:05 <abadger1999> t8m: In this regard they're very similar concerns.  coprs are an addon repository to fedora;  epel is an addon repository to rhel/centos
18:42:08 <sgallagh> mattdm: Not sure if mmaslano was counting me as assumed +1
18:42:21 <mmaslano> for the record -1
18:42:22 <sgallagh> Proposal: COPR repos should amend %{dist} to include ".copr" after the distribution version. Example: pkgname-1.0.0-1.fc20.copr.x86_64
18:42:27 <t8m> still +1
18:42:31 <abadger1999> how disttags interact between addon repositories and the distros they add to is the crux of both discussions.
18:42:31 <mattdm> +1
18:42:33 <sgallagh> +1
18:42:34 <abadger1999> -1
18:42:36 * pjones -1
18:42:57 <nirik> -1
18:43:04 <mitr> sgallagh: +1
18:43:05 <drago01> Viking-Ice: if anything that would make more sense as a pre commit hook (to rpevent the commit) and not at build time
18:43:21 <notting> sgallagh: -1
18:43:28 <sgallagh> +4/-5, then
18:43:45 <mattdm> okay. so, alternate ideas?
18:43:47 <drago01> Proposal: Do nothing
18:43:53 <sgallagh> t8m suggested Vendor
18:44:06 <sgallagh> So at least rpm -qi would be helpful.
18:44:11 <mmaslano> #agreed proposal about adding dist tag didn't pass (+4,-5,0)
18:44:18 <nirik> drago01: well, I am in favor of changing the default description if not filled in.
18:44:18 <sgallagh> Even if it's not likely to end up in a BZ
18:44:21 <nirik> but otherwise yeah.
18:44:22 <mattdm> I think setting the vendor is a Good Idea™ but doesn't really address the issue
18:44:32 <t8m> #proposal Change the Vendor tag so it is clear that the package comes from COPR
18:44:33 <mattdm> (the bz issue)
18:44:33 <nirik> neither does dist. ;)
18:44:35 <drago01> nirik: I am talking about the spec file
18:44:40 <pjones> mattdm: likewise
18:44:48 <nirik> sure, change vendor. Dont' care. ;)
18:44:51 <mattdm> so I guess +1 to the proposal
18:44:53 <sgallagh> mattdm: It does make it possible to write a trivial tool to detect whether a user has COPR packages on the system (and which ones)
18:44:56 <sgallagh> So there's that
18:45:07 <drago01> nirik: but yeah empty desc shouldn't be allowed (it does not make sense and takes a few minutes at most to fill in)
18:45:11 <nirik> sgallagh: 'keychecker | grep notsigned'
18:45:13 <abadger1999> nirik: +1 to changing the description.
18:45:31 <sgallagh> nirik: Got a proposed description?
18:45:33 <abadger1999> +0.6 to Vendor (go ahead and round up ;-)
18:45:43 <nirik> from the ticket. looking.
18:45:50 <mmaslano> abadger1999: +1.4
18:46:07 <mattdm> nirik  lack of gpg  could be any number of other things too though.
18:46:17 <nirik> "Description not filled in by author. Very likely personal repo for testing purpose, which you should not use."
18:46:24 <drago01> ideally copr packages should be signed
18:46:25 <drago01> but wll
18:46:28 <drago01> *well
18:46:33 <notting> t8m: +1, default to "COPR: <account name>"?
18:46:34 <mattdm> Do we want "Vendor: Fedora Project COPRS" or should it be more specific?
18:46:37 <mitr> t8m: I'm not opposed but I can't really see that it gives us anything over the signature key ID we already have
18:46:37 <notting> or smething like that
18:46:39 <nirik> mattdm: sure, all of which should (except rawhide) mean you shouldn't report it as a fedora bug. ;)
18:46:52 <t8m> notting, OK, why not
18:47:11 <Viking-Ice> That description field is not enough so...
18:47:13 <notting> (that probably implies code in coprs itself)
18:47:30 <t8m> mitr, simple rpm -qi | grep Vendor ?
18:47:31 <mattdm> proposal "Vendor: Fedora Project COPRs / coprname"
18:47:34 <sgallagh> mattdm: Vendor: Fedora Project COPR <coprname>
18:47:38 <mattdm> hah
18:47:40 <mattdm> yeah that
18:47:48 <mmaslano> sgallagh: +1
18:47:58 <t8m> nice bikeshedding in addition to that? :)
18:48:03 <mitr> Proposal: let msuchy find something reasonable, and let's move on?
18:48:08 <t8m> mitr, +1
18:48:12 <nirik> mitr: +1
18:48:19 <sgallagh> mitr: a reasonable vendor tag?
18:48:21 <abadger1999> mitr: +1
18:48:21 <mattdm> mitr important question is whether it's generic for all coprs or per copr
18:48:25 <sgallagh> (for clarity)
18:48:30 <mattdm> agree to not bikeshed on specifics :)
18:48:35 <mitr> sgallagh: vendor tag / description / whatever
18:48:43 <pjones> sgallagh: +1
18:48:44 <jwb> you realize this is still going to require the fedora component maintainer to figure out something is wonky and then ask for that info, right?
18:48:51 <sgallagh> I'd prefer it to indicate which COPR just to make life easier on the consumers, but I'm okay either way.
18:48:58 <nirik> jwb: just like anything else, yep.
18:49:02 <Viking-Ice> jwb, preciesly
18:49:08 <t8m> jwb, yeah, do you have an idea how to overcome this issue?
18:49:09 <pjones> jwb: yeah, we'd noted that above - we just don't have a good answer to solve it
18:49:30 <sgallagh> We're trying to reduce the effort needed to discover that info.
18:49:35 <Viking-Ice> t8m, the best proposal to do that was the dist tag
18:49:40 <t8m> jwb, except for dropping the copr concept altogether
18:49:53 <t8m> Viking-Ice, unfortunately did not pass - as you could see I was +1
18:50:00 <jwb> sgallagh, no... you're just putting an actual needle in the haystack
18:50:08 <mitr> btw (yum list $pkgname) already gives you the repo (... if it is installed via yum)
18:50:15 <jwb> anyway, i missed that you already noted this so i'm good
18:50:20 <mattdm> jwb open to other suggestions here if you've got 'em
18:50:22 <Viking-Ice> t8m, since the reporters know how to put a version number in bug reports triager or maintainers spot corp closed wontfix
18:50:36 <Viking-Ice> no ping pong back and fourth needed
18:50:42 <jwb> mattdm, nope.  just wanted to make sure people were clear
18:50:43 <nirik> proposal: interested parties work with copr maintainer for vendor tag and description changes out of band
18:50:53 <mattdm> +1 nirik
18:50:54 <t8m> nirik, +1
18:50:55 <mmaslano> nirik: I like this proposal even better
18:50:59 <mmaslano> +1
18:51:12 <sgallagh> nirik: works for me. I volunteer.
18:51:16 <mitr> nirik: +1
18:51:25 <notting> nirik: +1
18:51:26 <nirik> sgallagh: great.
18:51:26 <mmaslano> but the previous passed by +5
18:51:47 <t8m> mmaslano, I think later vote overrides :) as it is more general
18:51:47 <sgallagh> mmaslano: What did?
18:51:54 <mmaslano> t8m: yeah
18:52:01 <pjones> nirik: seems backwards
18:52:05 <Viking-Ice> you still do realize have packages more descriptive wont solve the underlying problem right?
18:52:25 <pjones> nirik: or maybe I'm misreading you
18:52:26 <sgallagh> Viking-Ice: Avoiding the back-and-forth?
18:52:32 <Viking-Ice> sgallagh, right
18:52:33 <mmaslano> #agreed interested parties work with copr maintainer for vendor tag and description changes out of band (+5,-0,0)
18:52:52 <mattdm> Viking-Ice given that the dist tag approach didn't pass, do you have an alternate suggestion?
18:52:53 <nirik> pjones: backwards?
18:52:55 <mmaslano> obviously we won't solve it right now. Could we postpone it for next meeting?
18:52:59 <sgallagh> Viking-Ice: Yes, but since a majority of FESCo voted down the %{dist} proposal, we need to do something at least.
18:53:04 <pjones> nirik: I think I was misreading
18:53:08 <Viking-Ice> sgallagh, the whole purpose of this ticket in the first place is to reduce the added time copr brings for triagers and maintainers
18:53:23 <nirik> pjones: basically I don't think this is a fesco thing... copr maintainer is happy to change those 2 things, so people who care should work with him to word them and done
18:53:25 <mitr> Viking-Ice: "it's only a problem if you have a solution"
18:53:26 <sgallagh> Viking-Ice: Yeah, I know. I agree with you.
18:53:27 <pjones> hrm.
18:53:37 <pjones> Actually %{dist} could work /in conjunction with a yum change/
18:54:08 <jreznik> guys, how ubuntu/opensuse solves this issue (if they solve it at all?) anybody took look? /me is loging to his build.opensuse account
18:54:08 <pjones> which is to say we'd need to exclude people using coprs from ever getting a non-coprs version of a package in that copr into their transaction set.
18:54:11 <pjones> it's pretty ugly.
18:54:26 <pjones> jreznik: hey, so you've cought up with the conversation 20 minutes ago!
18:54:32 <mattdm> pjones yum repopriority plugin?
18:54:39 <mattdm> jreznik they don't.
18:54:44 <pjones> mattdm: but you want exclusion, not priority
18:54:46 <mattdm> they just punt
18:54:53 <nirik> I really don't think this is that big a deal... but by all means keep discussing.
18:55:01 <mmaslano> nirik: I agree
18:55:02 <notting> pjones: would have to check, think that's a plugin already
18:55:17 <mattdm> pjones I *think* maybe one of the repo pinning plugins handles that but it's been awhile
18:55:20 <pjones> notting: I mean, I guess you could just manually manage excludes: on a per-repo basis
18:55:47 <pjones> so really what we'd want is /automatically/ doing that when you install a package from a copr and undoing it if that package is removed.
18:56:06 <pjones> I'm going to stick with "pretty ugly" in my description of that idea, though.
18:56:15 <sgallagh> I kind of suspect that we could just punt on that part of things.
18:56:19 <nirik> and then we should modify all the repos.fedorapeople.org repos... and then ping rpmfind.net and....
18:56:28 <pjones> nirik: right ;)
18:56:34 <sgallagh> If someone installs from COPR, we should assume they know roughly what they are doing
18:56:47 <sgallagh> All we need to concern ourselves with is ignoring those packages in bug reports.
18:57:09 <nirik> if you suppose they know what they are doing, they would know not to report a fedora bug on that package. :)
18:57:22 <sgallagh> nirik: People make mistakes.
18:57:33 <mattdm> and there's the abrt problem.
18:57:36 <sgallagh> I occasionally forget when I have a development package on my system and it breaks something
18:57:46 <mattdm> (which vendor or gpg id checking can solve)
18:57:53 * abadger1999 notes that a few meetings ago someone wanted to reinstate the cloture rule.... ;-)
18:58:00 <nirik> mattdm: abrt is not a factor
18:58:11 <nirik> abadger1999: yeah, at the time I thought that was silly. ;)
18:58:23 <sgallagh> "cloture rule"?
18:58:35 <t8m> can we move on?
18:58:37 <mattdm> do we want to continue discussing this right now, or move to other business?
18:58:43 <sgallagh> Let's move on
18:58:47 <abadger1999> sgallagh: 15 minutes on a topic requires a vote to continue.
18:59:04 <nirik> we have been on this topic 45min or so
18:59:06 <sgallagh> abadger1999: Didn't know it by that name, but I'm the one who brought it up (and is now quite guilty of ignoring it)
18:59:08 <mattdm> I suggest we move on and if anyone has any other suggestions or ideas that might make %dist more appealing to put them in the ticket
18:59:29 <notting> abadger1999: we reject all guidelines written in clojure?
18:59:50 <mmaslano> #topic 1217 What is critical in Fedora?
18:59:52 * pjones agrees, move on
18:59:54 <mmaslano> .fesco 1217
18:59:57 <zodbot> mmaslano: #1217 (What is critical in Fedora?) – FESCo - https://fedorahosted.org/fesco/ticket/1217
19:00:02 <mmaslano> sounds as another good one
19:00:03 <abadger1999> notting: hey, that's a pretty sane idea ;-)
19:00:20 <nirik> I'm afraid this ticket is a bit too generic for me...
19:00:40 <notting> i mean, as a direct application of the title, the critical-path could be considered critical in fedora
19:01:13 <notting> in terms of protected packages, i'd expect different defaults in different products
19:01:46 <mattdm> I think the basic mechanism as currently implemented by yum is quite good
19:01:54 <sgallagh> Proposal: Punt on this and let the products determine the appropriate mechanism.
19:01:55 <t8m> mattdm, +1
19:02:00 <t8m> sgallagh, +1
19:02:03 <mattdm> and I would like to see it in dnf. but I don't think FESCo should mandate it.
19:02:06 <mmaslano> sgallagh: +1
19:02:14 <mitr> sgallagh: +1
19:02:22 <pjones> sgallagh: +1
19:02:23 <notting> sgallagh: +1 to that
19:02:26 <mattdm> sgallagh +1
19:02:29 <nirik> sgallagh: sure. +1 I'd prefer for concrete cases if someone wants overriding existing behavior
19:02:49 <mitr> sgallagh: (I might also add "yum/dnf maintainers", but products owning this makes a lot of sense)
19:03:16 <abadger1999> sgallagh: +1
19:03:22 <jwb> if it helps, from a kernel maintainer point of view, i could care less what dnf does.
19:03:24 <mmaslano> #agreed Punt on this and let the products determine the appropriate mechanism. (+9,-0,0)
19:03:42 <sgallagh> Woo, unanimity :-P
19:03:45 <mmaslano> #topic #1220 Multiple products/WGs/teams coordination
19:03:50 <mmaslano> .fesco 1220
19:03:51 <zodbot> mmaslano: #1220 (Multiple products/WGs/teams coordination) – FESCo - https://fedorahosted.org/fesco/ticket/1220
19:04:20 <sgallagh> I can only speak for myself, but I've been trying to insinuate myself into most of the other WG meetings so I keep up with them.
19:04:24 <mmaslano> mattdm: great, you will solve it ;-)
19:04:36 <sgallagh> I've been a little lax in my participation with Env/Stacks and Workstation lately, I'll admit.
19:04:40 <mattdm> as noted in the ticket, at least part of the problem here is that i need to step up my game. :)
19:05:01 <mattdm> I've been following pretty much all of the things but not writing anything outside of cloud or talking enough.
19:05:02 <abadger1999> I'm not sure if status reports are good or not yet but the fesco liasons are supposed to be bringing up in fesco meetings things that would be relevant to fesco/other groups.
19:05:26 <mattdm> Yeah -- I think probably want to start having liason reports as part of the fesco meeting agenda
19:05:26 <jwb> Workstation PRD is out for vote
19:05:31 <mattdm> maybe every other week
19:05:31 <jwb> <end of status>
19:05:41 <abadger1999> so at the least, there should be reports and discussion of things that require coordination.
19:05:45 <mattdm> and yeah -- it needn't be long.
19:05:51 <nirik> I think there will be more info flowing around when we get down to more concrete stuff.
19:06:01 <sgallagh> Server PRD is out for a vote and is +6 with 3 members' votes outstanding.
19:06:18 <mattdm> Cloud PRD is still work in progress but very much better than last week
19:06:21 <mitr> nirik: There was already info to flow, but the default state of the universe is that it doesn't.
19:06:27 <mattdm> and we had some good discussion with server wg
19:06:32 <mmaslano> Env and Stack PRD will be hopefully ready in end of the week
19:06:56 <nirik> I'm quite interested to see what the actual implementation plans will look like. ;)
19:07:05 <jreznik> just one note - it's not only about FESCO <-> WG communication but there are more groups affected...
19:07:06 <mattdm> Also, Sunday of DevConf is Fedora-centered
19:07:25 <nirik> jreznik: right.
19:07:26 <mattdm> jreznik absolutely. qa, releng, web, marketing....
19:07:46 <jreznik> mattdm: it was a good opportunity to bring more people to devconf, not sure if the last time call for participation would work
19:07:51 <jreznik> but we can try to market it
19:08:03 * jreznik will blog tomorrow and spam internets :D
19:08:13 <nirik> although speaking personally from a infra/rel-eng angle... implementation plans and proposals are going to be much more useful than prd's. :)
19:08:25 <abadger1999> jreznik: Correct.  But I think the implicit plan was that WG communicate in fesco and fesco is responsible for making sure that other groups are brought in as needed.
19:08:34 <mattdm> nirik yeah. so we should be getting to that stage RSN. for realz.
19:08:49 <nirik> yep
19:09:34 <mattdm> anything more in specific we can do right now?
19:09:45 <sgallagh> jreznik: Is there available budget to try to coax WG membership to Devconf?
19:09:58 <sgallagh> Comped rooms or the like?
19:10:13 <jreznik> as I said - I'd like to help as it's my job that Fedora would not break apart - I think there's agreement we should communicate more - let's think about it more in the ticket and come with real plans, not my scratch ideas
19:10:24 <mattdm> sgallagh I think we have all of the WG fesco liasons at least.
19:10:32 * sgallagh nods
19:10:36 <mattdm> jreznik +1
19:11:23 <jreznik> sgallagh: budget - that's that world you should never say but let's try to look for some budget (and interested people to come - so please let's ask people if they want to come)
19:11:33 <mitr> devconf is kind of one-time...
19:11:50 <jreznik> but I'm worried - it's already so expensive that it would be hard to get more money
19:12:01 <mitr> proposal: Fire a "standing" FESCo ticket for WG activity reports, to be added to the ticket by liaisons every other week, and ACKed or discussed on the meeting
19:12:04 <jreznik> mitr: but to kick off things, f2f makes sense sometimes
19:12:18 <mitr> Eh,  "file" a ticket I suppose
19:12:22 <sgallagh> mitr: I realize that, but it's a near event where we'll already have a lot of the relevant people present.
19:12:28 <mmaslano> mitr: +1
19:12:31 <pjones> mitr: +1 to file or fire
19:12:35 <mattdm> mitr +1
19:12:40 <sgallagh> mitr: +1
19:12:44 <t8m> mitr, ₊
19:12:50 <t8m> mitr, +1 that is
19:13:03 <jreznik> mitr, thanks - and actually I promised Phil to start with it for Base WG for today's meeting, sorry, I'm not a good example :D
19:13:12 <notting> mitr: +1
19:14:38 <abadger1999> I might like a standing space (like open floor) for fesco liasons to bring up things that they think should be more widely disemminated.
19:14:50 <mmaslano> #agreed File a "standing" FESCo ticket for WG activity reports, to be added to the ticket by liaisons every other week, and ACKed or discussed on the meeting (+6,-0,0)
19:15:07 <abadger1999> So that there's an active element of "This is important for everyone" rather than just passive "didn't you read the weekly summary I sent?"
19:15:27 <abadger1999> (by like open floor I mean... similar to open floor)
19:15:34 <mmaslano> #action mmaslano will file a ticket for next week discussion
19:15:46 <mmaslano> abadger1999: sounds fine
19:15:54 <mitr> https://fedorahosted.org/fesco/ticket/1221 for the record
19:16:11 <mmaslano> abadger1999: I saw in Server WG there already are issues marked as needed to discuss
19:16:48 <mitr> mmaslano: They got resolved or removed.
19:17:03 <abadger1999> Proposal: Standing Agenda Item for FESCo Liasons to bring up topics that should be discussed more widely
19:17:07 <mitr> mmaslano: ... which is not to say you shouldn't know :)
19:17:08 <mmaslano> mitr: and that's good
19:17:17 <notting> mitr: jreznik2: hindsight 20/20, but would have been nice to get the idea of a devconf/fosdem f2f earlier in the planning/budgeting sessions
19:17:39 <nirik> abadger1999: sure, although the ticket could be that if we have it each week?
19:17:43 <sgallagh> notting: FWIW, I put in my Fedora.next workshop proposal the day the CFP went out
19:17:58 <abadger1999> nirik: Yeah -- but active vs passive again.
19:18:39 <abadger1999> Do all of us read all of the new comments on all of the fesco tickets every week?
19:18:40 <sgallagh> (for both conferences)
19:18:47 <nirik> abadger1999: well, meeting keyword on ticket means it comes up each meeting and we ask if anyone has things to note/discuss/report?
19:19:00 * sgallagh usually does, unless abadger1999 was the one commenting ;-)
19:19:09 <abadger1999> sgallagh: :-P
19:19:22 <notting> sgallagh: *nod*, but that's different than the idea of 'get all WG members into one place'
19:19:45 <Viking-Ice> why are you wasting time and effort getting all wg members in one place
19:20:15 <Viking-Ice> and time and effort better spend in actually seeing if the community actually supports any of this stuff
19:20:43 <Viking-Ice> but by all means spend energy <sigh>
19:20:54 * nirik shakes his head.
19:21:06 <pjones> I'm going to take that as meaning he doesn't expect an answer to that question.
19:21:10 <jwb> is there a community you're referring to that isn't already on all the lists everything is being sent to?
19:21:15 <pjones> jwb: he's gone.
19:21:25 <jwb> oh
19:21:32 <sgallagh> jwb: Viking-Ice is a community unto himself, unfortunately.
19:21:43 <sgallagh> When he uses that word, he's talking about himself only.
19:21:46 <notting> jwb: or at the conferences where the rings/products/etc were discussed, as well
19:22:00 <mmaslano> are you okay with the ticket for discussing status of WGs, or you want to do more?
19:22:03 <nirik> anyhow, I am fine with ticket and/or space in each meeting for wg's to discuss things
19:22:17 <mmaslano> mattdm: I count with WG meetup on Sunday on devconf
19:22:27 <sgallagh> I'm neutral on adding more process.
19:23:05 <mattdm> mmaslano count?
19:23:05 <abadger1999> I thikn I'd rather have the meeting item.
19:23:19 <abadger1999> rationale: the status reports will have many things that don't need to be acted upon.
19:23:23 <mmaslano> mattdm: I really should be going :)
19:23:23 <t8m> mmaslano, I'd move on and suggest anything else to be proposed in the ticket and voted upon next week
19:23:34 <mattdm> mmaslano oh yes. I kind of assumed you would be :)
19:23:40 <abadger1999> Meting item would serve to highlight things that might get lost i nthe other status report items.
19:24:32 <mattdm> i'm unclear on how this is different from the previous proposal
19:24:45 <mitr> abadger1999: We already have ways for anyone in the community to raise issues, do we specifically need one more category?
19:25:47 <abadger1999> mitr: I think so.  At least for me, I don't like to seem to be "pestering" someone else.
19:25:59 <abadger1999> But I think this coordination is important.
19:26:55 <abadger1999> So we'd do well to specifically say that we want the fesco liasons to alert us to these issues.  Allocating specific meeting time to that makes it so it doesn't feel to be pestering so much as doing something that's expected of you.
19:27:01 <mattdm> I think it can't hurt to at least try it.
19:27:03 <mattdm> so +1
19:27:12 <mattdm> if it starts getting too heavyweight we can back off :)
19:27:16 <mmaslano> ok +1
19:27:23 <abadger1999> <nod>   Willing to adjust :-)
19:27:26 <abadger1999> +1
19:27:26 <nirik> sure, +1
19:27:36 <notting> abadger1999: i would hope the idea that a 'fesco liason' raises issues with fesco would already be implied as an expected duty
19:27:44 <t8m> +1
19:28:25 <sgallagh> +0 for pretty much what notting said
19:29:19 <mattdm> (I think it's good to have on the agenda specifically because these meetings are kind of unbounded. So it's helpful to know that there is time allocated to liasoning.)
19:29:30 <mitr> 0
19:29:30 <mmaslano> #agreed fesco liasons will alert on fesco meetings about important issues (+5,-0,0)
19:29:34 <mattdm> liasing
19:29:36 <mmaslano> mattdm: so at the start?
19:29:47 <mmaslano> meetings can be very long
19:30:15 <mattdm> Sure, let's try putting it at the start. And then we'll see if we ever get to anything else. smile/sigh
19:30:16 <abadger1999> Start could be good -- especially as the meetings run late into the European night?
19:30:17 <t8m> mmaslano, definitely - we can postpone the discussion of it then to end
19:30:36 <mmaslano> what?
19:31:38 <mmaslano> I would prefer start
19:32:02 <mmaslano> so, let's move to next chairman?
19:32:16 <t8m> mmaslano, I agree, but if we have more pressing topics we can postpone the liaison discussions after them
19:32:24 <t8m> for that concrete meeting
19:32:27 <mmaslano> t8m: I would leave to chairman
19:32:34 <t8m> yep
19:32:41 <mmaslano> so chairman
19:32:46 <mmaslano> #topic Next week's chair
19:33:33 <nirik> I'll do it if no one else is wanting to
19:33:55 <mmaslano> #action nirik will chair next meeting
19:33:57 <mmaslano> nirik: thank you
19:34:03 <mmaslano> #topic Open Floor
19:34:12 <t8m> I might not be able to attend next week.
19:34:22 <sgallagh> One quick reminder: PRDs are due on Monday. Please read through them before the meeting next week.
19:34:28 <jreznik2> any move on EOL? closure should happen later this week
19:34:42 <jreznik2> or did I miss this topic? ;-)
19:34:57 <mmaslano> jreznik2: I forgot to add it into agenda um
19:35:14 <mattdm> jreznik2 I think we agreed to add the wording about mailing to an ombudsman alias/list
19:35:42 <nirik> well, thats pretty last minute for me...
19:35:44 <jreznik2> mattdm, ok, let's sort it out in ticket
19:35:53 <mattdm> and I guess to punt on further possible changes until the next cycle (although presumably not so close to the end of it.)
19:35:59 <mattdm> +1 sort it out in ticket
19:36:07 <mmaslano> yeah we did
19:36:10 <t8m> +1 to that
19:36:14 <jreznik2> yep, it's too late for big changes
19:36:38 <nirik> ie, we can slap a list together no problem, but we have no scope or buy in from others or anything, so I would personally defer this too. ;)
19:37:43 <jreznik2> nirik, good point on the other hand we would see if anyone would be interested to write ombudsman
19:38:04 <jreznik2> and in case we would see 99 % would be ranting
19:38:10 <nirik> with no clear expectations we could actually make people more mad.
19:38:23 <mitr> I can't see that a list where people volunteer to explicitly deal with EOL bugs only has much chance of attracting at least as many contributors as general bug triage that is focused on the very latest version
19:38:35 * mmaslano really need to go now
19:38:47 <mmaslano> do you want to continue without me?
19:38:47 <mattdm> mitr that is a good description of the scope, really. :)
19:38:52 <nirik> but sure, we can do figure it in ticket I guess.
19:39:01 <mattdm> let's close the meeting and figure it out in the ticket
19:39:16 <mmaslano> thanks
19:39:23 <jreznik2> thanks guys
19:39:27 <mmaslano> #endmeeting