===================================
#fedora-meeting: FESCO (2014-01-15)
===================================
Meeting started by mmaslano at 18:00:34 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-01-15/fesco.2014-01-15-18.00.log.html
.
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: https://fedorahosted.org/fesco/ticket/1221 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
* **UNASSIGNED**
* (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`: http://wiki.debian.org/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
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@xxxxxxxxxx>
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
