Summary/Minutes from today's FESCo Meeting (2014-01-15)

Marcela Mašláňová mmaslano at
Thu Jan 16 06:39:56 UTC 2014

#fedora-meeting: FESCO (2014-01-15)

Meeting started by mmaslano at 18:00:34 UTC. The full logs are available

Meeting summary
* init process  (mmaslano, 18:01:02)

* 1197 Procedure for suggesting/approving different Products and/or WGs?
   (mmaslano, 18:01:58)
   * ACTION: mattdm will create proposal for spins/secondary products
     (mmaslano, 18:12:00)
   * ACTION: jreznik will help mattdm wiht proposal (invite interested
     people...)  (mmaslano, 18:15:44)

* #1218 Before this starts causing us in QA serious headache there
   should be manatory description on copr repos  (mmaslano, 18:18:55)
   * AGREED: proposal about adding dist tag didn't pass (+4,-5,0)
     (mmaslano, 18:44:11)
   * AGREED: interested parties work with copr maintainer for vendor tag
     and description changes out of band (+5,-0,0)  (mmaslano, 18:52:33)

* 1217 What is critical in Fedora?  (mmaslano, 18:59:50)
   * AGREED: Punt on this and let the products determine the appropriate
     mechanism. (+9,-0,0)  (mmaslano, 19:03:24)

* #1220 Multiple products/WGs/teams coordination  (mmaslano, 19:03:45)
   * 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)  (mmaslano, 19:14:50)
   * ACTION: mmaslano will file a ticket for next week discussion
     (mmaslano, 19:15:34)
   * LINK: for the record
     (mitr, 19:15:54)
   * AGREED: fesco liasons will alert on fesco meetings about important
     issues (+5,-0,0)  (mmaslano, 19:29:30)

* Next week's chair  (mmaslano, 19:32:46)
   * ACTION: nirik will chair next meeting  (mmaslano, 19:33:55)

* Open Floor  (mmaslano, 19:34:03)

Meeting ended at 19:39:27 UTC.

Action Items
* mattdm will create proposal for spins/secondary products
* jreznik will help mattdm wiht proposal (invite interested people...)
* mmaslano will file a ticket for next week discussion
* nirik will chair next meeting

Action Items, by person
* jreznik
   * jreznik will help mattdm wiht proposal (invite interested people...)
* mattdm
   * mattdm will create proposal for spins/secondary products
   * jreznik will help mattdm wiht proposal (invite interested people...)
* mmaslano
   * mmaslano will file a ticket for next week discussion
* nirik
   * nirik will chair next meeting
   * (none)

People Present (lines said)
* mattdm (94)
* sgallagh (84)
* mmaslano (72)
* nirik (64)
* pjones (50)
* t8m (49)
* abadger1999 (46)
* Viking-Ice (37)
* notting (35)
* mitr (33)
* drago01 (23)
* jreznik (23)
* jwb (12)
* zodbot (9)
* jreznik2 (7)
* jsmith (1)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`:

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
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 at>
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 -
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 
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 
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 
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, 
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) – 
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 
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 
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 
18:25:09 <nirik> drago01: along with: did you install from source, did 
you use, 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 
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 
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 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: 
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 < 
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:
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 -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 
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: 
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 
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 
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 
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 
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 
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 
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 
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 
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... and then ping 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 
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 -
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 
19:15:46 <mmaslano> abadger1999: sounds fine
19:15:54 <mitr> 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 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 
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, 
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 
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 
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

More information about the devel mailing list