- 1 2007 January 18 FESCo Meeting
- 1.1 Members
- 1.2 Summary
- 1.2.1 EPEL Update
- 1.2.2 Opening Core
- 1.2.3 FESCo-successor name issue
- 1.2.4 Encourage co-maintainership
- 1.2.5 Firefox updates in stable often breaks packages
- 1.2.6 Disallow cvs-import for everything but the initial import
- 1.2.7 What do we want like to see in the approved-message in a review bug
- 1.2.8 Syslog-ng Patent Problems
- 1.2.9 Misc
- 1.3 Log
2007 January 18 FESCo Meeting
- Thorsten Leemhuis (thl)
- Brian Pepple (bpepple)
- Rex Dieter (rdieter)
- Jason Tibbitts (tibbs)
- Toshio Kuratomi (abadger1999)
- Christian Iseli (ch4chris)
- Warren Togami (warren)
- Josh Boyer (jwb)
- Tom Callaway (spot)
- Kevin Fenzi (nirik)
- Dennis Gilmore (dgilmore)
- Jeremy Katz (jeremy)
- Jesse Keating (f13)
- Bill Nottingham (notting)
- Andreas Bierfert (awjb)
- Most of the outstanding issues are waiting on RedHat IS.
- It was brought up that EPEL should have separate guideline (e.g. latest and greatest vs. a more stable approach), and that the EPEL community should make this decision.
- FAB accepted thl's proposal on the FESCo/Core cabal merge. Welcome to FESCo Jesse & Bill!
- f13, notting, and max will be added to the fesco-list.
FESCo-successor name issue
- It was decided to keep the name 'FESCo' after the Core/Extras merge. thl will send an e-mail to the mailing lists announcing this.
- thl is going to send an e-mail to the mailing lists with his proposal.
Firefox updates in stable often breaks packages
- Will look at automating rebuilds of effected packages, though this won't before F7.
- For now, bpepple is going to form a group with other maintainers with packages effected by Firefox updates so rebuilds are handled more quickly.
Disallow cvs-import for everything but the initial import
- It was discussed how using cvs-import quite often overwrite previous changes done by other maintainers.
- The initial thought on how to fix this was to modify cvs-import to prevent this behavior, but many issues need further discussion before acting. Further brain-storming will occur on the mailing list, so as not to waste meeting time.
What do we want like to see in the approved-message in a review bug
- People seeking sponsorship should definitely use checklist of items reviewed, so there is documentation of the knowledge of the packaging guidelines.
- If there is a discussion on issues in the review, then an APPROVED only is probably ok.
Syslog-ng Patent Problems
- RedHat Legal is currently reviewing this issue.
- FESCo meeting in the future will take place in #fedora-meeting beginning on 2007-01-25.
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process - starts in 5 minutes. * jeremy is around c4chris is here <tibbs> I'm just wolfing down something unhealthy. * nirik is here... time to get another cup of coffee. bpepple is going to grab a pot of green tea quick. <rdieter> hmm, coffee... <bpepple> FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, jeremy, jwb, rdieter, spot, nirik, thl, tibbs, warren Hi everybody; who's around? * dgilmore is here spot is here <jeremy> still here :-) <c4chris> me too :-) <rdieter> here <abadger1999> here -- but I have a sick kid so I may abruptly disappear <bpepple> Ok, we'll start slowly. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update <dgilmore> still waiting for internal RH IS on pretty much everything right now need to get a location to host the master mirror I need to work out who to bug for bugzilla notting: any word <notting> nope whatcha need in bz? <mmcgrath> we're just waiting on RH IS right? <dgilmore> notting: a sync the same as we do for extras a new product and components notting: have you spoken with the mirror admins yet to see if epel will be picked up? * thl now around <thl> sorry for being late, we have a storm here the_conley thl <notting> dgilmore: no. was waiting for confirmation on the location from IS first <dgilmore> notting: :) <dgilmore> bpepple: so there is not really alot to report right now <bpepple> dgilmore: ok, thanks. <rdieter> I can lend my pointy stick if anyone needs it. (: --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? <dgilmore> bpepple: i think once we get those last bits in place things will take off <bpepple> dgilmore: I tend to agree. We can probably drop this item. <nirik> yeah, once people can use the packages there will be a lot more interest, I suspect. <thl> dgilmore, what about policies how to manage packages in EPEL? <rdieter> if you build it, they will come. <thl> e.g. latest and greates vs. a more stable approach? <mmcgrath> We've been waiting on a few specific parts for literally months. <thl> packages peobably need some guidelines how to manage those <bpepple> thl: I would think it would have to be a stable approach. <dgilmore> we need to be much more stable <thl> bpepple, sure :) <thl> but the packages need to know that <dgilmore> i dont think we want to offer RHEL type guarantees <rdieter> imo, up2maintainer. <thl> rdieter, I disagree <rdieter> we can't do what rhel4 does, that's umteen years' worth of backports,support to try to offer. <bpepple> Is there somewhere on the wiki we should be have packaging guidelines for EPEL? <thl> rdieter, having a repo that is in parts maintained with a stable approach and in parts with latest and greates is the worst thing we can do <dgilmore> quite often the latest wont build on RHEL so it cant be <rdieter> thl: worksforme wrt kde-redhat... (: <thl> rdieter, sure, but we should not update to the latest if there is no need to IMHO <bpepple> thl: +1 <rdieter> thl: upstream rarely supports anything non-latest either, then what? <thl> then don't update? <rdieter> upgrades, just for upgrades' sake is plain silly, regardless of the target (extras or epel) thl: no updates -> no bug fixes then either? <c4chris> bug fixing is good <mmcgrath> We can really only have guidelines, shoulds and should nots. It will be difficult to enforce things once a package is accepted. <rdieter> that's why I said up2maintainer * notting wonders if this will then stray into the somewhat different upgrade/backport policies currently for core and extras :) <bpepple> mmcgrath: agreed. <rdieter> maintainers are likely the one best informed to make that hard decision, between supportability, bug fixes vs backporting, etc... <rdieter> notting: that's what some people seem to want (I don't, personally) that's my $0.02 anyway. <mmcgrath> We should probably treat it separate from Extras and let the EPEL community decide as we go along. <thl> mmcgrath, +1 <bpepple> mmcgrath: +1 <rdieter> common sense rears its ugly head once again. (: <thl> but we should work out some guidelines soon IMHO <c4chris> I think we should encourage the end (bug fixing) but leave the means (upgrade / backport) to the maintainer's judgement <rdieter> c4chris: and that's different than Extras' existing policy, how? (: <dgilmore> c4chris: sounds fairly sane <bpepple> Ok, anything else we need to discuss regarding this? <dgilmore> bpepple: nope <bpepple> ok, moving on. <thl> bpepple, nope <abadger1999> Regarding speed: <c4chris> rdieter, plenty of new features get added in Fedora --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Did the board acceppt what thl proposed? <mmcgrath> thl: I'll just copy the extras guidelines verbatim right now and we'll change stuff as we need to. <rdieter> bpepple: rubber stamp of approval, "just do it". (: <bpepple> rdieter: good deal. --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- Should we put f13, notting and max on the fesco-list <abadger1999> Should we give people who have packages in EPEL some room to work? * warren back <nirik> I think having a updates system for release versions will help a lot... so people have to figure out what reason they are updating for... <abadger1999> bpepple: Any drawbacks? <thl> +1 for adding notting, f13 and max to the fesco list <bpepple> abadger1999: I don't see any. <abadger1999> +1 <bpepple> +1 <thl> (was my idea in case somebody wonders) <nirik> +1 <dgilmore> bpepple: +1 <c4chris> +1 <spot> +1 <rdieter> +1 <jeremy> do it <bpepple> Ok, consider it approved. --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon! <c4chris> abadger1999, --verbose on th eroom thing ? <thl> bpepple, can we please discuss the FESCo-successor name issue after this topic? I forgot to put it on the schedule... (sorry) <abadger1999> Maybe: "Join the EPEL SIG and start discussing these Policies" <bpepple> thl: sure. <warren> bpepple, yes, I need to post that bpepple, nothing new to report yet, just move forward <abadger1999> Or some such. <bpepple> ok, we'll move on then. <c4chris> abadger1999, ah ok. Yes, that would be good --- bpepple has changed the topic to: discuss the FESCo-successor name issue <bpepple> thl? <warren> FTC wasn't acceptable? * dgilmore like FTC <abadger1999> Basically give the EPEL contributers notice that they can start making their own technical decisions. <thl> well, what names do people like? <abadger1999> Cabal! * bpepple thinks FTC is acceptable. spot thinks FESCO is fine, its easy enough to make it keep working. <thl> abadger1999, nope, I don#t want cabal <warren> Fedora Technical Cabal <spot> no reason to change, move on. <warren> spot, what does it stand for? <abadger1999> warren: :-) <skvidal> Federal Trade Commission <spot> FEdora Steering Committee <bpepple> Leaving it FESCo would be easier. * dgilmore is fine with whatever <thl> abadger1999, look up cabal in the dictionary -- "secret" is found there quite often <nirik> how about "Gnome desktop"? :) <warren> +1 whatever * nirik really doesn't care. <tibbs> I honestly don't care as long as I can type it. the_conley thl <jeremy> tibbs: so not klasdfjalksdfj ? <abadger1999> thl: Yeah -- it's kind of a long-running community vs Red Hat joke. <thl> spot, "FEdora Steering Committee" can be easily confused with the board :-/ <c4chris> jeremy, see, that was easy to typy.... once <thl> abadger1999, well, I got the impression some people meant that seriously :) <spot> thl: i don't see "Board" in there anywhere? :) <-- Sonar_Guy has quit ("Sonar_Guy has Left the Building!!") <rdieter> thl: has FESCo *ever* been confused with the Board (not afaik anyway). <spot> it didn't get confused with the board when the E stood for Extras <thl> FeDiStCo -- Fedora Distribution Steering Committee ? <spot> i think it will be ok now <thl> rdieter, I'm just playing devils advocate ;-) <bpepple> spot: should we do a quick vote to see if we should keep FESCo? * c4chris has no strong opinion, but keeping FESCO kinda makes sense, and is easy... <spot> +1 for FESCO <abadger1999> If it's confusing we could change it to Fedora Engineering Steering Committee or some other unwieldy thing. <dgilmore> sure +1 <bpepple> +1 to FESCo <thl> abadger1999, +1 <abadger1999> Otherwise FESCo as FEdora Steering Committee has my +1 <nirik> +1 to keep fesco... path of least resistance. <thl> +1 for FESCO -- Fedora Engineering Steering Committee * jeremy abstains <bpepple> ok, I don't see anyone voting against it, so we'll remain FESCo. <wwoods> FeSCo <_andy_at_work> +1 for fesco, but I think the naming of the commite isn't significant vs. real work <thl> bpepple, k, I'll post to the list <bpepple> thl: great, thanks. --- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- c4chris, thl -- thl wrote something up; It's not completely finished, but do people like it? <spot> _andy_at_work: if we dont manage to argue over pointless things like naming, how will we ever defeat debian? <thl> just FYI, I slightly enhanced the policy proposal one hour ago but I'd like to get feedback soon <bpepple> thl: I just finished reading it before the meeting, and thought it was good. Haven't read your revisions, though. <thl> I'll probably send it to the list if I don#t hear anything from the other FESCo members soon that okay for everybody? <bpepple> thl: sound good. <thl> I'll probably send it out on Sunday/Monday <nirik> looked good to me. The package db would help a lot... but that will come with time. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? <bpepple> Is this something the QA SIG should look at handling? <_andy_at_work> spot, is it rhetorical question? <spot> _andy_at_work: yes. ;) <nirik> possibly... there is going to be a gap until the core/extras merge tho. ie, new firefox comes out and we have to wait until it's pushed before we can build extras stuff. <tibbs> There will be a gap even after the merge. <nirik> in theory after the merge someone could build while firefox is just in needsign and hasn't been pushed... <tibbs> The only real way to eliminate it is to not push the distro if it has broken dependencies. <nirik> of course that would requre notice that it's there. <dgilmore> nirik: there will be no need for a gap once merged <thl> I think the most important thing to do for now is: have a group that rebuilds all depending packages as soon as possible <dgilmore> right now we have no choice we need it to break before we can build against new updates <thl> e.g. a list in the wiki with packages that need a rebuild and someone that kicks those rebuilds <nirik> perhaps we could get all the folks that maintain those affected packages to band together to do it? <thl> nirik, +1 <bpepple> nirik: +1, since I'm one of those people due to liferea. <nirik> dgilmore: yeah, but if firefox gets pushed before other packages notice it's been updated there is still a gap where packages are broken. <thl> a small gap is better than what we have now <dgilmore> nirik: yes unless we design the new build system/push scripts to handle it <bpepple> thl: agreed. <nirik> shall I mail all those folks and see if they are interested in forming some group to do it? or bpepple, do you want to? <abadger1999> Yeah -- for the generic case of missing notification... libburn/brasero also happened in the last week. <thl> someone just needs to create a list in the wiki, send some mails to the maintainers IMHO <dgilmore> nirik: what id like to see is automated rebuilds for brokeness like that <thl> dgilmore, that should be a long term goal, nothing for now IMHO <bpepple> nirik: That sounds fine. If you don't want to send the e-mail, I can. <nirik> yeah, but it's hard to say if the depending update breaks the package in some way... <dgilmore> thl: it shoudl be a short term goal. i.e we should put it in soonish <bpepple> thl: +1 <thl> dgilmore, well, I requires massive changes to the buildsys afaics dgilmore, I don#t think that will be easy <dgilmore> it probably wont be in for FC-7 but hopefully soon after <thl> and we have a lot to do already... <nirik> I think drjeff made a list of all affected packages for firefox. <dgilmore> thl: we are getting a whole new buildsys <tibbs> Well there's a bomb I don't recall being dropped before. <bpepple> How about we plan on implementing nirik's suggestion, with the plan of eventually automating it sometime after F&? <thl> dgilmore, then we should ask those guys that build it to consider adding that feature -- I don't even know who those guys are -- could you manage that maybe? <bpepple> s/F&/F7/ <thl> bpepple, +1 <dgilmore> thl: im not sure who it will be yet. probably dcbw, f13, me and a few others f13: how is brew/wart's code release comming along <abadger1999> tibbs: The release of brew as open source. <nirik> bpepple: ok, I can send the email or you can, I don't care. Do you have drjeff's list of firefox dependent packages? <dgilmore> bpepple: thats fine <thl> dgilmore, well, then we should all try to keep it in mind for now :) <bpepple> nirik: no, I don't have the list. <tibbs> abadger1999: There's a difference between brew being released and all of Fedora switching to it. <bpepple> Ok, let's move on. <abadger1999> tibbs: It's been mentioned a couple times but it might have been more tangential. <abadger1999> tibbs: True. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? <warren> cvs-import would self-enforce this? <tibbs> Well, I'd vote for it. <nirik> what was the issue here? that cvs-import is overwriting changes that were made in the repo? <warren> maintainers not paying attention <bpepple> nirik: correct. <tibbs> It's pretty much incompatible with development by multiple people. <thl> nirik, that and not looking at the diffs before committing <mmcgrath> What are we trying to accomplish? <nirik> ok, I'm all for stoping that... <bpepple> warren: It would be nice if cvs-import didn't allow anything but the initial import. <tibbs> With CVS at least you can't commit unless your tree is up to date. cvs-import just overwrites everything. <warren> yes, so cvs-import would be modified to self-enforce that? <rdieter> I feel uncomfortable making mandates, would/could it be sufficient to strongly discourage it? <bpepple> warren: that's what I would like to see. <abadger1999> rdieter: No... But maybe we couldmodify cvs-import? <nim-nim> [backroom noise] The java guys will hate it <tibbs> People can always edit the script or just do the steps themselves. <warren> rdieter, people who don't pay enough attention in order to screw up cvs-import would also ignore a mandate. rdieter, err.. ignore a discouragement. <rdieter> ok, fair enough. <dgilmore> i would be happy if cvs-import at the least did a diff and show what was going to change <thl> dgilmore, +1 <abadger1999> dgilmore: And a cvs update? <dgilmore> abadger1999: yeah <warren> I don't like cvs-import after initial import. There is no meaningful cvs comment. <nirik> of course if we change it in cvs-import that means people will need to update to that new version to get the check. ;) <dgilmore> the main problem is think like the one packager who put a .repo file in his package but even a diff might not stop him warren: very true <tibbs> Just give folks who really want it an environment variable to set to disable the check. <warren> by default, disable it <dgilmore> warren: but if we change how cvs-import works so it does updates and diff's etc then we could also get a better changelog <bpepple> Is anyone opposed to disallowing cvs-import for everything? <abadger1999> bpepple: -0.1 <abadger1999> I'm definitely for modifying cvs-import Like rdieter, not sure about mandating "you must not use this script for updates" <c4chris> I like the "cvs update" idea, and tibbs idea too * nim-nim cheers abadger1999 <nirik> modifying cvs-import is fine with me, who will do it though? :) <bpepple> Maybe this is something we can brain-storm about on the mailing list? I'm for modifying the cvs-import, but we probably need to decide what that exactly entails. <rdieter> and exactly what is, and is not reasonably (technically) possible. <bpepple> rdieter: agreed. <tibbs> Perhaps some additional scripts to make maintenance easier would also help. <c4chris> bpepple, sounds fine <tibbs> Some people use cvs-import to propagate a package unchanged between branches. Another tool to do that would be helpful. <dgilmore> tibbs: maybe we need to expand upon the scripts we offer <bpepple> Ok, I'll send an e-mail to the list, and we can work from there. <dgilmore> cvs-clone cvs-update <bpepple> Anything else on this before moving on? --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html <dgilmore> bpepple: something that shows a review happened <dgilmore> if there is a disccussion on issues then an APPROVED only is probably ok <bpepple> dgilmore: agreed. just saying 'APPROVED' is sufficient to me. <dgilmore> if there is no need for a discussion something * nirik things checklists should be encouraged, but not required. People seeking sponsorship should definitely be encouraged to use checklists to show what they checked. <bpepple> s/is/isn't/ <c4chris> nirik, yes <abadger1999> nirik: Pretty much my view. <bpepple> nirik: agreed. <thl> I still this we should encourage new contributors to post more then approved <dgilmore> the more relevant info in the review the better it will help new people see what they need to do * spot thinks it should be obvious that i agree with nirik on this <abadger1999> If you want to gain further trust for being knowledgable about packaging, you have to document your knowledge. * nirik hangs his head in shame for not doing his full checklist on the updated package in the recent postgresql-dbi-link package. ;( <c4chris> tsk tsk :-) <dgilmore> if something is not applicable for a review leave it off the checklist * f13 agrees with nirit's post. <f13> not required. <jima> dgilmore: or say n/a <dgilmore> we dont want too much noise <bpepple> dgilmore: agreed. Is there anything else people want to say regarding this topic? Or should we move on? <rdieter> move on --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- the "syslog-ng patent problems" https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00015.html <nirik> as somewhat of an aside, when checking core packages we should suggest reviewers look at the open core bugs for the package. Might be some good things worth addressing when moving the package in. <rdieter> nirik is on fire! <warren> I'll add that. <notting> nirik: fear the kernel review! <warren> heh <nirik> yeah... might take until fc8 to just read all the bug reports. ;) <tibbs> So, patent problems. <bpepple> Doesn't this need to go to RH legal? <f13> I think hinting at patent problems is nto really our concern. <tibbs> Has legal had a chance to comment? <f13> until there are actual known problems instead of just threats, I dont' think we need to take heed. <rdieter> f13++ * bpepple tends to agree with f13 on this. <tibbs> Is the plan to switch wholesale to syslog-ng? <f13> the plan is to evaluate syslog-ng and if favorable, switch. <dgilmore> f13: +1 <tibbs> Adding it to the repo can't be a problem; using it as a fundamental part of the OS might warrant more careful concern. <bpepple> Ok, I don't think there is much else to add to this now, so we can probably move on. <dgilmore> though i switch all my machines to syslog-ng first thing <abadger1999> What about our committment to only ship open source software? <dgilmore> tibbs: its in extras now <f13> is it not opensource? <tibbs> Is it somehow not open source? <wwoods> patents! PATENTS! BOO SCARY! <abadger1999> If the patent is being granted only to implement the standard then it's not opensource. <f13> but do we have any information about said patent, or when said patent would be applied? <jeremy> I know that this is in the legal queue, I'm not sure if it's been discussed with legal yet <nirik> perhaps the folks who will evaluate if it should replace syslog wil look further into it? <jwb> abadger1999, FOSS is a licensing issue. the software in question is FOSS * jwb is finally here <bpepple> abadger1999: Until legal has looked at it, I don't think there's much we can do right now. <jwb> bpepple, right <f13> we can continue to evaluate it on a technical level. <bpepple> f13: agreed. <abadger1999> f13: Not really. I read the "granted to implement the standard" thing on another blog so no idea of wha the company actually intends. <jwb> abadger1999, take RCU. it's patented. yet it's still open source <f13> maybe even do a test release with it. <abadger1999> bpepple: +1 <bpepple> Moving on...... --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- kernel-naming https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00581.html <dgilmore> so right now kerenl is named on the tarball <nirik> I think this is waiting to hear back from davej, right? and he's going to talk to linus/alan? <f13> yep. last I heard, davej has not reported back from his fact finding mission <jwb> correct <nirik> he's still in .au though, so it's not too surpising... <warren> jwb, didn't IBM grant that patent? <bpepple> f13: Ok, we should probably skip this till next week then. <jwb> warren, yes but my point was it's irrelevant to the _license_ of the software --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop <warren> jwb, nod <spot> ok. http://fedoraproject.org/wiki/PackagingDrafts/Conflicts was approved via email vote barring veto from FESCO, i'll send it out to fedora-maintainers today so everyone knows how it works <bpepple> spot: It seemed fine to me. <tibbs> Well, by policy FESCo gets another week to comment. <spot> tibbs: sure. no rush on my part. <bpepple> Has everyone in FESCo read it? * thl likes it jeremy hasn't read it yet <c4chris> fine here <abadger1999> ... I thought policy was a week or until the next Packaging Meeting.. (has to do some research now) * nirik just as scanned it, but it looks ok from a quick glance. <abadger1999> s/(has/(I have/ <bpepple> Anything else from the Packaging Committee? <thl> abadger1999, we changed that slightly some months ago <spot> bpepple: we're working on trying to resolve the jpackage naming <spot> but we don't have anything final to report there thats it from the PC <bpepple> spot: thanks for the update. --- bpepple has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy -- bpepple <bpepple> this is me. I'm going to send an e-mail out to f-e-l tomorrow looking for additional suggestions. and hopefully have something to present at next weeks meeting. <tibbs> This won't include responsibilities for EPEL branches, right? <bpepple> tibbs: correct. tibbs: do you think we should address EPEL in this? <tibbs> Perhaps only to say that the policy doesn't completely apply to EPEL. <thl> bpepple, no, I don't think so <bpepple> tibbs: agreed. I'll add that to the wiki. <thl> we should probably work on seperating EPEL and FEdora a bit more now that Core and Extras merge <bpepple> thl: agreed. <f13> bpepple: what is this policy? And since we're merging, we're suggesting policy for RH employees too? (Not a bad thing, just something to consider) <thl> f13, look in the wiki ;-) <nirik> Might be worth looking at the debian version of this sort of thing and see if they have any good ideas to add. ;) <bpepple> f13: http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy <thl> f13, then please also take a look at the co-maintainer policy proposal ;-) <bpepple> Moving on...... --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras <bpepple> Anything people want to talk about? <nirik> are we meeting in fedora-devel next week? or here? <c4chris> where do we reconvene? <f13> bpepple: ok, that seems reasonable. <bpepple> nirik: thanks for reminding me. <tibbs> Someone needs to kick chanserv first, though. <c4chris> gah, nirik must've a red keyboard... <bpepple> Does anyone have a problem with meeting in #fedora-devel next week? <nirik> c4chris: ? * dgilmore doesnt <thl> I'm wondering if should have a fedora-meeting channel for meetings could be used by different projects <c4chris> nirik, you type much faster than me... an red cars are the fastest... ;-) <jeremy> thl: might be better <dgilmore> bpepple: i asking in #fedora-devel on monday if it was ok and no one said no <bpepple> thl: that might be a good idea. <nirik> fine with me, but tibbs is right that we need to kick chanserv <dgilmore> gahh bpepple i asked <rdieter> thl: interesting, then normal channel business wouldn't have to be put on hold. <tibbs> Can we get the ops issue figured out as well? <jeremy> I don't want to discourage people from using #fedora-devel for development discussion <rdieter> thl: no overlapping meetings tho. <thl> wejust need to annouce the meetings in the approciate channel to make sure people know about it <bpepple> dgilmore: yeah, I saw that. Thanks. <dgilmore> thl: that works <c4chris> what is it about chanserv ? <tibbs> It won't let you change the topic. <nirik> chanserv won't let you change the topic in fedora-devel <c4chris> oh <bpepple> I like thl's proposal, does anyone object to holding it in #fedora-meeting? <abadger1999> thl: +1 <dgilmore> c4chris: someone with admin privliges needs to fix that <dgilmore> bpepple: nope <dgilmore> someone should register the channel <jeremy> bpepple: +1 <thl> someone should register that channel <nirik> fedora-meeting sounds good, as long as the ops/chanserv is seutp ok on it. <thl> dgilmore, :) <tibbs> Another tab to keep open, or remember to open before the meeting. That's the only real downside. <thl> tibbs, I hope to get rid of #fedora-board then again :) <warren> somebody already owns it anybody here? <thl> I hope the board could use it, too <bpepple> warren: not me. <jcollie> personally, I'd like to see a switch to jabber-based chat rooms <f13> thl: +1, I like #fedora-meeting <spot> gregdek owns it <jwb> warren, gregdek owns it <f13> makes it easier to remember where to go. <jeremy> warren: gdk owns it * jwb thinks it was a chanserv info race :) <bpepple> let's check with gdk, and see if he has a problem with us using it for our meetings. <jeremy> thl: the board can easily switch to it <jwb> jcollie, what? <thl> jeremy, I'd like that btw, where do we discuss policy changes for the near future? fedora-devel (open), fedora-maintainers (closed), fedora-extras (some red hat people might not be around)? <jcollie> jwb, jabber/xmpp can do chat rooms similar to IRC... <dgilmore> thl: fedora-devel <bpepple> For now, let's plan on meeting next week at #fedora-meeting. Is that ok with everyone? <f13> jcollie: the question is, why? <dgilmore> yep <rdieter> ok <thl> bpepple, +1 <c4chris> +1 <nirik> bpepple: +1 <jwb> +1 <spot> +1 <f13> bpepple: +1 <abadger1999> bpepple: +1 <bpepple> Ok. Anything else people want to discuss before calling it quits? <dgilmore> bpepple: not from me <jcollie> f13, jwb, IRC is so 20th century, plus no dealing with chanserv/nickserv freenode.net vs. gimp.net or whatever * bpepple will end the meeting in 60 <delero> jcollie: +1 <jwb> jcollie, and enforcement? <warren> jcollie, OTOH, barrier of entry, when everyone already uses this. * bpepple will end the meeting in 30 bpepple will end the meeting in 15 <bpepple> -- MARK -- Meeting End