Extras/SteeringCommittee/Meeting-20060928

Log
0:00           --- | thl has changed the topic to: FESCo meeting in progress -- Init 0:00 <        thl> | hi all 0:00           --> | scop (Ville SkyttÃ€) []  has joined #fedora-extras 0:00 <        thl> | who's around? 0:00 <  BobJensen> | cweyl: everyone got the memo 0:00             * | bpepple is here. 0:00 <       scop> | pong 0:00 <      cweyl> | BobJensen: mmmm, yeah. I'm going to have to ask you to come in this weekend, mmkay? 0:01             * | BobJensen is here 0:01             * | cweyl is here, in his rabble seat 0:01 <     warren> | I'm here 0:01             * | rdieter is 1/2 here (packaging finishing up) 0:02 <        thl> | k, so let's start slowly 0:02             * | abadger1999 here 0:02 <     warren> | btw, has anyone noticed any further fp.o mail disappearing? 0:02 | Before we start 0:02             * | thl waits 0:02 | Ca someone else write up the minutes this week and next? 0:02 <     warren> | I'll write it this week, but I will be gone next week. 0:03             * | rdieter is now 100% here 0:03 | I'll ask on the list for next week then. 0:03 <        thl> | warren, thx 0:03 | thanks 0:04 <    bpepple> | abadger1999: I should be able to do it next week if needed. 0:04           --- | thl has changed the topic to: FESCo meeting in progress --  M{ae}ss-Rebuild 0:04 <        thl> | scop, ? 0:04 <       scop> | two things 0:05 <       scop> | first, it looks like there are surprisingly many contributors who don't read fedora-extras-list nor fedora-maintainers 0:05 <        thl> | scop, I'm working on getting fedora-maintainers up2date 0:05             * | rdieter shakes head, sad. 0:05 <        thl> | scop, but yes, we next time need to make sure that all people get direct mails on important stuff 0:05 <       scop> | sad and annoying as hell when they start to flame me in PM for removing their stuff 0:05 <     warren> | Perhaps we should have a fedora-devel-announce list, very low traffic and only the big news like "Mass rebuild" 0:06 <        thl> | warren, +1 0:06 <        thl> | I was about to suggest something similar 0:06 <     warren> | scop, who flamed? (examples) 0:06 <    rdieter> | scop: tough-titties for them, I say. (: 0:06 <        thl> | warren, but maybe better "fedora-maintainers-annouce" 0:06 <        scop> | no names here 0:06 <      warren> | scop, were any of these RH engineers? 0:06 <       cweyl> | why not just enforce subscription to -maintainers? 0:06 <        scop> | no 0:07 <     rdieter> | scop: you're too nice. (: 0:07 <       scop> | I've let people's sponsors know 0:07 <       scop> | rdieter, you haven't read my replies ;) 0:07 <      warren> | cweyl, many will ignore entire lists if there is too much traffic 0:07 <      warren> | we need specific low traffic mediums to get out REALLY IMPORTANT news to target audiences 0:07 <         thl> | warren, +1 0:07 <       cweyl> | warren: gotcha.  so maintainers-announce, with automated subscription of everyone in the owners list? 0:08 <      warren> | examples of important news: Mass rebuild, policy changes, 0:08 <         thl> | cweyl, +1 0:08 <     rdieter> | on one hand, folks complain that lists have too much traffic, otoh, folks will complain about too many lists.  *sigh* 0:08 <      warren> | owners.list doesn't match their e-mail in account system right? 0:08 <         thl> | rdieter, warren, it needs to be a moderated list 0:08 <      warren> | yes, moderated 0:08 <     rdieter> | ok, warren: +1 0:08 <     warren> | announce-lists should NOT be filtered 0:09 <     warren> | fedora-announce-list is now useful, after we moved package announcements away. 0:09 <     warren> | i suggested fedora-devel-announce because Core + Extras will eventually become just Devel 0:10 <     warren> | "mass rebuild" warnings would apply to both 0:10 <     warren> | fedora-maintainers-announce is OK too... I prefer fedora-devel-announce personally. Any strong feelings? 0:10 <       scop> | works for me 0:10 <     bpepple> | sounds good. 0:10 <       scop> | (no strong feelings) 0:10 <        thl> | I prefer fedora-maintainers-announce 0:11 <    rdieter> | either ok. 0:11 <        thl> | I don't like fedora-devel to much already 0:11 | Depends on whether we want all package maintainers to read it or 0:11 <      cweyl> | I like maintainers... just because there is a devel list and a maintainers list 0:11 <      cweyl> | so people have their own impressions of what devel/maintainers mean already 0:11 | all community members interested in fedora packaging to read ti. 0:11 <        thl> | because everything is devel and people always post stuff there even if it has nothing to do with development 0:11 <     warren> | fedora-devel-announce would be useful for f13's problem of having a single place to notify RH engineers of freeze schedules too. 0:12 <        thl> | warren, what do we need fedora-maintainers for when we have fedora-devel-announce/fedora-devel-announce ? 0:12 <     warren> | fedora-maintainers is too heavy traffic and many people don't bother to read it 0:13 <     rdieter> | problem being is that there have been a *lot* of (imo) offtopic traffic on fedora-maintainers lately. 0:13 <        thl> | yeah, but what's it purpose when we have a moderated announce-list? 0:13 <       scop> | isn't announce-list for users? 0:13 <     warren> | original purpose for maintainers-list was for the people that matter to discuss things and come to amicable decisions away from the noise of fedora-devel-list 0:13 <    rdieter> | one difference: guarranteed low traffic/moderated? 0:13 <        thl> | I think we get rid of it and discuss the stuff directly on fedora-{extras,devel}-list 0:14 <        thl> | warren, well, in that case I even prefer fedora-maintainers-announce even more over fedora-devel-annouce 0:14 <     warren> | fedora-devel/maintainers-announce would be rarely used, but required subscription for all maintainers both RH engineer and Extras. 0:14 <     warren> | ok, fedora-maintainers-announce I'll create. Open subscription, but moderated posting. 0:14 <       scop> | cool 0:14 <        thl> | warren, thx 0:14 <  BobJensen> | May I? 0:14 <         thl> | BobJensen, if it's on topic -- sure 0:15 <  BobJensen> | From a Docs point of view some of our messages are getting lost also 0:15 <     warren> | BobJensen, should you have a docs announce? 0:15 <  BobJensen> | callls for input on relesenotes and so on 0:15 <         thl> | BobJensen, those could be send there, too 0:15 <    Rathann> | what? not another mailing list... -_- 0:15 <       scop> | I think the announcement about docs freeze arrived on fedora-announce 3 or so days after the deadline :) 0:16 <      warren> | calls for input of release notes and freeze deadlines should go to multiple lists 0:16 <   BobJensen> | warren: they do and stilll at times we get nothing 0:16 <   BobJensen> | warren: nothing meaning replies 0:16              * | scop afk for a few minutes, still a few things about mass rebuild I 0:16 <      warren> | We need better moderating turnaround on fedora-announce-list at times too.  Currently only a small handful of RH employees in the same timezone do it. 0:16 <        scop> | ...'d like to discuss 0:17 <   BobJensen> | I just want ot make sure that this new announce list wil be the right place for these announcements also 0:17 <         thl> | BobJensen, I think those are fine there 0:17 <   BobJensen> | OK good enough for me 0:17 <      warren> | I anticipate only a few e-mails per release cycle to hit this list. 0:18 <  BobJensen> | I just needed to make sure we would be on-topic when posting 0:18 <     warren> | nod 0:18 <        thl> | k, let's stop here with the list; the details can be sorted out later 0:18 <        thl> | let's stop mass rebuild until scop's back 0:18 <     warren> | So, all Core, Extras and Docs maintainers are required to subscribe to this list. And we anticipate very very low traffic here. 0:19             * | scop is back 0:19 <        thl> | warren, and people should use the e-mail adresses that they use in the accounts system 0:19 <      cweyl> | and, just to recap:  new list would be used for announcing freezes, rebuilds, major policy changes; subscription would be rigged automagically at some point not too far in the future? 0:19 <        thl> | so we can automatically check if all are still subscribed 0:20 <       scop> | ok, move on? 0:20 <     warren> | Yes, subscription must be automatic based upon owners.lists 0:20 <        thl> | cweyl, I think that describes it well 0:20 <        thl> | scop, yes, move on please 0:20 <       scop> | second issue 0:20 <       scop> | there's more than a few rebuilds for orphaned packages 0:21 <       scop> | we've announced that they will be removed, yet people are doing it 0:21 <        scop> | the question: when to remove them? 0:21             * | nirik from the rabble seats thinks that shouldn't be allowed. :( 0:21 <     warren> | confused 0:21 <         thl> | scop, mail people directly and/or add those to owners.list as maintainers/co-maintainer that started the reubilds 0:22 <        scop> | warren, you're guilty :) 0:22 <     warren> | "yet people are doing it" what? 0:22 <      nirik> | people are rebuilding packages that they like/need, but not taking over ownership... 0:22 <        thl> | scop, I'd like to avoid removing the packages again 0:22 <       scop> | warren, rebuilding already orphaned/removed packages without unorphaning them 0:22 <      nirik> | FreeWnn adns ghc libvisual-plugins perl-Apache-LogRegex perl-File-BOM 0:22 <      nirik> | perl-Imager perl-Mail-Alias perl-Spreadsheet-ParseExcel 0:22 <      nirik> | perl-Unix-Statgrab perl-YAML-Parser-Syck python-adns python-twisted 0:22 <      nirik> | scim-fcitx 0:22 <       scop> | nirik, some of those are already cleared 0:23 <      nirik> | yeah, thats from the Packagestatus wiki page... so not current. 0:23 <     warren> | I might have missed one 0:23 <       scop> | I'll do another push tonight and update the list 0:23 <       scop> | warren, NetworkManager-vpnc... 0:23 <      cweyl> | scop: do we know who kicked off the builds? I kinda like thl's approach: add them to owners.list. it's a little "evil" tho... :) 0:23 <        thl> | cweyl, should be able to detect from cvs-logs and/or plague 0:23 <       cweyl> | or, maybe just a "hey guys, I noticed you forgot to add yourselves as maintainer in owners.list when you rebuilt package foo" posting to the extras list :) 0:23 <    rdieter> | send the FESCo enforcer thungs to rough-up the trouble-makers? Deploy orbital laser? 0:24 <    bpepple> | cweyl: +1 0:24 <      cweyl> | bring forth the holy fesco orbital laser! 0:24 <    rdieter> | cweyl: +1 definitely 0:24 <      nirik> | package database would help here too... acl to prevent builds unless you are maintainer/co-maintainer... but that doesn't help now. ;) 0:24 <     warren> | scop, I wasn't aware that it was on the orphan list, and someone else has subsequently claimed it. 0:24 <        scop> | warren, about 4 people have claimed it, yet nothing had happened... 0:25 <        scop> | anyway, let's not get stuck to that 0:25 <        scop> | I'll go ahead and make the rebuilders maintainers in owners.list 0:25 <         thl> | scop, simply add them to owners.list as co-maintainers; tha okay or everybody? 0:25 <         thl> | scop, yes please 0:25 <     rdieter> | thl++ 0:26 <     bpepple> | thl: +1 0:26 <        scop> | the problem with adding them as co-maintainers is when the _primary_ maintainers is extras-orphan, they're still effectively orphaned 0:26 <         thl> | scop, okay, so make them maintainers ;-) 0:26 <       scop> | or at least we have no way of knowing which are and which aren't 0:26 <         thl> | but let's move on now 0:26 <        thl> | I have added something to the status section: 0:27 <        thl> | We IMHO should mark all orphans as "dead.package" shortly before FE is branched for FC6 0:27 <       scop> | yes 0:27 <    rdieter> | agreed 0:27 <       scop> | and clean up comps-fe6.xml 0:27 | yes 0:27 <        thl> | scop, +1; the scripts from c4chris might detect that 0:27 <       scop> | and maybe drop all packages whose deps are broken in FC6/devel before the release? 0:28 <       scop> | (drop == remove from package repository, no orphaning, no disabling in CVS) 0:28 <        thl> | scop, well, we should send out some warnings before taht 0:28 <    rdieter> | scop: +1 0:28 <        thl> | scop, but otherwise agreed 0:28 <    rdieter> | haven't these folks been getting warnings already for some time? 0:29 <     warren> | directly in their own personal e-mail, even 0:29 <        thl> | rdieter, yes, but one final warning can't hurt... 0:29 <       scop> | okay, so when to do this? 0:29 <    rdieter> | thl: ok, I guess you have more patience than me. 0:29 <       scop> | late next week? 0:29 <        thl> | k, no yelling, so seems to be settled as well 0:29 <        thl> | scop, yes 0:30           --> | devrimgunduz (Devrim GUNDUZ) []  has joined #fedora-extras 0:30 <        thl> | anything else regarding the mass rebuild? 0:30 <       scop> | anyone know/ have opinions when the CVS/package repo branching will happen? 0:30 <        thl> | scop, jeremy should now 0:30           --> | tibbs-cellphone (Jason Tibbitts) []  has joined #fedora-extras 0:30 <        thl> | scop, normaly two or three days before FC will ship  iirc 0:31 <        thl> | seems jeremy is not around 0:31 <        thl> | let's move on 0:31 <         thl> | scop, I'll try to ping jeremy to get a rough date 0:32           --- | thl has changed the topic to: FESCo meeting in progress --  Enterprise Extras 0:32 <     warren> | oh boy 0:32 <       scop> | ok, summary: so packages with broken deps will be removed next week, orphaned ones will be dead.packagized at CVS/repo branch time 0:32 <        thl> | mmcgrath, dgilmore, what's the builder status for EPEL? 0:33 <        thl> | seem they are not around 0:34 <        thl> | anything else we want to discuss regarding EPEL? 0:34 <        thl> | testing repos? 0:34 <    rdieter> | testing++ 0:34 <        thl> | testing++ 0:34 <    rdieter> | (and thanks for leaving my name/quote on that as the topic here for the last few days...) 0:34 <        thl> | (and locked stable locked down and resynced with testing on each RHEL update) 0:35 <        thl> | rdieter, :) 0:35 <      warren> | locked stable? 0:35 <      warren> | (?) 0:35 <       nirik> | humm... so you must wait a entire minor cycle to get an update in stable? 0:35              * | rdieter scratches head too. 0:35 <      warren> | RHEL (changes only at updates), Extras changes every build? 0:36 <         thl> | nirik, just an idea, but yes, I think that's might be nice 0:36 <         thl> | nirik, bugfixes of course can go into stable directly after some days in testing 0:36 <     rdieter> | so how to differentiate between what can go into stable? 0:37 <         thl> | rdieter, well, maintainers should decide 0:37 <       nirik> | unless there are very clear rules, I expect that might either confuse maintainers, or they might ignore it... 0:37 <         thl> | rdieter, but the guideline should IMHO be: version updates to testing 0:37 <       nirik> | how often are the EL minor updates? 6months? 0:37 < tibbs-cellp> | we ned testing repos in any case. 0:37 <    rdieter> | I'd say epel and FE should follow the same rules 0:37 <        thl> | things fixing actual bugs to testing and then to stable 0:38 <    rdieter> | imo, *all* pkgs should go to some "testing" repo before entering the main/stable one. 0:38 <        thl> | rdieter, +1 0:38 <        thl> | e.g. in extas, too 0:38 <     warren> | RHEL itself will update when errata is released? 0:38 <     warren> | (RHEL in the buildroot) 0:38 <      nirik> | if there is a testing it should be manditory, or people will ignore it like they do for core. ;) 0:38 <    rdieter> | nirik: +1 0:39 <         thl> | warren, yes, I think so; but it shouldn't matter much -- or am I wrong with that? 0:39 | warren: +1 nirik: +1 0:39 <     rdieter> | I suppose we could come up with some mechnism to skip or minimize testing for critical stuff, but that should be the exception. 0:39 <         thl> | rdieter +1 0:40 <      warren> | That means that EPEL needs a release manager 0:40 <       nirik> | it would be cool (both for FE and EPEL) if updates/builds go to testing, and the maintainer has a thing to say "ok, this is ready to push out as an update now" 0:40 <      warren> | or a team to act as release manager 0:40 <         thl> | warren, we first must agree that we really want the lockdowns 0:40 <     rdieter> | thl: define lockdown? 0:40 <     rdieter> | lockdown = testing? 0:41 <         thl> | lockdown=version updates that get build for testing, that are pushed over to stable when a RHEL update is published 0:41 <      nirik> | I would think the maintainer should know best if the update they just pushed is: security, minor bugfix, version update, etc... and would be able to decide when it's ready to push... or use some default days or something. 0:41           --> | kushal (Kushal Das) []  has joined #fedora-extras 0:41 <        thl> | anyway, I think that task it to big to discuss and decide on it now 0:41 <      cweyl> | nirik: something like that is going to require more infrastructure than we have in place right now 0:42 <    bpepple> | thl: +1 0:42 <        thl> | let's discuss this further on the list and get back to it next week 0:42 <      nirik> | cweyl: yeah... :( 0:42 <        thl> | anything else regarding EPEL? 0:43 <         thl> | seems not 0:43 <         thl> | so let's move on 0:43            --- | thl has changed the topic to: FESCo meeting in progress --  Use comps.xml properly,  Activate legacy in buildroots 0:43 <         thl> | skipping both, dgilmore and c4chris seem to not be around 0:43            --- | thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report 0:44 <         thl> | ? 0:44 <         thl> | scop, rdieter, abadger1999 ? 0:44 <     rdieter> | came close to approving: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles (one vote short) 0:45 <     rdieter> | discussed http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives  (needs more discussion) 0:45 | ...because of lack of quorum. 0:45 <        jima> | thl: dgilmore is on the road for work. 0:45 <         thl> | jima, k 0:45 | So DesktopFiles is likely to pass this week on the mailing list. 0:45 <    rdieter> | discussed standardizing static lib policy/pkgname, leaning toward foo-static 0:46             * | thl would like that 0:46 <    rdieter> | some other distros use -static-devel 0:46 <        thl> | would be okay for me, too 0:46 <    rdieter> | I think that's about it. 0:47 <        thl> | k, thx 0:47           --- | thl has changed the topic to: FESCo meeting in progress --  Sponsorship nominations 0:47 <        thl> | any nominations? 0:47 <        thl> | seems not 0:48           --- | thl has changed the topic to: FESCo meeting in progress -- approve kmod's 0:48 <       nirik> | anyone have comments on: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583#c51 0:48 <        thl> | sorry, I didn't find time for the zaptel stuff or the general discussion 0:48 <      nirik> | (zaptel-kmod reply from upstream) 0:49 <        thl> | nirik, well, dgilmore said the releavant thing in #52 afaics 0:49 <      nirik> | was someone going to make a FE_KMOD_PENDING_FESCO and FE_KMOD blocker bugs so we can identify all the kmods? 0:49 <        thl> | nirik, I'll do that soon 0:49 <      nirik> | thl: ok, once you do, let me know and I can go thru and add them to those blockers. 0:49 <      nirik> | unless you want to do it. ;) 0:50 <        thl> | nirik, I'm wondering if a FE_KMOD_FESCO_APPROVED would be better 0:50 <         thl> | opinions? 0:50 <         thl> | (FE_KMOD_FESCO_APPROVED better than a FE_KMOD_PENDING_FESCO) 0:50 <       cweyl> | one's much easier to type :) 0:50 <      nirik> | I don't care... either way. Just to make it clear which ones are waiting for fesco approval, and which ones are ready to review. 0:50 <        thl> | nirik, k, thx 0:50 <        thl> | so let's move on 0:51 <      warren> | thl, I gave you the password for nobody@ right? 0:51 <        thl> | warren, yes, you did 0:51 < tibbs-cellp> | chris stone? 0:51           --> | nim-nim (Nicolas Mailhot) []  has joined #fedora-extras 0:51 <        thl> | tibbs-cellphone, sponsor nomination? 0:52 <        thl> | nirik, and please tell upstream that dgilmore comment in #52 is my opinion, too 0:52 <       scop> | hey, don't pimp it ;) 0:52 <       nirik> | ok... will add another comment there. 0:53            --- | thl has changed the topic to: FESCo meeting in progress --  MISC 0:53 <         thl> | just FYI, I removed all inactive members from cvsextras 0:53 <         thl> | nearly nobody yelled 0:53 <         thl> | only the initrd submitter; he was sponsored again 0:53              * | rdieter golf claps 0:54            --- | thl has changed the topic to: FESCo meeting in progress -- free discussion around extras 0:54 <         thl> | anything else we should discuss? 0:54 <      warren> | nothing here 0:54 <     rdieter> | other than buildsystem support, are there any other blockers for making epel happen? 0:55 <         thl> | rdieter, no real blockers afaics 0:55 <     rdieter> | good.  can't wait. 0:55 <      warren> | I will be away for the next two weeks and available ony via e-mail. Due to my new timezone I will be unable to attend meetings. 0:55 <        thl> | we should considers the early stepps as testing-phase before we really annouce it to the great publich 0:55 <       jima> | i think buildsystem support is partly in. 0:55 <        thl> | "my new timezone"? 0:55 <     warren> | thl, visiting Tokyo and Seoul for 2 weeks 0:56 <    rdieter> | excuses, excuses... (: 0:56             * | nirik submits comments to zaptel-kmod. 0:56 <      warren> | various developer meetings, conferences, fedora promoting stuff 0:56 <         thl> | warren, ohh; well, have fun :) 0:56 <     warren> | I think zaptel's business attitude is just wrong. It might be due to a lack of understanding of dual licensing implications. 0:57  | thl: Chris Stone is a good sponsor candidate IMHO. 0:57 <      nirik> | I think they don't understand the advantages of getting their driver merged upstream... ;( 0:57 <     warren> | We should maintain a hard-line stance about including modules only if they are heading upstream.  zaptel is only hurting themselves if they decide not to participate in Fedora and upstream kernel. 0:57 <         thl> | tibbs-cellphone, k; can you forward this nomination to the lists please? 0:58 <         thl> | nirik, then it's partly our job to tell them why they should work towards getting their driver merged 0:58 <      warren> | (err... this is a policy requirement for kmod right?) 0:58 <       scop> | I still don't share that opinion 0:58 <         thl> | warren, well, yes, that was the plan, but you see scop's comment yourself ;-) 0:58 <      nirik> | thl: agreed. Perhaps someone will jump in with more good advantages on the bug... 0:58 <     warren> | thl, from reading their excuse, it is potentially that they don't understand copyright implications and dual licensing. 0:59 <    rdieter> | ?: where is this kmod policy (upstream) documented? (I couldn't find it the other day) 0:59 <      nirik> | rdieter: which kmod policy? extras? 1:00 <    rdieter> | kmod policy that says they need to make an effort to be upstreamed 1:00 <       scop> | rdieter, link? 1:00 <        thl> | rdieter, that's the reasons why the "FESCo needs to approve kmods" rule 1:00 <        thl> | we never documented it properly 1:00 <    rdieter> | ok, gotcha. 1:00 <        thl> | sorry, I have to much to do atm to work on that 1:00 < tibbs-cellp> | ok 1:01 <      nirik> | yeah, the current policy doesn't say that that is a hard blocker... 1:01 <        thl> | nirik, yeah, I know :-/ 1:01 <        thl> | well, It's getting late 1:01 <    rdieter> | anyone willing to work on that (other than thl)? (count me out, in the short term anyway) 1:01 <      nirik> | IMHO it should be... but it's gonna be hard to enforce. 1:02 <        thl> | rdieter, would be good if some actuall kernel-developers could help with that 1:02             * | thl has to leave soon 1:02 <     warren> | whatever happened to the "If we don't see progress toward upstream inclusion, we will drop your kernel module in X duration of time."? 1:02 <    rdieter> | good idea, though they don't like kmods to begin with... 1:03 <     warren> | anyway, we gotta finish 1:03 <     warren> | anything else? 1:03             * | thl will close the meeting in 30 1:03             * | thl will close the meeting in 15 1:04 <        thl> | -- MARK -- Meeting end 1:04 <        thl> | thx everyone 1:04             * | warren writes up summary 1:04 | thanks warren!