--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpepplemarek: https://fedoraproject.org/wiki/Extras/Schedule/NewSponsors
marekbpepple: can I add him to that page, with bugzilla links etc...?
marekas for next meeting vote
bpepplemarek: yeah, that would be fine.  Once you do that I'll send the info to the mailing list for discussion.
FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
Hi everybody; who's around?
* nirik is here.
sharkcz is here
dwmw2 just about
j-rod here
dwmw2wenchlet is sick though and I'm playing nurse... which means going to the shop imminently to find sustenance
* dgilmore kinda
nirikdwmw2: get delivery? :)
* jds2001 here
dwmw2nirik: not here.
* jwb is here
bpeppleok, I see eight of us, so we can probably get started.
* j-rod wonders... is a wenchlet akin to a wench as a piglet is to a pig?
bpeppleFirst off, I'd like to welcome sharkcz to FESCo.
* wwoods lurks
jds2001 gives a big welcome to sharkcz :)
bpepplesharkcz: you got any questions?
sharkczthanks to all :-)
sharkczbpepple: no
bpepplecool, all right let's get to business.
--- bpepple has changed the topic to: FESCo-Meeting -- Elect new FESCo chair - all
bpeppleOk, jwb & jds2001 expressed interest in being the chair?  Anyone else want to throw their hat in?
* bpepple went a little crazy with question marks.
j-rodI sort of half-heartedly threw my hat towards it, but it missed.
bpepplej-rod: ;)
j-rodand now I'm picking it up.
bpeppleok, so we've got j-rod, jwb, and jds2001 up for chair.
j-rodoh, no, I mean I'm picking it up and keeping it -- NOT throwing it in. :)
too many j's
bpepplej-rod: oh right, misread that. ;)
jwbthere are never enough j's
bpeppleok, so it's jwb and jds2001.  You both still want it?
jds2001i will yield to jwb if he wants it :)
jwbactually, i think jds2001 might bring "new blood" better than i
dwmw2mmm, blood
jwbi've been the pseudo "vice-chair" for a while now
either way works for me though
* bpepple is fine with either of you guys being chair.
jds2001does anyone have opinions on who *shouldn't* be chair?
* dwmw2 shouldn't
tibbs|hzodbot needs a .coinflip command.
* dgilmore says dwmw2 shouldnt also
jds2001dwmw2: you're appointed!
* dwmw2 promotes an attitude of violence towards jds2001
niriktibbs|h: there is one. ;)
not loaded I guess.
jds2001or not.
bpeppleI'm fine with either jds2001 or jwb.  Someone just needs to step forward. ;)
jds2001if jwb wants it to be me, i guess it's me :)
dgilmorejwb, jds2001: cat fught :)
cat fight
* jds2001 needs to get crash course in chairing FESCo, though :)
jwbjds2001, if you have the time, go for it
jds2001jwb: that's the thing, most weeks I do, some I might not.
dgilmorejds2001: by my einne meenie miny moe  your it
jds2001dgilmore: :)
bpepplejds2001: I'm still around, so I can pitch in when needed.
fedbotnirik: heads
jwbshifting the minute taking should help
bpepplejwb: agreed.
jds2001: do you want to lead the rest of the meeting? Or you want me to?
jds2001either way...
bpepplehow about I finish up today, and next week it's all you. ;)
--- jds2001 has changed the topic to: FESCo-Meeting -- New FESCo meeting time (Friday's @ ?) - all
jds2001that'd work too
dgilmoreany time friday works for me
bpepplejds2001: to late you already took control. ;)
dgilmorei think notting had the hardest time requirements
dwmw2any sensible time in Europe works for me.
on Fridays
jds2001I have a 3PM on Fridays, but that's too late for sharkcz and dwmw2 I think.
jwbi will point out that friday morning is usually better than friday evening, but that is opposite for people in .eu
dgilmoredwmw2: 2am sensible?
jwb: friday morning in the us is friday evening in .eu
bpeppleDo our usual starting time work for folks?  Just switching the day to Friday?
dwmw2dgilmore: :)
jwbdgilmore, that's what i just said
nirikthat works for me.
sharkcz2am = 20:00 here, works for me too
dwmw2bpepple: yeah, although an hour earlier would be nicer.
dgilmorejwb: sorry misread it
jwbbpepple, it would sort of work.  i have a hread life meeting at the same time, but i rarely attend it
sharkczdwmw2: +1
dwmw26pm on a Friday is a different issue to 6pm on a Wednesday... :)
bpeppledwmw2: I'm fine with moving it up one hour.
dwmw2even more so for those on the mainland, since it's 7pm for them...
nirikmoving up an hour would work ok for me too.
dgilmoresharkcz: i meant 02:00 GMT :)
sharkczdgilmore: then I am out ;-)
dgilmoresharkcz: :)
dwmw2dgilmore: see the news from olpc today?
bpeppleok, so I don't hear any objections to dwmw2's proposal.  So if no one speaks up, I say we have our meeting on Friday's at Noon(est).
dgilmoredwmw2: no i did not
jds2001sounds good.
dgilmore+1 for dwmw2's proposal
bpepplealright, if no one objects I think the last bit of business we need to decide is handling the meeting summaries.
jwbok, so what time exactly?
dwmw2jwb: 17:00 GMT
jwbworks for me
bpeppleI suggested on the mailing list we rotate the person handling the meeting summary every 2 meetings.  Anyone have a problem with that?
jds2001nope, just need to coem up with a schedule.
bpepplejds2001: how about alphabetical? (Note: I'll handle this week's)
jds2001sounds good as any to me :)
jwbalphabetical by irc nick?
* jds2001 was thinking last name, but any way works.
bpepplejwb: I was thinking last name, but truthfully I don't care.
* nirik does not care either.
jwbthe "this week's" comment threw me off
last name is fine
jds2001i.e. we'll start this next meeting.
jwbi guess i'm up next week
dgilmorejwb: :)
bpepplejwb: ;)
ok, I think that covers all the administrative stuff we needed to cover. We can probably move on.
* bpepple takes a back seat, and lets jds2001 drive.
--- jds2001 has changed the topic to: FESCo-Meeting -- Adding provenpackagers to experienced maintainer
jds2001definition -
oh well, what this is about is the "experienced maintainers" definition in who's allowed to tocuh what packages.
there's also concern about the size of the provenpackagers group.
(281 last I checked a few weeks ago)
dwmw2I don't think it's a problem
let people apply common sense when touching other peoples packages
jwbthe plan was to send an email to the group asking for voluntary removal, right?
nirikI think if we do any culling we should start with people who never used their powers...
dwmw2it _always_ used to work just fine, when it was RH-internal.
jds2001nirik: is there an easy way to find out?
dwmw2why would we _need_ to remove powers from people who don't use them? What's the point?
jwbdwmw2, tread carefully
nirikjds2001: easy? not sure. Could cull the commits logs
jds2001convincing folks who look at sheer numbers that there aren't many.
nirikdwmw2: yeah, not sure there either.
* jds2001 not personally concerned. But others have voiced concern.'
nirikSo, whats the issue we are trying to solve again? some people don't like that provenpackager has many people in it and thus dont trust it?
dwmw2The 'issue' is pure FUD, as far as I see it.
nirikf13: you around? I know you were one who had some issues with it?
jwbfor something like provenpackager, FUD is all it takes for it to be useless
dwmw2jwb: really?
jwbpeople opt in or out of letting the group touch packages based on their comfort level with how it was seeded, etc
tibbs|hPeople don't want to let provenpackager touch their packages because there are too many people in it.
dwmw2jwb: oh, I didn't realise people could still opt out of that.
niriknevermind that I suspect almost none of them have used their powers.
dwmw2despite that fact that I've probably been told three times already. I'm not very clever
bpeppletibbs|h: Do these folks have any concrete reasons for their fear, or just a general distrust of you contributors?
j-rodthat's what I was wondering
is there actual grounds to this fear
* jds2001 has a local pkgdb at home with an old data dump
jds200181 packages were opted-out iirc
bpeppleThat's been my problem with understanding the problem here.
tibbs|hI don't know if I could find any instance where this was discussed.
jds2001most of them either looked sane, or belonged to one contributor.
nirikthere was a thread on the sponsors alias.
jds2001sane == kernel/lvm2/etc
nirikskvidal and f13 both expressed that they disliked how it was populated.
j-rod"OMG! My package is SOOO important, I can't let *ANYONE* I don't know personally touch it."
^^^ about what it sounds like to me
dwmw2j-rod: The fear is that a well-known and trusted contributor might suddenly suffer a brain tumour and start wreaking havoc on other peoples packages, I believe.
that too.
j-rodand its not like things can't be reverted and people yelled at if they *do* do something dumb
dwmw2mostly what you said, in fact, but I was trying to pretend there was at least _some_ sanity to it
in the interest of being constructive
jwbj-rod, you mean like the kernel?
tibbs|hThere was one instance yesterday where someone was reluctant to open to provenpackager, but eventually allowed it with the note that they can always revoke access later.
dwmw2j-rod: well, maybe a brain tumour could incite me to commit, build _and_ push some packages?
I don't think it should be optional
tibbs|hnirik: That was your discussion with rsc.
dwmw2not without fesco approval, anyway
j-rodjwb: well, there *are* a few packages where restrictions do make some sense...
dwmw2if you want to block provenpackagers (as we might, for the kernel), then you should need fesco approval for that.
* jds2001 thinks fesco needs to review the current list, too.
jwbj-rod, i know.  i was just pointing out the exception to your rule :)
dwmw2but then again, if packagers commit to the kernel when they shouldn't, we should take them out back and shoot them. Problem solved.
j-rodgotcha :)
dgilmoredwmw2: does that include me?
dwmw2proposal: tell people to stop being fucking stupid. Impose a rule that all "provenpackager cannot commit" ACLs must be fesco-approved
j-rodwait, I might have just given grounds to get myself shot...
tibbs|hMost people don't realize that cvsadmin members can commit to their packages regardless of the ACLs in place.
dgilmorej-rod: wondering the same thing.  not taht i often touch the kernel.  but i have done so in the past
jds2001dwmw2: +1
dwmw2dgilmore: but you do so _appropriately_
nirikalso secondary arch people are always allowed.
dgilmoretibbs|h: as are the secondary arch groups
dwmw2I think the real problem is that people are too territorial about their^Wour packages.
j-roddgilmore: yeah, as long as there's no inappropriate touching, its all good... :)
bpeppledwmw2: +1.
tibbs|hThe bottom line is that if you own a package in Fedora, you are going to have to accept that a bunch of people are going to be able to mess with it.
dgilmorecvsadmin fedora-sparc fedora-ia64 fedora-s390 and fedora-arm all can touch any package
j-rod: :)
dwmw2so my proposal stands, perhaps reworded to be slightly more quotable
tibbs|hPeople need to understand that if they have a "mine!" attitude then they should just not bother.
dwmw2tell people to stop spreading FUD, require FESCo approval for any package to prevent provenpackager commits
bpeppletibbs|h: totally agree.
j-rodIndeed -- its a *community* distribution.
jwbso what do we do with the ones that exist already?
jds2001I see five +1's to dwmw2's proposal. I'll ask abadger1999 for a list of current packages to review.
* nirik is ok with dwmw2's proposal I guess.
jds2001jwb: review them.
jwband we need to line up abadger1999 to make the pkgdb changes
j-rod+1 to dwmw2's proposal
dgilmorejwb: review and remove or get justification
dwmw2jwb: give the package owners a time limit (1 month?) to get FESCO approval, then re-enable provenpackager commits if not given
nirikalso, can we add a blurb about sponsoring new provenpackagers to the wiki?
jwbwe need the prevention in place before the review
otherwise we'd have a lot more to review
so, abadger1999 ping
dwmw2if there are still concerns, there are other things we can do.
abadger1999jwb: pong
dwmw2we could allow _commits_ but not bodhi pushes, perhaps?
abadger1999Question: Why not add a third group?
jds2001dwmw2: that's already teh case.
jwbabadger1999, how hard would it be to change pkgdb to not allow packagers to change "provenpackagers can commit" ?
dwmw2jds2001: oh, then people really are just being muppets then :)
jwbabadger1999, a third group?
abadger1999jwb: That should be easy to disable
jds2001abadger1999: I was thinking adding 'fesco' as a group that could change that .
abadger1999jwb: packager provenpackager adminpackager
or similar.
jwbdiff between the latter?
dwmw2do we have stats on how many packages currently _don't_ have 'provenpackagers can commit' set?
I prefer keeping it as simple as possible.
jds2001dwmw2: in my DB db should_open was false on 81 pkgs iirc
nirikwho do we need another group?
* nirik is getting confused here.
jds2001but I don't know how many have 'provenpacker can commit' unchecked.
abadger1999The way packager-provenpackager was set up, it segregates new packagers in the packager group.  That's somewhat of a different thing than provenpackager-adminpackager:
abadger1999adminpackager == a group that has commit access to almost all of the packages.
nirikabadger1999: isn't that 'cvsadmins' ?
and the secondary arch groups?
jwbno, he said 'almost'
abadger1999nirik: cvsadmins have total access with no way to deny.
dwmw2abadger1999: that's what provenpackager was _for_, surely?
nirikyeah, why is that not provenpackager?
abadger1999dwmw2: There's two use cases.  and I think the problem is that we put them together.
dwmw2what's the other one?
jwbi'm not generally in favor of adding more levels of maintainer privs
abadger1999segregating wet-behind-the-ears packagers so they can be sponsored easier.
* jds2001 either.
jwbi mean, i-am-god-packager would be cool, but sort of useless
dwmw2yes, but segregating them from the people who'll have access to almost all of the packages.
two groups, surely?
tibbs|hCurrently we have three access level: your packages - most packages - all packages
Where does another group fit?
nirikwe have now: packager (restricted to their packages), provenpackager (can commit to everything except small exceptions)
abadger1999We don't have any control over what "small exceptions" is.  Is that the problem that we're trying to solve?
dwmw2didn't we just vote to take control over that? exceptions shall be approved by fesco now
jds2001institute policy that every exception must be fesco-approved.
* nirik nods at dwmw2
bpeppledwmw2: correct.
abadger1999So having a third group, FESCo could decide which packages deserve to be excluded.
jds2001right, have a fesco group
jds2001and only that group can tick the box.
abadger1999while leaving the packager/provenpackager dicotomy the way it is.
jwbwe don't need a fesco group
jwbwe just need to give a list to cvsadmin
tibbs|hI wonder if this really makes any difference in practice.  Has there actually been an instance of a provenpackager not being allowed to touch a package that they wanted to touch?
jwbhaving a fesco group would be messy, with member turnover, etc
dwmw2tibbs|h: not yet, I think, but we're trying to prevent it from becoming an issue.
abadger1999the python-2.6 rebuild showed a few.
dwmw2ok, I really have to go to the shops before Karen expires. sorry.
* abadger1999 reads scrollback as quickly as possible
jwbjds2001, how many votes did you count for the proposal itself?
bpeppleDo we have a list of the packages that currently don't allow provenpackager? (I lost track if this was asked or not).
jwbbpepple, no, but we can get one
jds20015, some came in late
jwbjds2001, majority i guess
jwbadd a +1 from me
f13sorry I was not around.
jwbf13 did you need to be?
j-rodand +1 from me, I don't think mine made it in
f13I was pinged about proven packager.
jds2001f13: we wanted to know the reasons for concerns over how it was seeded.
bpepplef13: correct.  You want to read back a bit?
f13erm... can somebody summarize?
I'm torn between lots of meetings
jwbf13, we just passed a proposal: every package has 'provenpackager can commit' checked, and exceptions must have fesco approval
jwbi'll point out that this has nothing to do with concerns over the size of provenpackager itself
f13how does FESCo feel about the reasons we've already seen expressed, such that the contents of provenpackager were ill-filled and untrusted?
f13and what does FESCo do when they feel the justification isn't "good enough" ?
nottingbpepple: my sincere apologies, i was swallowed by another meeting
bpepplenotting: no worries.
notting(and am going to be again in 12 minutes)
nirikf13: can you give some reasons for why people think "the contents of provenpackager were ill-filled and untrusted" ?
tibbs|hI'll note that http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure hasn't mentioned the "whoever can commit" flag for some time now.
jds2001f13: we wanted to talk about that, the size.  My proposal was a voluntary culling of the group.
bpepplef13: is there any concrete evidence that the initial seeiing was ill-filled and untrusted?  I don't really agree with that assessment.
abadger1999notting: log of current discussion: http://fpaste.org/paste/922
f13nirik: I can pull the IRC log from when rsc gave his reasoning
f13nirik: and I think thl posted about it on fedora-devel list, they felt (and I do too) that number of packages has really no bearing whatsoever that people are trustworthy enough to touch other people's packages
* knurd wakes up
f13number of packages is too arbitrary, and they felt it bloated the group way too much
knurd: please correct me if I'm remembering incorrectly
nottingabadger1999: weird. fpaste doesn't horizontally scroll
f13I /thought/ you had mentioned something about this
nirikspot: are you around?
abadger1999notting: weird. This will work: http://fpaste.org/paste/922/plain
f13I just don't see reason in applying a lower bar to the pool of people allowed wide package access than teh bar we apply to people who can sponsor new contributors
nirikf13: I agree it may have made the group bloated with people who will not use it, but I disagree that they are untrusted by default.
knurdf13, not sure myself; must be long ago or somebody else who said it
(or myself getting old and forgetfully)
spotnirik: i am
nirikspot: I seem to remember you had strong feelings about this issue at the meeting we decided how to populate provenpackagers...
spotnirik: well, honestly, i thought it was the wrong way to achieve the goal of encouraging open commits
nirikf13: I think we do need docs/guideline on when to add someone to provenpackger, and perhaps we could cull it of the people not using it...
jds2001nirik: I would start with voluntary culling.
f13<rsc> f13: you may argument with "provenpackagers" former "ueberpackagers, but to get "provenpackagers" afaik only maintaining 5 packages is required. Th
jds2001see where we get with that.
f13at has nothing to do with "proven" nor with "ueber", the German for "above"
nirikspot: yeah, but it had to balance with the people who don't want anyone touching their stuff... I dunno. Perhaps it's all a failure. ;)
sharkczjds2001: yes, that can't hurt
* notting votes -1 on dwmw2's proposal, on the record. in the sense that there should be some sort of review of it, and fesco is the only administrative body around, it makes sense, but I'm not sure that it needs codified. perhaps 'fesco can intervene if there are issues'
spotnirik: i still think it is much more interesting to find out why people have various things locked down.
bpepplef13: If I remember correctly the initial bar was higher than 5.  Let me see if I can find the exact number.
* nirik notes it was 8 packages
jds2001 thinks 8
jds2001 too slow :)
* bpepple sees that nirik beat him to it. ;)
nirikand that does show someone has ability to get 8 packages submitted, reviewed and maintain them all.
f13sure, 8.  Not really a big difference.
nirik: which is super easy if you have 8 perl modules, or python modules, or whatever.
nottingw.r.t. this, i think there are probably too many people in the group, for the usage case that the group is for
f13any number of packages is just going to be arbitrary and in no way demonstrate diversity
nirikf13: sure, but also, someone new with one package could just request provenpackager...
f13whereas sponsors have had /human/ review lookin gover their works and a group decision on their quality and trustfulness.
jwbnirik, and?
jds2001nirik: *that* we need some sort of guideline for.
* nirik notes that people with lots of packages don't get autoupgraded, this was only inital seed.
jwbnirik, afaik, there is nothing that determines how to approve new members
f13nirik: a one package person can request sponsorship status as well, doesn't mean they'll get it.
nirikright. Perhaps we should add a guideline (at least loose one on that)
nottingjwb: Q: how to approve? A: say no, and don't! (tongue in cheek)
nirikf13: yeah, but I suspect in the absense of any guideline, some people are just approving anyone who requests.
* nirik has no proof of that of course.
f13I haven't actually been seeing many provenpackager requests
bpepplenirik: yeah, I think that's a bigger problem than the initial seeding.
f13those that I have seen were from reasonable people whom I would have approved
niriknot too many, but all have been approved.
abadger1999bpepple: http://dpaste.com/106472/
dgilmoref13: there was initially  but not many recently
f13I really wanted proven packager to be initially seeded with a small set of /already/ trusted people.
abadger1999I think that's the list of packages with closed acls.
niriksome I didn't recognize the requestor or the approver
f13then those that /want/ to have provenpackager can actively seek it out, and those we already apply trust to can decide if they should be brought in or not
these types of things need to be pre-seeded with pre-trusted folks. Our sponsors are exactly that
nottingapologies. next meeting.
f13same here.
nirikok, how about this:
bpeppleabadger1999: thanks!  I'll have jds2001 add a review of that list at next week's meeting.
nirikproposal: we don't do anything now, we try and have a hackfest or other informal meeting to try and discuss this and revamp it at fudcon?
f13I'm fine with that.
bpepplenirik: +1
f13my immediate suggestion, boot everybody out that isn't a sponsor, let those that actively want pp re-request membership.
* bpepple since I'm still not convinced it's a problem.
nirikI think we need to step back and figure out our goals here.
bpepplesounds like a good idea, and we've beaten this topic to death today. ;)
f13right, my goals were to allow more access to those that are actively willing and wanting to help and share development duties across the collection.
so that new packagers can pre-allow anybody whom the project entrusts with this ability
and existing packagers can feel comfortable unlocking what is currently locked.
* quaid waves FESCo on in the midst of their discussion, just ping me when you are done with the channel
abadger1999Other goal: Allow new packagers and people taking over an existing package to find a sponsor easier.
jds2001quaid: i thought we had two hours?????
bpeppleso did I/
quaidjds2001: I thought you started at 1700 UTC?
quaidok, so this is still unsolved
we didn't switch our time with the time change
ok, we're doing Docs in #fedora-docs, meeting times still unresolved
* quaid notes that https://fedoraproject.org/wiki/Fedora_meeting_channel says 1700 to 1900
bpepplequaid: we're moving to Friday's next week.
quaidbpepple: ok
bpeppleok, so to summarize our discussion here:
nirikanother goal of more open packages so more people could commit is not served by the current setup.
bpepple1. We approved a proposal to have FESCo approve what packages can exclude provenpackagers.
2. At fudcon there will be a hackfest/discussion about the seeding of provenpackagers.
Is that correct?
jds2001seems right to me.
bpepplejust wanted to make sure I got right.
j-rodsounds like a plan to me
jds2001moving right along
bpeppleif there's nothing else we can probably move on.
* nirik wonders again who all from this discussion will be at fudcon?
--- jds2001 has changed the topic to: FESCo-Meeting -- https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages - nirik
* bpepple won't be there. :(
abadger1999So, you need me to disable the ability for packagers to disable the provenpackager flag
* jds2001
abadger1999And leave it open for just cvsadmins for now?
bpeppleabadger1999: I believe that is correct.
jds2001abadger1999: right.
* sharkcz won't be there
* abadger1999 will
bpepplenirik's proposal looks good to me.  My only nitpick would be that the review wouldn't be in bugzilla.
jds2001nirik, j-rod, f13, me, dgilmore, notting abadger1999 afaik
jwbi'll be there
bpeppleso 6 of the 9 folks in FESCo.
jwbi'm not in favor of on fedora-devel
then you'll get people posting there for normal reviews too
jds2001nirik: i'd require it be in bugzilla.
nim-nimbpepple: I'd like the way mass renamed can be performed clarified
jds2001that way we have better records than a mailing list archive.
nirikbugzilla seems like a good idea.
bpepplenim-nim: any wording suggestions?
nirikbut you would need to attract attention to it somehow
jds2001I'm not thinking that a full re-review be required, just look for proper provides/obsoletes.
nirikie, there is no package rename queue.
bpepplenirik: the could send a note to the mailing list with a link to the bug.
jds2001nirik: yeah, I would say for this *only* send a note to the ML
* jds2001 has a concern that f-devel would wind up being bugzilla 2.0, though :)
nim-nimbpepple: anything that codifies how packagers can be kicked into action instead of hoping individial packagers will initiate their part of a mass rename independently
jds2001nim-nim: isn't that what the non-responsive procedure is for?
(I know what mass rename you're getting at, but I wouldn't do it, FWIW)
nim-nimbpepple: my preference has always been to authorise infra after FPC or fESCO approval to mass-rename cvs components and just have individual packagers pick up from here
jds2001not saying that I wouldn't rename my packages, but you know :)
niriknim-nim: the main issue I have with that is that it's then impossible to review the Obsoletes/Provides... isn't it?
tibbs|hFPC or FESCo aren't going to do the individual change reviews, though.
nim-nimtibbs|h: some packagers will delay changes indefinitely if they don't have a triggering event
tibbs|hAnd we have a procedure for that.  It's called the non-responsive maintainer policy.
nim-nimjds2001: if you have to threaten a non-responsive procedure to make people work on a mass rename, we are in bureaucratic trouble
niriknim-nim: couldn't you just have a pool of people from the group/sig co-maintain?
then you can always make changes as needed...
nim-nimtibbs|h: I'm not saying the non-responsive maintainer policy is bad, just that it's oversized for this case
nirikthe kde folks have no problems doing things that way.
nim-nimtibbs|h: a lot of maintainers just need a flag signal to start renames in a mass rename
tibbs|hSo you're saying that if you have a maintainer who is not responsive, then the non-responsive maintainer is "oversized"?
nim-nimtibbs|h: they don't delay because they are unresponsive, they delay because they just delay
niriknim-nim: shouldn't that be 'hey, maintainer, please rename... here's the rename procedure: <link>'
tibbs|hThat's my comedy moment for today.
jds2001nim-nim: like me. I haven't complied with the new guidelines yet...been slightly busy :)
but I will, I promise! :)
* nirik also has a few to update. ;)
jwbi was planning on doing it during the hackfest
nim-nimnirik: s, it's not because people are of bad will
you just need to get the ball rolling
what is the danger of renaming cvs components in one go?
it does not make the packages build
you can still make a review a necessary step
but it clearly signals people they have stuff to do
nim-nimotherwise I fear inertia will just win the day
* jds2001 got bugs which indicated I needed to do something :)
niriknim-nim: the danger is that there is no review of Oboletes/Provides.
which is the point of this entire thing. If it didn't matter, we could just say: rename your package as you like, just request cvs.
bpepplenirik: agreed.
nim-nimnirik: the bias against renaming is ok for individual renames
jds2001it's not a bias, the bar is quite low.
but it does need to be reviewed that Provides/Obsoletes are correct.
nim-nimhow about mass cvs renaming + mass filing of bugs where the review can take place?
you'll still get a few people that push before review
but you'll always get a few problems like this in a mass operation anyway
bpepplenirik: do you want to update your proposal to use bugzilla, and next week we vote on it?  Or would you like us to do it today? (I'm not really sure how is still around).
nim-nimIMHO the risk is smaller than just have a mass rename stall because of general inertia
nirikbpepple: I can update it and talk with nim-nim more and try and revise it for his concerns.
niriknim-nim: why would you push before review?
nim-nim(and again this is only for mass operation, nirik's proposal is fine for individual renames)
bpepplenirik: that sounds good.
nim-nimnirik: just say I'm cynical and don't expect people to behave perfectly at all times
bpepplejds2001: we can probably move on.
niriknim-nim: sure, but I don't see what the rename policy doesn't cover for mass renames too... ie, for fonts you tell everyone to rename, they update their packages, request review, you can do that and then they check in.
bpepplehmm, looks like jds2001 might have stepped away.
jds2001for a second
bpeppleno worries.
--- jds2001 has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/KDE42
sharkcznim-nim: you can set a deadline, file bugs, on time T the group/sig will take care of the rest, and then really do cvs changes
nim-nimsharkcz: this just reports the charge to a small group
sharkcz: not good
jreznik\me is here, listening for KDE 4.2 feature requests complaints
bpepplejreznik: looks pretty straight forward to me.  I don't think I have any questions/
* nirik doesn't either... +1 here.
sharkczjreznik: looks good to me too
bpepple+1 to KDE feature.
jds2001+1 here
sharkcz+1 for the records
jds2001jreznik: you might want to include the modified packages in teh scope, though.
niriknim-nim: but it would always come to that wouldn't it? even if we did cvs for all the renamed packages in advance, some might not update... so someone would need to go do it for them?
jds2001preferably before next week if possible?
jwbi have to drop.  phone call
nim-nimnirik: the trick is to find a process that maximizes the chances of individual packagers doing their part on time
nirik: this is really my main objection to your proposal for mass renames
jreznikjds2001: yes, I can but it could be long list
jds2001jreznik: put it in another page if you need to, I guess.
wouldn't want to sacrafice readability of the main feature page.
nim-nimnirik: it relies too much on individual packagers being proactive, and does not incitivize doing the right thing
dgilmore+1 for kde-4.2
jreznikjds2001: ok, good idea to use other page to track changes/modified packages
jds2001I see five +1's, the KDE 4.2 feature has been approved.
jrezniknice, thanks!
j-rodbelated +1
--- jds2001 has changed the topic to: FESCO-Meeting -- Free discussion around Fedora
jds2001anyone got anything else to add?
* dgilmore is done
bpeppleI've got nothing.
* jds2001 will end the meeting in 60
tibbs|hDid I miss the FPC discussion?
jds2001FPC discussion?
oh, yeah - you did :)
tibbs|hOK, I'll scroll back.
bpeppleDid we discuss the FPC?
jds2001tibbs|h: we wanted nirik to revise the proposal to use bugzilla.
tibbs|hSorry, no, I mean the FESCo review of the FPC decisions.
nirikno, we didn't discuss the FPC report.
jds2001oh, no, that wasn't discussed.
bpeppletibbs|h: I must have missed the summary e-mail.
tibbs|h: sorry, I was swamped at work yesterday.
tibbs|hI thought I got the summary out in time.  I can't really get it out any earlier, but hopefully the move to Fridays will make that better.
bpeppletibbs|h: yeah, having our meetings on Friday should solve the problem.
jds2001yeah, is there anything urgent in it?
nirikso we need to ratify the font splitting rules?
tibbs|hNot really.
nirikor object if we object rather.
tibbs|hIt's just the font splitting rules; they can wait a week.
bpeppleHow about the FESCo members at FUDCon discuss it, since there should be a majority there.  If I've got any objections I'll send them to the mailing list.
jds2001sounds like a plan
same for dwmw2_gone and sharkcz
* jds2001 ends the meeting in 30
== Meeting End ==
thanks everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!