From Fedora Project Wiki

2007 February 22 FESCo Meeting

Members

Present

  • Brian Pepple (bpepple)
  • Jason Tibbitts (tibbs)
  • Christian Iseli (ch4chris)
  • Tom Callaway (spot)
  • Warren Togami (warren)
  • Rex Dieter (rdieter)
  • Toshio Kuratomi (abadger1999)
  • Kevin Fenzi (nirik)
  • Dennis Gilmore (dgilmore)
  • Bill Nottingham (notting)
  • Jesse Keating (f13)
  • Jeremy Katz (jeremy)

Absent

  • Andreas Bierfert (awjb)
  • Josh Boyer (jwb)

Summary

awjb

  • Andreas has decided to step down from FESCo due to time constraints with his university work.

Core/Extras Merge

Co-Maintainers

  • Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as new sponsors.

Packaging Committee Report

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* jeremy is here
dgilmore is here
<tibbs> I'm here
* daMaestro here
nirik is here.
<notting> hello
<rdieter> yo
<rdieter> Since it's an init process: rdieter: ......... OK
<bpepple> FESCo meeting ping -- abadger1999, awjb, c4chris, f13, jwb, spot, tibbs, warren
* spot is barely awake
<tibbs> It's a busy day here at work; I may be in and out.
<bpepple> spot: didn't expect you to be here since your overseas.
<notting> spot is committed to the cause.
<abadger1999> hey
<dgilmore> spot: good flight?
<rdieter> a real tropper, spot is.
* thl is lurking
<rdieter> trooper, too.
<spot> dgilmore: the flight was fine, but i can't sleep on planes, so i slept all day and woke up a little while ago
<bpepple> Ok, looks like about everyone is here, so we can probably get started.
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- thl -- okay for everybody if the EPEL-SIGs works more on its own and reports to FESCo
<dgilmore> spot: ahh I cant sleep on planes either  so i feel your pain
<abadger1999> bpepple: +1 :-)
<jeremy> sounds fine to me
<thl> hmmm
<dgilmore> i thought we already had agreed to this
<thl> my mail to fedora-devel about EPEL got 0 responses
<nirik> +1 from me... I think it's good to have it in a SIG...
<warren> Just Do It
* cweyl takes his place in the rabble seats
<bpepple> dgilmore: I though so also, but regardless it's a good idea.
<rdieter> just do it: +1
<notting> go forth and multiply. or something.
<dgilmore> +1  from me
<spot> +1
<tibbs> I thought that's how it was working already, so +1.
<bpepple> any '-1'?  otherwise consider it done.
<rdieter> thl: 0 replies means everyone likes it, obviously. (:
<thl> tibbs, I thought that, too :)
rdieter, agreed :)
<tibbs> I don't recall ever seeing the message, but there are so many lists to keep up with.
<bpepple> thl: anything else in regard to the EPEL-Sig?
<thl> bpepple, not that I know of
bpepple, move on
<bpepple> ok.
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren
<dgilmore> bpepple: just that we are having our first meeting this wekeend
<warren> Any further objections to the review with flags process?
<nirik> FYI, of the 1085 core merge reviews, 18.4% have been touched...
<bpepple> dgilmore: I'll put a note in my summary about that, and send it out tonight.
<tibbs> No objections here.
* c4chris is here now
<warren> one modification: fedora-review- means final no, not temporary no
<bpepple> warren: the last version seemed good to me.
<warren> so fedora-review? is exactly the equivalent of FE-REVIEW
<dgilmore> warren: flags seems fine as long as its used
<warren> This process is *BOTH* for Merge and new packages
and we have to get rid of the tracker bugs
the tracker bugs is already removed from new tickets filed through the template interface
<nirik> warren: +1 from me. We should also come up with a plan for all the reviews currently "in transit"
<tibbs> The only question I have is what replaces a query on FE-NEW.
<nirik> tibbs: componet Fedora Review and flags " " ?
or assigned to nobody@fedoraproject.org.
<tibbs> Or that cached review page, I guess.
<warren> tibbs, the best way to do that is the cached status page
we should have more cached status pages
<c4chris> tibbs, I not RE not match [+-?] 
<warren> they are really fast
<c4chris> s/I/I use/
<tibbs> The cached pages should not be run outside of the project, though.
Otherwise we can't expect people to depend on them.
<warren> that was only a test
It seems successful enough to make it a regular FI thing.
<cweyl> implementation question: assuming FESCo likes the new review procedure, can we have an effective date of a week or so from now?  give people time to get used to the new procedure, communications, etc, etc
<tibbs> http://rubenkerkhof.com/review is all I've been using for the merge reviews.
<c4chris> tibbs, yea I thought mmcgrath was going to make them run on fp.o somewhere
<nirik> cweyl: given the level of confusion, is waiting worth it? can't we just tell people as they go to look at the new procedure?
<c4chris> (I even rewrote the stuff ib Python to that end)
<warren> I think we just need to put our foot down and say THIS IS THE PROCEDURE
<bpepple> warren: +1
<warren> people have been confused by the old process and various versions of the new process
<nirik> warren: +1
<cweyl> nirik: the confusion (to me at least) seemed to stem from the fact stuff was changing
cweyl|work cweyl
<warren> this has been especially frustrating for the RH engineers
<cweyl> people were in the middle of things, and all of a sudden they didn't know what they were supposed to be doing
cweyl|work cweyl
<warren> I move that we just ratify it, update the documentation and announce widely.
<nirik> for the merge reviews, we will need to go in and change any in state "-" to state "?", for any in extras, we will need to remove blockers and change state as needed.
<cweyl> a date effective would answer all those questions -- and even people who lag a day or two in reading all those lists should get it
<warren> nirik, trivial
<abadger1999> nirik: I could just be dense here, but I don't see a component Fedora Review
<cweyl> abadger1999: Package Review
<nirik> abadger1999: it's under fedora-extras
<warren> cweyl, people have already been using the new process, or close to it
<cweyl> warren: but not everyone, and really they should just be using it for the merge reviews
<warren> I think we don't need a warning or transition period, because people were already too confused.
<nirik> cweyl: thats part of the problem... some extras reviews have been using the merge procedure, some not, it's a mish mash
<warren> Just put foot down and make it so.
<cweyl> warren: that's where the confusion came from.  "here's this new process!" but not so clear on when, where, why, etc
<warren> THIS IS IT.
<bpepple> ok, how about we vote of ratifying warren's proposal, and then we can decide when it becomes effective?
<cweyl> and that's been effective before :)
<dgilmore> im fine with the flags proposal
<rdieter> for the love of all that is holy, let's ratify the policy, make it so, just do it: +1
<nirik> +1 from me. All good.
<bpepple> +1
<warren> VOTE: Ratify the proposal?  (Independent of when, which is the next vote)
+1
<c4chris> +1
<tibbs> +1
<dgilmore> I say for 1 week both old and new is fine after that new only
+1
<notting> aye.
<spot> +1 (i just want the confusion to end)
<nirik> +1
<warren> OK... is that done?
<jeremy> +1
<rdieter> done, stick a fork in it.
<bpepple> I don't see any one objecting, so consider it ratified.
<f13> I'm here.
<warren> OK.  VOTE: Effective immediately?  (Does anyone object enough to give a -1 on this?  I think we're better off with immediate.)
<nirik> +1
<bpepple> +1
<warren> +1
<c4chris> +1
<spot> +1
<jeremy> warren: -1
<notting> +1
erm, +1 with grandfathering of existing reviews
<jeremy> changes without enough lead time for communication are a continuing disaster :/
<abadger1999> enforced or not enforced?
<cweyl> jeremy: exactly!
* dgilmore votes +1  on same condition as notting
<rdieter> +1
<warren> What if we told people "DO THIS", but if they happen do the the old thing, that's OK until March 1st?
<nirik> jeremy: so it would be "use whatever unclear procedure you think we were using" until the new effective date?
<warren> We can politely remind them as we see it.
<bpepple> ok, I see 8 for immediate, and 1 for not.
<tibbs> +1
<abadger1999> warren: That I would be okay with..
+1
<bpepple> warren: +1
<c4chris> warren, yes
<warren> OK... so the plan is.... DO IT, and politely remind.
<nirik> warren: yeah, I assumed there will be people using wrong procedures until they know better, but the new one should be effective now.
<bpepple> warren: sounds good.
<cweyl> the transition period should be stated in any communications
<bpepple> warren: anything else on the review process need to be discussed?
<warren> Yes.
<jeremy> before we can say "this is it, effective now", we need to have all of the wiki stuff ready to go and udpated to reflect it
<warren> Do we keep the FE-NEW, FE-REVIEW, FE-ACCEPTED as-is?
jeremy, +1
<c4chris> warren, yes, keep
<warren> I could ask dkl to get rid of the tracker bugs and automatically adjust the flags to match the current procedure.  This can be done with no mail.
<c4chris> at least until pkgdb is ready and loaded, then I don't care
<warren> That way querying it is consistent.
FE-ACCEPTED becomes fedora-review+
<cweyl> warren: at least until the transition period is over, then I'd say get rid of the tracker bugs
<warren> FE-REVIEW becomes fedora-review?
<nirik> if it can be done without a flood of emails and c4chris can adjust his scripts I would say change them...
<warren> OK, we'll discuss removal of tracker bugs and fixing the flags next week.
<cweyl> (the lack of FE-REVIEW should be an immediate clue to anyone after that point that something has changed :) )
<c4chris> I'd like to lear a way to get info on who changed what flag when in batch mode
s/lear/learn/
<f13> warren: so that we can change hte review policy at least once a week right?
*sigh*
<warren> f13, what do you mean?
c4chris, hmm good point
<f13> warren: if you go forward with things now, then in a week decide to stop the use of blocker bugs, thats yet another change to the proceedure
<warren> I'm in favor of just stopping the old procedure now and telling people as we see it to use the new procedure.
But some people here want a transition period.
<f13> thats entirely beside the point
you're driving an incomplete change to the review process through
one that you're going to change again, in a week's time.
<notting> warren: i think f13's point is *whatever* we're doing, he wants it decided completely at this meeting
<warren> f13, documented procedure would not reflect the old procedure at all during this week.
<c4chris> what's the rush to kill the trackers now?
<cweyl> the procedure just agreed to here doesn't use the blocker bugs at all...  removing them after the transition period it's just cleanup.  right?
<warren> Killing trackers has nothing to do with ratifying the new review process.
<f13> notting: correct.  rip the bandaid off all at once, not a little bit each week.
<c4chris> just add the flags if you wish, but no need to kill the trackers *right now*
<warren> Killing trackers simplifies what people see, and makes it easier to query things in a consistent way.
<f13> warren: the new process, do you still use blocker bugs?
<warren> NO
none
<f13> ok.
then disregard me.
<warren> OK, schedule: Next week we talk about what to do with tracker bugs
meanwhile I'll talk with dkl about feasibility.
* rdieter thinks f13 is making a lot of sense, bandaid ripping may be the best option.
<c4chris> k
<bpepple> warren: ok, if there's nothing else we can move on.
<warren> Last review topic: Queries and cached pages.
Is cached pages enough?  Do we need also canned queries?
<f13> rdieter: I was confused.  I thought using FE-NEW/ACCEPT/REVIEW was still part of ht eprocess, and we'd revisit that next week.  I was wrong.
warren: canned queries would be nice
<nirik> question: for reviews that are "in flight", should people remove the existing blocker bugs when they add the flag? or leave them?
<rdieter> f13: yeah, I typed too slow. (:
<f13> nirik: I'm in favor of leaving them.
<cweyl> nirik: I say just leave them until they're mass-removed
<warren> Does anyone want to own canned queries and cached pages?  This would involve 1) figuring out what the queries are, putting them on a wiki page 2) working with FI with a RFR to make cached pages a permanent thing.
<nirik> ok, that should be made clear in the wiki/wherever we announce it... so people don't remove them.
<warren> The code for cached pages is pretty much done, you only need to customize it, and maybe talk to mizmo to improve the look.
<c4chris> warren, I can take that
<warren> cool
<bpepple> thanks c4chris.
<nirik> I just saw recently that you can make personal queries public... was meaning to look and see if that would help any.
<warren> OK, anything else we're missing for reviews?
<tibbs> Besides another 500 reviewers, you mean?
<f13> warren: what do merge reviews do when the review is over?  close the bug?
<warren> bpepple, I would like to talk briefly about RH sponsors and internal RH concerns sometime
<bpepple> warren: do you want to do when we look at new sponsors?
<f13> warren: the question came up a few times, is it documented somewhere?
<warren> f13, it actually doesn't matter, if fedora-review+ is set, we're fine.  But that could be better spelled to mean "CLOSED only if you have fixed and tested the binary RPM."?
<c4chris> in principle, CLOSED means package ready in repo
<notting> no, it's a valid point. we should have a documented procedure for a) the case where people want to 'move early' b) the case for when we do the mass move
<f13> warren: closed when built for rawhide?
<warren> bpepple, prior to,  yes
<bpepple> warren: ok.
<warren> notting, f13: It needs to be spelled out explicitly in writing, the details of which we should discuss separately from this meeting?
<f13> warren: sure
<notting> probably, yeah. would need sponsorship, etc. stuff too
<bpepple> ok, sounds like we're finished on this topic, so we should probably move on.
<warren> sponsorship is another aspect that I've been working on, which is part of what I want to talk about when we're on that topic here.
--- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- thl
<bpepple> thl: anything to report on this?
<thl> bpepple, well, it got discussed on the list
<thl> a minor thing was adjusted
so IMHO we should just make this effectie
<bpepple> is it to the point where FESCo can vote on it?
<thl> effective
I think so
<bpepple> Has everyone read it? http://fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership
<thl> we can of course adjust eerything later, but I think this is it for now
<tibbs> I still think it's just so incredibly long, but I don't find anything to disagree with.
I know that some maintainers will bristle at the section about maintaining too many packages.
<notting> thl: mildly concerned about the last entry in 'Policy'; i could see refusing a maintainer for EPEL on technical merits even if they're willing
<thl> I want to prevent that we run into a situation where a Fedora packager tries to prevent that a package gets build for EPEL
if you have a better idea how to circument that: I'm open
tibbs, nearly nobody complained about the "section about maintaining too many packages"
I think that section is important
<notting> thl: maybe just 'can't block co-maintainers for distributions he does not want to support on that basis alone.'
<tibbs> I recall flames on list about it.  I guess that's what you mean by "nearly nobody".
<thl> tibbs, yes (the flames were mainly in the first round)
notting, sounds fine
<bpepple> Ok, let's vote on ratifying this, taking into account nottings suggestions.
<tibbs> But my point was that I don't disagree; I just think some people will.
+1
<bpepple> +1
<notting> +1
<c4chris> +1
<spot> +1
<rdieter> +1
<nirik> +1
<abadger1999> +1
<jeremy> +1
thl thimm
<bpepple> thl: ok, I don't see any objections so consider it ratified.
thl thimm
thl: anything else? otherwise I'll move on.
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations
<thl> bpepple, sorry, was in the wiki
bpepple, moing on is fine
<bpepple> thl: no worries.
warren: you want to talk about sponsors?
<warren> OK
Red Hat has many engineers who do not yet have FAS accounts or sponsorship.
I'm working on documentation to make it very obviously clear exactly why and how to do this.
Furthermore I'm trying to be sure that all regions and offices have designated sponsor trainers.
Some of the proposed sponsors within RH might not fully qualify for sponsor access given traditional requirements.
<tibbs> Yes, that's been my main issue.
<warren> However I ask FESCO to accept this, because it is part of their job requirements to FOLLOW THE WRITTEN GUIDELINES.
<warren> Sponsors are responsible for ENFORCING THE WRITTEN GUIDELINES.
<tibbs> Speaking of sponsor nominations....
<warren> Furthermore we need all of this done sooner than later in order to make RH engineering less cranky about all the big changes in merging for F7.
<dgilmore> warren: i see it this way.  they mess up we are going to scream at you
<warren> Things might not be perfect at first, but I think we'll gradually shift everyone in the right direction.
<warren> dgilmore, that's fine.
<jeremy> dgilmore: scream at me instead
* rdieter think warren is very proficient is his use of the cluestick.
<tibbs> warren: Unfortunately we've seen examples of those who simply don't want to follow the guidelines, and loads of flames about it.
<warren> The big news here, is this implicitly means FOLLOWING THE WRITTEN GUIDELINES is a part of the job responsibility for the RH engineers.
Aside from the buildroot issue?
Ah yes, please scream at jeremy instead.
<tibbs> All kinds of things.  .la files, static libraries, directory ownership are just those that I remember from fudcon.
<warren> jeremy, thanks. =)
<jeremy> warren: np
<dgilmore> jeremy: it will probably go to you and notting also
<rdieter> jeremy is the official fedora ninja after all.
<warren> tibbs, I agree there are concerns.  How widespread would you think is lack of cooperation in following guidelines?
<jeremy> tibbs: removal of static libraries really has to be done with a lot of care.  I've already been bitten a couple of times now due to over-enthusiastic nuking of static libs from a package previously in core :-/
<tibbs> I can't say, as lately there's just too much review traffic for me to follow it like I used to.
jeremy: Which is why this stuff requires hard work, not arguments.
<nirik> I haven't noticed too much of that, but it could well be there...
<rdieter> as long as sponsors are onboard, to police those they sponsor... (:
<warren> jeremy, would you want cases where RH engineers disagree with guidelines forwarded to you to handle?
<nirik> Also, there are a lot of reviews with no answer from the "owner", but that might be due to RHEL5 busyness?
<jeremy> sure!  and we can then go from there
nirik: + rhel updates
<tibbs> Bottom line is that I'm happy to accept RH people that are well-trusted by the other RH people as sponsors.
<abadger1999> rdieter: I agree.  But that's why sponsoring Red Hat people because we need someone in the $GEOGRAPHICREGION office isn't the greatest.
<warren> tibbs, jeremy: perhaps as a policy matter SOMETHING has to be decided regarding buildroot, because that is just a STUPID WASTE OF TIME to deal with on an individual level.
<tibbs> How many times do we have to decide the same thing?
buildroot = the value in the guidelines.
We've voted on it like three times now.
<dgilmore> warren: its simple we agreed on a buildroot  use it
<nirik> I can't recall any merge reviews where they refused to change buildroot... formerly extras I have about 3 blocked on it now.
<warren> What to do about Extras people who refuse to use it and say they will change it back if it is forced upon their spec files?
<thimm> buildroot was just revised and changed by FPC ...
<warren> What to do about RH engineers who do the same?
<f13> thimm: that didn't pass the week timeout
thimm: the mktemp version failed.
* cweyl is starting to be reminded of the %{buildroot} vs $RPM_BUILD_ROOT messiness
<thimm> What's a "week timout"?
<tibbs> thimm: we even withdrew it because it didn't work.
<jeremy> to be entirely honest -- the entire buildroot argument seems like insanity to be spending as much time on as has been spent
<bpepple> Before we become to involved with the buildroot, how about we look at this week's sponsor nominees?
<notting> jeremy: then tell nasrat to start building new rpm ;)
<warren> <deciding body> could decide something, but what about the people who refuse to do it?
<thimm> So why make any buildroot mandatory?
<dgilmore> jeremy: indeed.  we agreed to something use it and move on
<f13> thimm: after FPC votes on something, FESCO and COre was given a week to raise objections before we put it into stone.
* nirik agrees with jeremy
<warren> Sure, this is stupid... but what?
<thimm> f13: ut it was not discussed at all last week?
/ut/but/
<f13> thimm: I wasn't in the meeting.
<warren> And why this buildroot matter at all?  Why can't it be ignored by the buildsys and overridden?
<dgilmore> thimm: it wasnt brought up in the FPC report
<rdieter> warren: that's the long-term plan.
<f13> warren: because it's a guideline to help out of buildsystem building apparently.
<bpepple> Could we table this until the Packaging Committee report later in the meeting?
<warren> OK.
<thimm> dgilmore: but that does not make it dropped, right?
<dgilmore> bpepple: yes
<warren> So, individual sponsors?
<bpepple> Let's start with Parag Ashok.
+1
<rdieter> +1
<dgilmore> +1
<c4chris> +1
<warren> +1
<nirik> I sponsored him long ago, +1 from me. ;)
<abadger1999> +1
<spot> +1
<jeremy> +1
<bpepple> Alright, Parag is a sponsor.
next up is Andrew Overholt.
<dgilmore> 0
<warren> +1
<tibbs> +1 I've reviewed his packages before and he was responsive.
<nirik> I haven't seen much of his reviews, but given all the above and that he's vouched for +1
<bpepple> +1 I looked at some of his java packages and they looked good.
<c4chris> +1
<jeremy> +1
<warren> The java team seems to have respect for the guidelines.
<spot> +1
<abadger1999> +1 Andrew.  Just from a look at a few packages and his mailing list posts.
<f13> +1 Andrew
<bpepple> ok, I don't see any '-1', so Andrew is a sponsor also.
Next up is Thomas Fitzsimmons.
<notting> +1
<warren> +1 (based on Ville's recommendation, who worked with him on jpackage)
<tibbs> What's his email address?
<warren> fitzsim@
<jeremy> +1
<bpepple> +1
<c4chris> +1
<nirik> +1
<rdieter> +1
<spot> +1
<abadger1999> +1
<dgilmore> +1
<tibbs> +1 I've done some of his packages as well.
<bpepple> Alright, so Thomas is a sponsor also.
Next up is Chitlesh Goorah.
<warren> +1
<bpepple> +1 here also.
<tibbs> +1
<dgilmore> +1
<nirik> +1 from me.
<c4chris> +1
<rdieter> +1
<bpepple> Ok, Chitlesh is a sponsor.
Next is Fernando Nasser.
0, I'm not familar with his work.
<rdieter> +1
<abadger1999> Anyone have a quick BZ link to fnasser's reviews?
<dgilmore> 0
<warren> Fernando Nasser was a Ville recommendation
and he's another java team member
<spot> +1
fernando helped write the jpackage "exception" for FPC
<warren> I have to admit I haven't seen Fernando's work
<nirik> 0 - I haven't interacted with him I don't think
<warren> Want to wait until next week for Fernando?
<jeremy> +1
<abadger1999> Yes.
<bpepple> warren: yeah, that sounds good.
<abadger1999> Wait.
<tibbs> +1 next week.
<warren> OK
<bpepple> Ok, let's hold off on Fernando till next week.
<tibbs> fnasser seems to have no completed package submissions.
<notting> warren: can i ask a question? why do we need three java-specific sponsors?
<warren> notting, we don't need, but it doesn't hurt.
<bpepple> That's it for this weeks new sponsors. Moving on.......
<warren> sponsor rank is not just a measure of "we need sponsors" but also that we trust that they follow and enforce guidelines to others.
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<spot> ok, one sec, lemme pull the notes
<abadger1999> tibbs: Did your questions about rvokal get resolved?
<spot> We approved http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl
<tibbs> abadger1999: Yes, I'm fine with rvokal.
<spot> Also, we added a "should" (not a MUST) for http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps
Last but not least, we're still working on the whole buildroot nightmare. More to come.
<notting> jeremy: you should update FileDeps with the sqlite sizes
<bpepple> spot: thanks.
<jeremy> spot: we really need to have better updates from the packaging committee to "the world"...  some of the changes are starting to catch people by surprise and then it's coming back to me
<spot> jeremy: you're right, and we're working o nthat
<thimm> MAybe through the fedora-maintainers-announce list=
<spot> jeremy: hopefully the new job will put me in a better position to be able to be more "announcy"
<jeremy> spot: k.  just wanted to make sure it was mentioned.
<bpepple> Alright, anything else regarding the packaging committee?  Otherwise I'll move on.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
<nirik> One quick item: Should membership in fedorabugs require cladone?
<rdieter> I have a question.
<bpepple> Since we're running late, I'll skip the cvs-import & F7 prep for this week, and go to the free discussion.
<notting> nirik: maybe mebership in fedorabugs should require (cvsextras || fedoraqa)
<dgilmore> notting: indeed
<notting> i.e., some sort of demonstrated commitment to the project
<abadger1999> nirik: Once mether explained that fedorabugs is necessary for triage, I'm not certain that cladone should be a requirement.
After all, anyone can add a patch to bugzilla.
<nirik> true... I was wondering if bugzilla could put up a thing like the wiki...
<abadger1999> fedorabugs just allows triagers to mark dupes, close dead bugs, etc.
<rdieter> abadger1999: +1
<nirik> so, requirement should be 'anyone who has a account and requests it' ?
<warren> fedorabugs?
<rdieter> notting: what's the practical difference between cladone and (cvsextras || fedoraqa)
<warren> Why not auto-approve fedorabugs for anyone who goes through the hassle of cladone?
<notting> rdieter: easier to track, i suppose
<warren> Is that too wide open?
<notting> rdieter: although, realistically, it's up to fedorabugs-sponsors, or whatever
<warren> Or auto-approve fedorabugs if cladone and (cvsextras || fedoraqa)?
<nirik> rdieter: well, cvsextras means they have a sponsor...
<notting> which is... who?
<abadger1999> nirik: Does fedoraqa run the triage project?
<warren> How active as fedoraqa been?
<nirik> no idea. Not sure who or what fedoraqa is. ;)
<abadger1999> How about we approve fedorabugs if they have cvsextras -- fedoraqa sponsors can approve anyone they think is a good triager?
<notting> is there a large group of people who have accounts but !cla_done?
<warren> cvsextras || fedoraqa -> automatic fedorabugs approval?  (one less manual step)
<abadger1999> warren: Does fedoraqa require cladone?
<warren> Why not?
<rdieter> warren: +1
<abadger1999> My goal is for  triagers to have fedorabugs without having to sign the cla.
<warren> Why?
<dgilmore> abadger1999: fedorabugs is not needed to submit patches and do triage work
<abadger1999> Close bugs as dupes?
Doesn't that require fedorabugs?
<dgilmore> i dont know
probably
<nirik> is there a way we can find out what fedorabugs gets? somewhere in bugzilla? or person to ask?
perhaps we should gather more info, discuss on list and then figure out things next week?
<dgilmore> nirik: it gives you alot in bugzilla
<abadger1999> warren: Because triagers aren't providing more content than a normal submitter to bugzilla.  So why do they need to sign cla?
<warren> hmm
<dgilmore> abadger1999: they can reassign bugs to themselves
<warren> Is that really an impediment to fedoraqa not being successful?  I am doubtful.
* warren believes fedoraqa is not successful because it is repeatedly treated as one-time "Bug Day" events rather than a consistent project with consistent leadership, roadmaps, organization, etc.
<abadger1999> warren: Could be you're right.  Someone should talk to mether about it as he's the person who's been approving people for fedorabugs without cladone.
<nirik> who is the contact for fedroraqa? wwoods?
<bpepple> nirik: I believe so.
<jeremy> nirik: yes
<warren> Could we decide upon "cvsextras || fedoraqa -> automatic fedorabugs approval?  (one less manual step)"  Without deciding whether fedoraqa requires cladone yet?
<bpepple> +1, sounds good to me.
<rdieter> warren: +1
<c4chris> warren, +1
<warren> Or rather, what is different about fedoraqa and fedorabugs?
<abadger1999> +1 for automatic
<warren> (Why are they separate?)
<abadger1999> That's a wwoods question.
<nirik> +1 for auto from what I know now...
<warren> +1 for auto, exactly what fedoraqa is, needs to be be figured out
Does this mean the account system just adds peopel to fedorabugs if they get sponsored to cvsextras?
<abadger1999> That's what we should do.  Someone will have to look at sopwith's code to see if that's currently easy though.
<nirik> I would say so. Might get some more reviewers out of it. ;)
<c4chris> yes
<bpepple> warren: that would be preferable.
<warren> OK, we'll see if anyone wants to do that during today's FI meeting.
the fedoraqa part figure out later.
<abadger1999> Sounds good.
<bpepple> Anything else people want to discuss?  Otherwise we should end the meeting.
* c4chris needs to bg real soon
<rdieter> my question: any chance of merging kde stack before f7t3?
<abadger1999> Sorta announcement
<f13> rdieter: depends on the buildsystem.
<rdieter> things will be painful and suck without it, I'm afraid.
<bpepple> abadger1999: go ahead.
<f13> rdieter: if we don't get the buildsystem working by test3, we're kind of shot for the merger happening at all for Fedora 7
<abadger1999> The PackageDB front end is pretty close to being done.    https://admin.fedoraproject.org/pkgdb/
<nirik> rdieter: are there still lots of merge reviews outstanding for kde?
<abadger1999> You can use the interface to enter almost all the owners.list/acl stuff into the database.
<rdieter> nirik: lots, part of the problem is than isn't replying to any of them (so far, we're working on that).
<dgilmore> abadger1999: i checked it out last night looking good
<bpepple> abadger1999: looks nice.
<nirik> rdieter: I could help out with some if you like... would like to see KDE happy. ;)
<rdieter> nirik: thanks, please do.
ok, I'm done, gotta go too.
* bpepple will end the meeting in 60
<abadger1999> Thanks.  We'll need to rewrite the things that draw from ownerss.list to use the packagedb instead.
notting do you have time to do some of that?
<notting> rdieter: well, if you can get the entire stack dep clean from the rest of current-core before then...
* bpepple will end the meeting in 30
<notting> abadger1999: um, i dunno.
* bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End
Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/SteeringCommittee/Meeting-20070222&oldid=10817"