From Fedora Project Wiki
< Extras | SteeringCommittee
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 < abadger1999> | Before we start
0:02 * | thl waits
0:02 < abadger1999> | 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 < abadger1999> | I'll ask on the list for next week then.
0:03 < thl> | warren, thx
0:03 < abadger1999> | 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 < abadger1999> | 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 < abadger1999> | 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 < abadger1999> | 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 < abadger1999> | 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 < abadger1999> | ...because of lack of quorum.
0:45 < jima> | thl: dgilmore is on the road for work.
0:45 < thl> | jima, k
0:45 < abadger1999> | 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 <tibbs-cellph> | 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 < abadger1999> | thanks warren!