17:00:16 <nirik> #startmeeting FESCO (2010-01-15)
17:00:16 <zodbot> Meeting started Fri Jan 15 17:00:16 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:23 * skvidal is here
17:00:25 <nirik> #meetingname fesco
17:00:25 <zodbot> The meeting name has been set to 'fesco'
17:00:30 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
17:00:30 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
17:00:37 <nirik> #topic init process
17:00:48 * notting is here
17:00:49 <nirik> I'm not 100% sure we will have quorum today... but we can try and see. ;)
17:00:57 * cwickert is here too
17:01:05 <Kevin_Kofler> Present.
17:01:07 <notting> ajax and mjg59 are travelling to LCA
17:01:37 <Kevin_Kofler> That's 4, need one more.
17:01:42 <nirik> dgilmore / pjones: you guys around?
17:01:50 * notting counts 5
17:01:55 <nirik> Kevin_Kofler: we are at 5 I think
17:02:00 <pjones> yo
17:02:25 <nirik> cool. Shall we go ahead and start in then?
17:02:28 <pjones> sorry, was fetching my lunch.
17:02:47 <nirik> #topic Followups on old business
17:03:12 <nirik> I pinged ticket 298 again... to see if we need to take further action there or if it's been resolved.
17:03:18 <nirik> .fesco 298
17:03:19 <zodbot> nirik: #298 (Revoke Paul Johnsons pacakger access and put him on probation.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/298
17:03:40 <nirik> I guess mjg59 was going to work on ticket 291
17:03:42 <nirik> .fesco 291
17:03:43 <zodbot> nirik: #291 (Man pages Packaging Guideline) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/291
17:03:53 <nirik> Any other old business we should revisit?
17:04:26 <nirik> ok, then on to new stuff.
17:04:38 <nirik> #topic Finalize new meeting day/time.
17:04:49 <nirik> Looks like we have 2 blocks... wed or thursday.
17:05:02 <nirik> Does anyone have a further preference?
17:05:20 <nirik> http://whenisgood.net/fesco-meeting/results/8kgg3e
17:05:41 <nirik> sorry, tue/wed
17:05:56 <cwickert> IMO Wednesday is better
17:05:56 <nirik> 20-22 UTC on tuesday or wed.
17:06:13 <pjones> either one is fine by me
17:06:29 <notting> tibbs|h: spot: do we need to move the packaging committee if we do weds?
17:06:50 <spot> notting: yes
17:06:59 * spot doesn't look forward to trying to reschedule that again
17:07:09 <nirik> humm... wed in this channel that time is booked sometimes by http://fedoraproject.org/wiki/Ambassadors/Meetings ?
17:07:20 <nirik> or is that page inaccurate.
17:07:28 <skvidal> I'm sure we can come up with a new channel :)
17:07:34 <Kevin_Kofler> I'm fine with either time, they're both quite late here (9 PM), but I can deal with that, no preference for Tue vs. Wed.
17:07:39 <skvidal> I hear they haven't stopped making channels
17:07:46 <nirik> skvidal: sure, but there are drawbacks to that.
17:07:59 <skvidal> nirik: I know - I was just being silly
17:08:17 <nirik> spot: when is packaging now?
17:09:42 <cwickert> according to https://fedoraproject.org/wiki/Fedora_meeting_channel it is 16:00-17:00
17:09:58 * dgilmore is here
17:10:04 <skvidal> cwickert: which day?
17:10:10 <nirik> wed.
17:10:15 <cwickert> Wednesday
17:10:22 <skvidal> so if we moved to tues
17:10:26 <skvidal> then there isn'tan issue?
17:10:48 <Kevin_Kofler> I think Wed would actually make more sense, we could approve the guidelines fresh off the press, not 6 days later.
17:10:49 <nirik> yeah, it means a week for us to object to their packaging changes, but is that so bad?
17:10:57 <cwickert> does anybody know if the "Fedora Magazine" meetings actually take place?
17:10:59 <notting> spot: wait, that doesn't overlap?
17:11:07 <nirik> cwickert: they never have that I have seen.
17:11:16 * dgilmore thinks we should go with tuesday
17:11:19 <nirik> but ENMA ambassadors does.
17:11:37 <cwickert> +1 for Tuesday because I'm also at the EMEA meetings usually
17:11:38 <nirik> EMEA. can't type.
17:11:43 <notting> spot: how is it an issue if the schedule doesn't overlap?
17:12:08 * nirik thinks tuesday sounds better too.
17:12:08 <spot> notting: because we usually want FESCo to have a window of time to review approved drafts
17:13:02 <pjones> spot: I'm not so sure that's all that bad - if it's simple, we probably won't need much time and can just approve; if it'd take a couple of days, we defer for a week.
17:13:25 <spot> pjones: okay. if there is no overlap, and you don't care, i don't care.
17:13:32 <nirik> well, if we do tuesday, that gives a week...
17:13:43 <Kevin_Kofler> I usually don't have the time to look at the new guidelines until during the meeting anyway.
17:13:44 <nirik> or if we need something faster we could poll for objections in the tickets.
17:14:11 <Kevin_Kofler> But the conflict with EMEA Ambassadors is a stronger argument for not doing Wed, and thus by exclusion, doing Tue.
17:14:18 <nirik> so, tuesday at 20:00 UTC ? going once...
17:14:24 <dgilmore> sold
17:14:28 <skvidal> okie doke
17:14:30 <cwickert> +1
17:14:40 <Kevin_Kofler> +1
17:14:53 <nirik> #agreed New FESCo meeting time is 20:00 UTC on tuesdays.
17:14:54 <pjones> that's 3pm EST5EDT?
17:14:59 <notting> sure, why not
17:15:09 <pjones> (right now, anyway)
17:15:10 <Kevin_Kofler> pjones: Yes.
17:15:11 <pjones> if so, fine.
17:15:11 <nirik> pjones: yeah, I think so.
17:15:25 <nirik> #topic #301 Sponsor Request: "David A. Wheeler" <dwheeler@dwheeler.com>
17:15:29 <nirik> .fesco 301
17:15:30 <zodbot> nirik: #301 (Sponsor Request: "David A. Wheeler" ) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/301
17:15:32 <Kevin_Kofler> 20:00 UTC is 21:00 CET, minus 6 hours that makes 15:00 EST. :-)
17:15:36 <DavidAWheeler_> (I'm here, if anyone wants to ask questions)
17:15:53 <nirik> welcome DavidAWheeler_ Thanks for coming.
17:16:26 <Kevin_Kofler> So the feedback on the sponsors list was split, some positive, some negative (too few packages).
17:17:04 <DavidAWheeler_> (I'm still here)
17:17:06 <cwickert> and too few reviews
17:17:12 <Kevin_Kofler> I'd guess somebody working on formal methods can be trusted to know how important quality is. :-)
17:17:20 <nirik> DavidAWheeler_: are you only interested in the formal methods area? or would you be doing more sponsoring/reviews in general?
17:17:20 * dgilmore thinks some more reviews are needed
17:17:48 <DavidAWheeler_> Willing to do some sponsoring/reviews in general, especially in areas where they improve software development quality
17:18:44 <Kevin_Kofler> Reviews like https://bugzilla.redhat.com/show_bug.cgi?id=548607#c25 look good.
17:18:46 <buggbot> Bug 548607: medium, medium, ---, dwheeler, CLOSED ERRATA, Review Request: pvs-sbcl - SRI's Prototype Verification System
17:19:01 <Kevin_Kofler> I'm +1 to this request.
17:19:03 <cwickert> but even in this review some things were missed
17:19:52 <Kevin_Kofler> (though I'm a bit biased because my dayjob at the university is in a project related to theorem proving ;-) )
17:20:34 <cwickert> e.g. there is a commands in %post that has no Requires(post):
17:20:40 <nirik> well, quantity isn't always required... but doing more reviews gives more experence and helps you notice things you may not if you haven't done a lot of them.
17:20:49 <cwickert> don't get me wrong, still a good review
17:21:32 * nirik gets a page from work... will be distracted for a few if someone can keep the meeting moving along.
17:21:41 <cwickert> and we all miss something from time to time, but IMO more packages and reviews are needed. please don't take this personally, DavidAWheeler_
17:22:29 <dgilmore> cwickert: i fully agree.  i know ive missed things in a review and pickled it up after the fact
17:22:39 <Kevin_Kofler> Now we just need a theorem prover doing reviews for us. ;-)
17:22:40 <dgilmore> s/pickled/picked/
17:23:37 <DavidAWheeler_> Kevin_Kofler- :-)
17:24:42 <nirik> DavidAWheeler_: so, would you be willing to go do another set of reviews and come back to us next week/whenever?
17:25:44 <DavidAWheeler_> I can do that.  It'd probably be more like 2-3 weeks (next week is hectic for me).
17:26:40 <nirik> DavidAWheeler_: excellent. Please keep us posted...
17:26:41 <notting> that's fine. there's no time limit at all
17:27:03 <nirik> #agreed David will do some more reviews and reapply.
17:28:04 <nirik> #topic #302 libssh2 - non-responsive maintainer
17:28:08 <nirik> .fesco 302
17:28:09 <zodbot> nirik: #302 (libssh2 - non-responsive maintainer) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/302
17:28:22 <kdudka> (I am also here)
17:29:31 <nirik> kdudka: so, I saw some commits to libssh2 after that?
17:29:46 <skvidal> kdudka: and did you attempt to contact the maintainer directly?
17:30:04 <kdudka> nirik, *some commit* - they didn't solve the problem actually
17:30:14 * cwickert can't find the name of the maintainer in the ticket or in the review. who is it?
17:30:15 <nirik> kdudka: yeah, looked like whitespace changes.
17:30:19 <nirik> cweyl
17:30:24 <nirik> .whoowns libssh2
17:30:24 <zodbot> nirik: cweyl (djuran in Fedora EPEL)
17:30:46 <cwickert> cweyl awol? I think he owns a lot of packages
17:31:01 <pjones> that does seem weird.
17:31:13 <kdudka> skvidal, sure: http://www.fpaste.org/iM0L/
17:31:38 <kdudka> so far Chris didn't respond any of my emails
17:31:50 <nirik> cwickert: he did commit to libssh the other day, but only whitespace changes.
17:31:51 <cwickert> https://admin.fedoraproject.org/pkgdb/users/packages/cweyl lists 318 packages
17:32:11 <nirik> (perhaps a miscommit, meant to fix this instead?)
17:32:12 <dgilmore> kdudka: you cant demand access,  you can ask for it
17:32:30 <kdudka> after filling the ticket at FESCO, he started commit something, but it didn't make any sense
17:32:44 <skvidal> so he's not awol, then?
17:33:01 <kdudka> among others, this one in curl: https://bugzilla.redhat.com/523796#c8
17:33:14 <dgilmore> he is not awol at all
17:33:16 <notting> hm, so the first bug/patch was in november?
17:33:22 <kdudka> dgilmore, if you mean Fedora ACLs, that's what I asked for in the mail
17:33:22 <Kevin_Kofler> Well, he updated to the latest upstream.
17:33:32 <dgilmore> he commits to perl-local-lib on Jan 4
17:33:32 <kdudka> dgilmore, it's more than a month ago
17:33:39 <Kevin_Kofler> That's not really something that doesn't make any sense.
17:33:42 <dgilmore> kdudka: you didint ask you demanded
17:33:43 <Kevin_Kofler> It just doesn't fix the bug.
17:34:01 <notting> hm
17:34:08 <kdudka> Kevin_Kofler, it doesn't fix anything
17:34:25 <dgilmore> > I am the new maintainer of RHEL libssh2 package. Could you please grant me
17:34:27 <Kevin_Kofler> Updating to current upstream makes sense.
17:34:28 <dgilmore> > Fedora ACLs for the package? I am going to co-maintain the Fedora part as
17:34:31 <dgilmore> > well. Thanks in advance!
17:34:35 <notting> so i think the first step would be to request cweyl respond to kdudka's request for comaintainership (yes, no, or otherwise)
17:34:43 <dgilmore> kdudka: you could have said i would like to help co-maintain in fedora as well
17:34:49 <kdudka> dgilmore, not sure what's the difference (I am not native speaker)
17:35:01 <Kevin_Kofler> IMHO we should require cweyl to accept it or remove his package ownership.
17:35:16 <dgilmore> kdudka: "i am going to"  is very pushy and demanding
17:35:17 <cwickert> dgilmore: "I am going to co-maintain the Fedora part as well" sounds clear to me
17:35:19 <Kevin_Kofler> It sucks for the RHEL maintainer not to be able to commit his fixes to Fedora and it's bad for Fedora if fixes only make it into EL.
17:35:31 <dgilmore> cwickert: i find it pushy
17:35:38 <kdudka> dgilmore, nothing wrong intended ... worth to reply in any case
17:35:49 <cwickert> dgilmore: ok, not a native speaker too
17:35:54 <skvidal> okay
17:35:59 <nirik> "I would like to" "I am willing to" "if you would like I would" all sound better, but thats all bikeshedding. ;)
17:36:02 <skvidal> so let's stop discussing tone
17:36:06 * nirik nods at skvidal
17:36:08 <skvidal> and discuss the policy
17:36:16 <kdudka> thanks all for suggestions, will do next time
17:36:38 <dgilmore> he is clearly not awol
17:36:41 <kdudka> however I don't think it solves the problem now
17:36:44 <dgilmore> but he is not responsive
17:36:57 <skvidal> who is his sponsor?
17:37:05 <kdudka> what does actually mean awol<
17:37:18 <skvidal> Away WithOut Leave
17:37:19 * nirik digs into the account sys to see.
17:37:19 <dgilmore> zodbot: fasinfo cwyel
17:37:23 <skvidal> AWOL - it's a military term
17:37:32 <zodbot> dgilmore: User "cwyel" doesn't exist
17:37:35 <pjones> kdudka: it's an old military term to say that you've skipped out on your duties.
17:38:02 <abadger1999> .fasinfo cweyl
17:38:02 <pjones> zodbot: fasinfo cweyl
17:38:05 <zodbot> abadger1999: User: cweyl, Name: Chris Weyl, email: cweyl@alumni.drew.edu, Creation: 2005-12-01, IRC Nick: cweyl, Timezone: UTC, Locale: en, Extension: 5100333, GPG key ID: 7962f5cb, Status: active
17:38:10 <zodbot> abadger1999: Approved Groups: cla_done fedorabugs packager cla_fedora gitcamelus provenpackager
17:38:14 <zodbot> abadger1999: Unapproved Groups: None
17:38:17 <zodbot> pjones: User: cweyl, Name: Chris Weyl, email: cweyl@alumni.drew.edu, Creation: 2005-12-01, IRC Nick: cweyl, Timezone: UTC, Locale: en, Extension: 5100333, GPG key ID: 7962f5cb, Status: active
17:38:22 <zodbot> pjones: Approved Groups: cla_done fedorabugs packager cla_fedora gitcamelus provenpackager
17:38:26 <zodbot> pjones: Unapproved Groups: None
17:38:39 <cwickert> cweyl was last seen in #fedora-devel 17 weeks, 0 days, 1 hour, 32 minutes, and 56 seconds ago: <cweyl> later!
17:38:44 <pjones> I bet he's on vacation or something.
17:38:50 <nirik> his sponsor is jwb. ;)
17:38:59 <Kevin_Kofler> 17 weeks is a long vacation. ;-)
17:39:34 <pjones> Kevin_Kofler: but he hasn't gone that long without doing things, merely that long without being on irc.  we've got plenty of valuable people who are /never/ on irc.
17:39:43 <nirik> libssh2 was commited to by him yesterday
17:39:57 <nirik> updating to 1.2.2
17:39:59 <Kevin_Kofler> I'm also almost never on #fedora-devel, though I lurk around on #fedora-kde almost all the time.
17:40:05 <pjones> seems like sending some emails might be helpful.
17:40:07 <kdudka> anyway it's pretty annoying ... we worked on the bug with Peter Stuge from upstream till 6AM to get it fixed ... now waiting two months to get the fix in Fedora :-)
17:40:27 <Kevin_Kofler> The problem is, not being IRC (assuming he's not on some other channel) means it's harder to join him.
17:40:36 <pjones> Kevin_Kofler: yeah.,
17:40:39 <Oxf13> 'join him' ?
17:40:46 <pjones> Oxf13: "invite", presumably.
17:40:47 <nirik> I'd like to propose we mail him and ask him about this and see if he can/is willing to add kdudka as co-maintainer, etc.
17:40:49 <Kevin_Kofler> Contact him.
17:40:59 * nirik is willing to mail him/irc/call whatever.
17:41:07 <pjones> nirik: ... and if that doesn't work, we invite him to the irc meeting next week.
17:41:10 <Oxf13> yeah, IRC isn't the only method of communication
17:41:21 <dgilmore> nirik: sounds like a plan
17:41:22 <nirik> pjones: sure. Sounds good.
17:41:29 <pjones> +1
17:41:40 <notting> nirik/pjones: sounds like a plan. +1
17:42:07 <cwickert> +1, I don't like calling a person with 318 packages MIA without trying everything
17:42:10 <kdudka> let me note it's sort of urgent issue as curl builds in Koji are broken...
17:42:31 <Kevin_Kofler> kdudka: Maybe a provenpackager should just commit this particular fix?
17:42:32 <nirik> #agreed nirik will try and contact cweyl and get information flowing, failing that will invite him to the next meeting to try and fix things up.
17:42:39 <cwickert> but what about libssh2? can somebody give kdudka commit access?
17:42:39 <kdudka> could some proven packager here at least apply my fixes?
17:42:39 <Oxf13> if it's a matter of something broken, why can't a provenpackager do the work?
17:42:40 <Kevin_Kofler> I could do it.
17:42:48 <dgilmore> kdudka: send me the fixes and i will commit them
17:43:03 <Kevin_Kofler> Or I see dgilmore volunteered. :-)
17:43:04 <Oxf13> we can get the important fix in without having to change ACLs
17:43:13 <kdudka> dgilmore, sounds great - where should it go actually?
17:43:18 <nirik> cwickert: I don't think we should now... lets find out why cweyl hasn't first.
17:43:25 <cwickert> ok nirik
17:43:27 <dgilmore> kdudka: dgilmore@fedoraproject.org
17:44:25 <kdudka> dgilmore, I'll send it today
17:44:29 <kdudka> dgilmore, thanks in advance!
17:44:37 <nirik> shall we move on to the next topic? anything else on this?
17:45:21 <nirik> #topic #297 Please consider the idea of a security (privilege escalation) policy
17:45:26 <nirik> .fesco 297
17:45:27 <zodbot> nirik: #297 (Please consider the idea of a security (privilege escalation) policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/297
17:45:35 <nirik> so, adamw filed this just before xmas.
17:45:50 <nirik> it's not really moved since then.
17:46:54 <nirik> should we try and open another dialog on the list?
17:46:54 <notting> well, i think we need someone to come up with a proposal
17:47:01 <nirik> does someone want to take point on this?
17:47:08 <Kevin_Kofler> The list of things an unprivileged user should not be able to makes sense (though the system clock part is AFAIK currently NOT true with system-config-time; KDE on the other hand does require admin auth).
17:47:17 <Kevin_Kofler> The problem is more: how do we verify this?
17:47:17 <nirik> or can we pawn^H^H^H^Hassign it off to some other group?
17:47:24 <pjones> I'd like to put some work into this, but right now there's no time due to RHEL 6 deadlines.
17:47:39 <pjones> (but those should be less crappy next week...)
17:47:48 <nirik> Kevin_Kofler: well, QA is asking for a policy that they can test against... they don't know what it should be currently.
17:47:53 <Kevin_Kofler> Having to request FESCo approval for every SUID binary would suck, it'd mean even longer FESCo meetings and delays for packaging.
17:48:06 <wwoods> how often does anyone actually add an SUID binary?
17:48:07 * adamw here
17:48:23 <Kevin_Kofler> (and stuff which gets root through e.g. D-Bus activation is effectively SUID)
17:48:30 <pjones> Kevin_Kofler: that's also not what's really appropriate here at all
17:48:33 <adamw> as wwoods says, we have no preconceptions of what the policy should be
17:49:04 <Kevin_Kofler> wwoods: KDE is moving from using kdesu for entire systemsettings modules to PolicyKit/KAuth mechanisms.
17:49:19 <nirik> we can also come up with a basic policy and add to it over time, doesn't have to be eveything at once, IMHO
17:49:20 <wwoods> which means less SUID binaries.
17:49:28 <Kevin_Kofler> So KDE is currently in a phase where you'll see several stuff running as root added, but it's all to avoid having to kdesu the whole UI.
17:49:33 <adamw> nirik: pawning it off to someone is more or less what we're asking for...we just want whatever butt kicking needs to be done to cause someone who actually has a clue about security to come up with a policy
17:49:39 <wwoods> so I still don't understand your point.
17:49:54 <Kevin_Kofler> Our system-config tools are in a similar phase (porting from consolehelper to PolicyKit).
17:49:57 <pjones> really what we need is guidelines so that a) developers know what sort of things they should be using polkit for, b) they know what /kind/ of things they should be asking for more input on, and c) it's possible for others to audit it and decide if they've missed something.
17:50:00 <nirik> adamw: yeah. But I'm not sure who that will be. I guess I could take some kind of stab at it, but ENOTIME for me too. ;(
17:50:10 <adamw> Kevin_Kofler: that's actually exactly the kind of situation which causes me to want such a policy to exist
17:50:17 <adamw> Kevin_Kofler: it's precisely what led to the packagekit snafu
17:50:42 <adamw> when the only option was 'run the entire packagekit app as root' it was screamingly obvious that it should require authentication to do so
17:51:06 <pjones> it's not a "the policy must say who's reviewing each use" sort of thing.  It's a "fedora's broader approach to $usage is $methodology, so in that case $structure of polkit acl is appropriate"
17:51:14 <adamw> it only became a problem because things could be made more granular, so a specific packagekit _operation_ could be made not to require authentication...
17:51:48 <Kevin_Kofler> Indeed, this migration can open up some holes.
17:51:55 <Kevin_Kofler> But it's also a lot of stuff to audit.
17:51:57 <adamw> Kevin_Kofler: so it could perfectly well happen with kde as it goes through the same process - it seems obvious that there needs to be a consistent policy about how exactly you deal with the question of authorization / authentication for each much more granular action you define as you go along.
17:52:05 <pjones> adamw: no, it only became a problem because we didn't have any way for richard to know a priori that more people should be in on that decision
17:52:13 <nirik> if the policy says "user cannot do X without authentication as admin user" then it's possible to test for.
17:52:18 <skvidal> pjones: .....
17:52:29 <pjones> skvidal: apart from "that seemed wrong to us" ;)
17:52:38 <skvidal> pjones: and to everyone in the fecking world
17:52:43 <pjones> skvidal: but that's the point - it seemed wrong to us, so if he'd come to us, ...
17:52:52 <skvidal> pjones: if the policy is "don't be dumb" then so be it
17:52:58 <pjones> skvidal: not to everyone.
17:53:14 <skvidal> pjones: everyone outside of the desktop echo chamber?
17:53:24 <Oxf13> that's not being helpful
17:53:27 <nirik> so, I don't think we are going to decide anything here aside from that we think it needs to be done, right?
17:53:42 <nirik> anyone willing to work on it? or have ideas on who we can ask to work on it?
17:53:46 <Oxf13> (because there were those in the desktop group who also didn't agree with the change)
17:53:54 <nirik> pjones: you willing to look at it after next week?
17:53:56 <Oxf13> this isn't a one group against another group kind of thing.
17:54:00 <skvidal> Oxf13: I didn't say desktop group
17:54:01 <pjones> skvidal: I realize you think it's a severe lapse, but in reality what happened was that he chose between two very similar policies, both of which were implemented, and he picked the wrong one for one thing.
17:54:35 <adamw> pjones: well the point is that these decisions only become problematic with the level of granularity that pk offers
17:54:38 <pjones> skvidal: so yes, it had serious ramifications, but if we'd had a policy that says "users don't get to pick which packages get installed" ahead of time, he probably would have picked the other.
17:54:46 <pjones> adamw: that's simply not the cas
17:54:48 <pjones> case
17:54:51 <nirik> as a side note, I think any security policy should have a 'this is default fedora' and a 'this is something it's possible for a local admin/spin to change'
17:55:10 <pjones> nirik: yeah, that's probably _generally_ true.
17:55:21 <pjones> nirik: I'd like to think we wouldn't indorse the "rootkit" spin ;)
17:55:45 <adamw> pjones: no, we'd just rename it the 'security audit' spin ;)
17:55:49 <Kevin_Kofler> Another good question is: should it be possible to retain authorizations for this kind of stuff. I know PK1 dropped retaining authorizations, but it'd be possible to implement them at app level, and possibly also at auth agent level (I'm toying with the idea of having polkit-kde allow retaining the authorization for things listed in some systemwide editable-only-by-root config file, I haven't evaluated the technical
17:55:49 <Kevin_Kofler> feasibility though).
17:56:20 <nirik> sure, so the 'this is possible for local admin/spin to change' would also default to 'deny by default'. So, only those things allowed/listed there would be acceptable to change there.
17:56:21 <Kevin_Kofler> So the question is, assuming this is technically feasible, would this be desirable or yet another no no not to step into.
17:56:30 <pjones> adamw: the granularity changed how obvious it was that his decision was wrong, making it less obvious.  less granularity still leaves the same kinds of decisions, which we're currently giving no guidance on.
17:56:47 <cwickert> will this policy also apply to spins? in the security spin there are currently lots of apps running with root privileges without authentification, but only in live-mode, not on the installed version
17:57:12 <pjones> Kevin_Kofler: doesn't polkit /already/ have that functionality built in?
17:57:13 <adamw> pjones: i really think what i said is true, though. 'should trusted updates be possible without root authentication' is a much trickier question than 'should my entire package updating application run without root authentication'. yes, in _theoretical_ terms anyone can screw up any security choice and therefore we should have had a policy for this years ago. but in practical terms, the chances of anyone screwing up are now far far higher because a) th
17:57:13 <adamw> ere will be more decisions and b) they will be harder decisions. hence it becomes much more _important_ to have a policy.
17:57:18 <pjones> Kevin_Kofler: I think it does...
17:57:41 <adamw> pjones: as kevin said, they took it out
17:57:49 <pjones> adamw: that's fair, though I don't think it reflects your previous point ;)
17:57:56 <Oxf13> upstream decided that it wasn't something they want to see
17:57:57 <pjones> ah, okay.
17:58:11 <pjones> well, that's unfortunate.
17:58:13 <adamw> Kevin_Kofler: i'm not sure it'd be a good idea to externally reimplement something into policykit that the policykit developers decided was a bad idea.
17:58:14 * nirik sets a timer for debate on this, since the chances of us coming up with and approving a new policy here is 0. ;)
17:58:17 <Oxf13> that instead of retained auth for some people for some apps and lots of popup boxes, they'd rather see users defined to have roles
17:58:19 <Kevin_Kofler> pjones: Not anymore.
17:58:23 <adamw> but yeah, it'd be nice to stay focused
17:58:24 <Oxf13> and the roles would get rights
17:58:30 <Kevin_Kofler> Retaining authorizations permanently got removed in PK1.
17:58:34 <Oxf13> but the roles stuff hasn't landed yet
17:58:35 <adamw> and answer the important point: who should write a policy for this and how do we make them do it?
17:59:05 <Kevin_Kofler> Which is one of the reasons PackageKit switched to that "always allow" policy which caused the chaos.
17:59:11 <Oxf13> adamw: the old strategy was to write it your self, however poorly it is, and then show it to the right people
17:59:14 <pjones> anyway, we need a policy that provides guidance on what kind of actions need what kind of roles.  from that you can derive both decision making on the part of developers and test things for correctness,
17:59:16 <adamw> i mean, if nothing comes out of this, we (qa) have an emergency fallback procedure that we will kick in: we'll write our own policy, test according to that, and when people complain that we're Doing It Rong we'll point out that no-one else seemed to give a stuff
17:59:21 <adamw> but I _really_ don't think that seems optimal
17:59:31 <Oxf13> asking for help doesn't get you much, but incorrectly answering something will get you a lot of corrections and attention.
17:59:36 <pjones> and we don't have to get into the nitty gritty details of every damn thing
17:59:43 <nirik> fine, I can oversubscribe my time some more and work on this some.
17:59:50 <pjones> adamw: tbf, if you guys wanted to write a policy and bring it to us for approval, that wouldn't be the worst plan ever.
18:00:09 <adamw> pjones: as long as someone who knows what they're talking about will look it over then that can probably work.
18:00:13 * nirik thinks the first step is to find out if RHEL/Debian/Ubuntu/Suse/Mandriva already have something like this we can look at.
18:00:36 <adamw> nirik: rhel really doesn't (i talked to the rhel guys and they said they'd be very interested in reading whatever we come up with :>)
18:00:39 <pjones> the current RHEL way isn't particularly interesting to us.
18:00:46 <adamw> nirik: mandriva doesn't either, i'd know if they do. dunno about the others.
18:00:58 <nirik> ok.
18:00:58 <pjones> (it's basically "let fedora figure it out and then prune their packagelist of stuff we don't like when we do a major version rev")
18:01:20 <adamw> good thought, though. i'll check with ubuntu / debian / suse before we start writing anything.
18:01:34 <nirik> adamw: could you do that and add your findings to the ticket?
18:01:39 <adamw> nirik: alright
18:01:59 <nirik> adamw: also, even tho it's likely futile, can you mail the security list and ask for interested people?
18:02:09 <adamw> nirik: already done :) both fedora and rh security
18:02:23 <pjones> that should bring some fun from the peanut gallery ;)
18:02:24 <adamw> i'll cc fedora security on any further work on this of course
18:02:42 <adamw> but yeah, i did that long before coming to fesco, if it'd worked i wouldn't be bothering you
18:02:52 <nirik> adamw: I don't recall seeing it there, and I am on that lsit.
18:02:58 <nirik> it gets almost no traffic.
18:03:06 <adamw> hum. lemme see
18:03:15 <nirik> oh dho. it was.
18:03:21 * nirik will check his filters.
18:03:40 <adamw> nirik: https://www.redhat.com/archives/fedora-security-list/2009-November/msg00000.html
18:03:45 <nirik> so, what do we do here? let adamw add info and revisit?
18:03:55 <adamw> lots of discussion, but mostly of the 'nitpick' variety, no 'oh yes let's write one!'
18:04:14 <nirik> adamw: you mean: http://lists.fedoraproject.org/pipermail/security/2009-November/001398.html :)
18:04:40 <skvidal> nirik: :)
18:04:51 <adamw> nirik: as soon as that's the first google result, i will =)
18:04:59 * adamw just finds the archives via google
18:05:19 <Kevin_Kofler> Well, some people were still mailing to rhl-devel-list and using rhl-devel-list archives not too long ago. ;-)
18:05:42 <nirik> ok, so, lets punt to next week, hope for more info and people willing to work on it
18:06:06 <nirik> thanks for the input adamw / wwoods.
18:06:15 <nirik> #topic #303 Feature: KDE PolicyKitOneQt ( https://fedoraproject.org/wiki/Features/KDE_PolicyKitOneQt )
18:06:19 <nirik> .fesco 303
18:06:20 <zodbot> nirik: #303 (Feature: KDE PolicyKitOneQt ( https://fedoraproject.org/wiki/Features/KDE_PolicyKitOneQt )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/303
18:07:35 * nirik wonders how Kevin_Kofler will vote here. ;)
18:07:37 <Kevin_Kofler> +1, already in Rawhide, feature page complete.
18:07:42 <notting> +1, sounds good
18:07:47 <nirik> +1, sounds good to me.
18:07:49 <cwickert> +1, looks good
18:07:50 <dgilmore> +1 from me
18:07:52 <skvidal> +1
18:08:09 <nirik> #agreed Feature is approved.
18:08:15 <nirik> #topic #304 Feature: KDE44 ( https://fedoraproject.org/wiki/Features/KDE44 )
18:08:19 <nirik> .fesco 304
18:08:20 <zodbot> nirik: #304 (Feature: KDE44 ( https://fedoraproject.org/wiki/Features/KDE44 )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/304
18:08:30 <notting> ack
18:08:49 <Kevin_Kofler> +1, likewise (well, 4.4.0 is not out yet so we have 4.3.90 which is a prerelease).
18:09:12 <nirik> +1 here. Is there any kind of global changelog/changes you can point to for the release notes? instead of just "lots of changes" ?
18:09:25 <Kevin_Kofler> There will be one in the 4.4.0 release announcement.
18:09:36 <skvidal> this is just really for the release notes, right?
18:09:40 <Kevin_Kofler> But there have been some in RC announcements or such already, I'll see if I can add a link.
18:09:51 <pjones> skvidal: looks that way
18:09:52 <nirik> Kevin_Kofler: cool.
18:09:58 <cwickert> Kevin_Kofler: it there a contingency Plan?
18:10:04 <Kevin_Kofler> It's not needed.
18:10:18 <Kevin_Kofler> See https://fedoraproject.org/wiki/Features/KDE44#Contingency_Plan
18:10:39 <cwickert> I did look at this, but it's not convincing to me
18:10:45 <Kevin_Kofler> If 4.4.0 really isn't ready we'll just ship 4.3.90 or whatever, but it looks like there's plenty of time to get probably even 4.4.2 in.
18:11:14 <cwickert> I don't like the idea of shipping a prerelease, btu I'm not a KDE user, so I don't know how good their prereleases are
18:11:23 <Kevin_Kofler> We're only at alpha.
18:11:38 <Kevin_Kofler> Trust me, we will get at least 4.4.0 in, most likely 4.4.2 or 4.4.3.
18:11:51 <jreznik_mobile> kde release schedule is clear and we have lot of time
18:11:52 <dgilmore> +1  kde 4.4 is coming along nicely
18:12:03 <jreznik_mobile> they deliver mostly on time
18:12:03 <Kevin_Kofler> http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule
18:12:06 * dgilmore has rawhide on his laptop and desktop
18:12:24 * pjones too.
18:12:45 <Oxf13> "we're only at alpha"; alpha is feature freeze, anything after alpha should be bugfixes
18:12:52 <Oxf13> does that mesh with KDE's schedule?
18:12:57 <Kevin_Kofler> RC to final is bugfixes.
18:13:03 <Kevin_Kofler> KDE 4.4 is already feature-frozen.
18:13:10 <Oxf13> ok.
18:13:14 <Kevin_Kofler> Hard feature freeze was on Nov 25.
18:13:22 <Oxf13> I just get twitchy when somebody says "we're only at alpha" (:
18:14:05 <Kevin_Kofler> The final 4.4.0 should be on Feb 9, so it might even make it into the alpha.
18:14:05 <cwickert> ok then, +1 from me
18:14:17 <Kevin_Kofler> If not, we'll have RC2 (release scheduled for Jan 20).
18:14:34 * nirik notes we are at 5 if notting's 'ack' was a +1. ;)
18:14:39 <notting> it was
18:14:43 * Oxf13 laughs at planned "release candidate"s greater than 1
18:14:44 <cwickert> Kevin_Kofler: maybe you should link that schedule from the feature page
18:15:01 <Oxf13> how can it be a 'release candidate' if you're not planning on being able to release it?
18:15:29 <notting> ... is that fesco's concern?
18:15:34 <skvidal> notting: +1
18:15:35 <pjones> can we not get into the epistemology of the term "release candidate"?
18:15:39 <Kevin_Kofler> Better than our Alpha / Beta naming which puts the feature freeze at alpha.
18:15:45 <Kevin_Kofler> Everyone thinks that's far away from release.
18:15:51 <wwoods> They're wrong.
18:15:53 <skvidal> okie doke
18:15:55 <skvidal> let's stop
18:16:00 <skvidal> it's been approved
18:16:02 <skvidal> next item
18:16:05 <skvidal> b/c I would like to go to lunch
18:16:11 <Kevin_Kofler> KDE's Beta/RC makes much more sense to me, as did our old Beta/Preview.
18:16:13 <nirik> #agreed Feature has been approved.
18:16:14 <jreznik_mobile> rc2 is only for worst cases
18:16:26 <nirik> #topic #305 Feature: Sugar 0.88 ( https://fedoraproject.org/wiki/Features/Sugar_0.88 )
18:16:30 <nirik> .fesco 305
18:16:31 <zodbot> nirik: #305 (Feature: Sugar 0.88 ( https://fedoraproject.org/wiki/Features/Sugar_0.88 )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/305
18:16:31 <Kevin_Kofler> KDE did drop their alpha releases just like we did (for our old alpha).
18:16:45 <sdziallas> (I'm here, just in case)
18:17:16 <notting> +1, sounds good.
18:17:31 <nirik> +1 here as well. Is there any upstream schedule for this release? or ?
18:17:43 <sdziallas> nirik: sure, let me get you a link.
18:17:54 <sdziallas> nirik: http://wiki.sugarlabs.org/go/0.88/Roadmap
18:17:54 <nirik> sdziallas: might again be good to add to the feature page.
18:18:22 <skvidal> +1
18:18:25 * nirik chuckles at the release code name.
18:18:25 <sdziallas> nirik: will do, sure!
18:18:58 * nirik waits for more votes.
18:19:02 <cwickert> +1
18:19:23 <Kevin_Kofler> +1 to this one too, also already in and with a complete feature page.
18:19:41 <nirik> #agreed This Feature is approved
18:19:43 <Kevin_Kofler> The schedule is a bit tighter than KDE's, but it should make it. Feature freeze is before ours.
18:19:46 <nirik> #topic #306 Feature: Xfce48 ( https://fedoraproject.org/wiki/Features/Xfce48 )
18:19:50 <nirik> .fesco 306
18:19:51 <zodbot> nirik: #306 (Feature: Xfce48 ( https://fedoraproject.org/wiki/Features/Xfce48 )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/306
18:20:01 <skvidal> sdziallas: next release name it "and Spice"
18:20:28 <sdziallas> skvidal: lol :)
18:20:38 <notting> skvidal: sucrose, glucose, fructose, high fructose...
18:20:45 <skvidal> notting: diabetes
18:20:53 <notting> and just hope the XOs don't become lactose intolerant
18:20:55 <skvidal> notting: natural progression, after all
18:21:05 <skvidal> notting: lactose?
18:21:07 <nirik> anyhow, I am +1 for this one, but I am sadly doubting we will make it in time...
18:21:10 <notting> nirik: +1 for new xfce
18:21:16 <cwickert> ok, the problem with Xfce 4.8 is the schedule
18:21:21 <nirik> the schedule is really tight.
18:21:22 <cwickert> it is very tight
18:21:31 <nirik> and upstream has a history of slipping.
18:21:41 <notting> but you have a contingency plan
18:21:45 <cwickert> but this time they have a release manager
18:21:48 <notting> as long as you're prepared to execute it
18:22:00 * cwickert talked to Jannis, the release manager and he said they will be on time
18:22:01 <nirik> yep. If we can't make it this cycle we will be ready for next.
18:22:11 * nirik crosses his fingers that this is the case.
18:22:27 <Kevin_Kofler> +1 too, some nervousness about schedule, but OK.
18:22:41 <Oxf13> cwickert: how many times have I said we'd be on time?  (:
18:22:53 <cwickert> ;)
18:22:56 <Kevin_Kofler> Can you ship a beta if needed or would you rather revert everything?
18:23:03 <cwickert> good question
18:23:07 <nirik> Kevin_Kofler: depends on where it is I think.
18:23:07 <dgilmore> nirik: when is upstream feature freeze?
18:23:17 <cwickert> dgilmore: all on the feature page
18:23:25 <Kevin_Kofler> dgilmore: Feb 9.
18:23:27 <nirik> I would prefer to only land the new stuff if we are pretty sure that it final will make it.
18:23:30 <cwickert> https://fedoraproject.org/wiki/Features/Xfce48#Detailed_Description
18:23:36 <Kevin_Kofler> Sugar's in on Feb 1, so not much better there.
18:23:57 <cwickert> Xfce 4.8 will help us to get rid of hal
18:24:05 <cwickert> +1 for me (of course)
18:24:05 <nirik> cwickert: yeah.
18:24:10 <Kevin_Kofler> cwickert: No way!
18:24:12 <Kevin_Kofler> KDE still needs HAL.
18:24:29 <nirik> Kevin_Kofler: Xfce still does somewhat too... there are still things, it just reduces it.
18:24:44 <cwickert> Kevin_Kofler: Xfce too, but not the core comonents. I'm not proposing to remove hal from the repos
18:24:46 <dgilmore> nirik: im +1  if we keep it in dist-f13-xfce until its ready
18:24:46 <Kevin_Kofler> nirik: Well, I think you'll have to land it before Alpha.
18:25:01 <Kevin_Kofler> dgilmore: It should go into the alpha so it gets testing.
18:25:09 <Kevin_Kofler> Even if it's alpha itself.
18:25:09 <nirik> Kevin_Kofler: yep.
18:25:27 <nirik> Kevin_Kofler: but we should have a better idea right before that if it's going to be on time... ie, if it's already slipped or not.
18:25:41 <nirik> ok, I think thats +5.
18:25:57 <Kevin_Kofler> Actually, Xfce's feature freeze is on Feb 1 (pre1), not Feb 9 as I wrote before, I misread the schedule.
18:26:02 <Kevin_Kofler> So it's the same as for Sugar.
18:26:13 <Kevin_Kofler> And the final release is only 2 weeks after Sugar.
18:26:18 <Kevin_Kofler> So they're both pretty much in the same boat.
18:26:26 * nirik nods.
18:26:32 <nirik> #agreed Feature is approved.
18:26:43 <nirik> #topic Open Floor
18:26:50 <nirik> Anyone have anything for open floor?
18:27:05 <gholms|work> I'm thinking of bringing up a discussion on the devel list to brainstorm some ideas on how to deal with what seems to be a lack of sufficient package reviewing.  The hope is to come up with a proposal that can actually do something about it.  Do any of you have any thoughts or recollections that would be useful before I go to do so?
18:27:23 <notting> 'go for it'?
18:27:27 <che> gholms|work, it is called qa ;)
18:27:53 <che> gholms|work, id be all for having a requirement on "trying the package out"
18:28:21 <che> gholms|work, seriously i have seen hilarious things... even packages with missing runtime requirements (i mean missing as in... not even in the distro)
18:28:34 <Kevin_Kofler> Indeed.
18:28:37 <notting> gholms|work: is this 'issues with existing reviews', or 'not enough people to do reviews'
18:28:42 <Oxf13> I think he meant not enough people doing reviews
18:28:48 <gholms|work> notting: The latter.
18:28:48 <Oxf13> not that the reviews being done are crap
18:28:59 <gholms|work> Reviewer participation has been rather low.
18:29:03 <Oxf13> which unfortunately it seems the former leads to the latter
18:29:20 <Oxf13> or trying to fix the former leads to the latter that is
18:29:20 <Kevin_Kofler> The problem is, the more we do about the first problem, the more we encourage the second and the other way round.
18:29:23 <gholms|work> In the past week alone we've seen 72 new requests, 28 of which have no comments at all.
18:29:35 <skvidal> we have 72 new pkg requests?
18:29:36 <skvidal> really?
18:29:39 <Oxf13> Kevin_Kofler: exactly what I was saying (:
18:29:46 <Oxf13> skvidal: and many more on the way.
18:29:49 <nirik> gholms|work: one suggestion was to require a scratch build for each review... confirm it builds at least.
18:29:50 <skvidal> what's the avg?
18:29:59 <skvidal> Oxf13: ?
18:30:17 <Oxf13> skvidal: we need to package up gwt, which is a snowball of java packages
18:30:21 <nirik> another suggestion was to ask everyone who submits a package to do a review. (of course without enforcing that doesn't help any)
18:30:35 <gholms|work> nirik: Since that's a guideline anyway that wouldn't be an unreasonable thing to ask for.
18:30:37 <Kevin_Kofler> It's particularly hard for new packagers, they need a sponsor (so a smaller set of potential reviewers) and they don't "know the right people" yet.
18:30:37 <nirik> also, there are eleventy million dogtag packages. ;)
18:31:06 <Kevin_Kofler> The problem is, forcing people to do reviews leads to crap reviews.
18:31:10 <dgilmore> nirik: the first wave of dogtag is reviewed
18:31:10 <nirik> another suggestion I had was to try and get rid of the needsponsor backlog and get those people reviewing.
18:31:15 <Kevin_Kofler> And banning crap reviews leads to not enough reviews.
18:31:42 <nirik> tibbs suggested the other day that we close new reviews until we deal with the backlog.
18:31:59 <Kevin_Kofler> Not feasible.
18:32:03 <nirik> it's a hard problem for sure.
18:32:24 <Kevin_Kofler> It'll discourage people who are active now for the benefit of "clearing a backlog" where submitters might not even be interested anymore.
18:32:33 <gholms|work> I, for one, could certainly help out with reviewing if I was sponsored.  I can't speak for everyone else who is asking for sponsorship, though.
18:32:45 <Kevin_Kofler> And it'll block things when e.g. KDE needs a new dependency.
18:32:51 <Kevin_Kofler> We can't just ban new reviews.
18:32:57 <Kevin_Kofler> They're all filed for a reason.
18:33:01 <Oxf13> and there is taht suite of software that is getting turned into something like 400 subpackages
18:33:05 <Oxf13> I can't recall thename just yet
18:33:37 <Kevin_Kofler> You mean TeXLive2009 and its 4000 packages?
18:33:38 <dgilmore> tetex?
18:33:40 <Oxf13> ah yes
18:33:44 <Oxf13> texlive
18:33:59 <Kevin_Kofler> They're all autogenerated.
18:34:00 <tibbs> sure it's perfectly feasible.
18:34:09 <tibbs> It's even trivial to do.
18:34:14 <tibbs> But it's probably not wanted.
18:34:16 <Kevin_Kofler> So really someone should review one of the specfiles and then mass-change them all to APPROVED.
18:34:28 * nirik shakes his head no at that.
18:34:33 <tibbs> Certainly not.
18:34:46 <tibbs> Or do you think that all of the code in there would, say, have the same license?
18:34:49 <Oxf13> I shake my head no to adding 4K packages worth of metadata to our compose processes :/
18:34:52 <Kevin_Kofler> How else do you review 4000 autogenerated specfiles?
18:35:11 <nirik> we have drifted into the weeds here. Can we go back to the topic?
18:35:16 <tibbs> The hard way.
18:35:16 <gholms|work> Would stricter limits on response time help at all?
18:35:24 <tibbs> gholms|work: Yes.
18:35:30 <Kevin_Kofler> gholms|work: If you want crap reviews, sure. ;-)
18:35:46 <gholms|work> What we get now is that if you're in the clique, your stuff gets reviewed, which I think is actually a worse situation than random stuff not being reviewed.
18:35:55 <Kevin_Kofler> And reviewing 4000 specfiles by hand is just not possible.
18:36:03 * nirik thinks that sounds like a quote of something tibbs said the other day. ;)
18:36:07 <tibbs> It is.
18:36:11 <gholms|work> nirik: It is.
18:36:12 <Kevin_Kofler> Then do it. :-p
18:36:30 <nirik> time limits on reporter wouldn't lower quality of reviews.
18:36:42 <nirik> they have the need/desire to get the package in...
18:36:48 <tibbs> They would certainly lower the amount of triage work needing to be done.
18:37:06 <Kevin_Kofler> gholms|work: That's also true, indeed.
18:37:27 <nirik> gholms|work: in any case, I would suggest brainstorming more suggestions over in #fedora-devel and then posting to the list for more/feedback.
18:37:31 <Kevin_Kofler> Package some KDE software, come nagging us on #fedora-kde and rdieter or myself will sponsor you. :-p
18:37:38 <nirik> then bring a proposal to us when you have one from the feedback?
18:37:45 <gholms|work> Works for me.
18:38:47 <skvidal> any other business?
18:38:57 * mdomsch raises hand
18:39:02 <nirik> mdomsch: go ahead
18:39:16 <mdomsch> is anyone going to look at the list of orphaned packages and decide what to pitch before alpha?
18:39:22 <skvidal> mdomsch: all of them
18:39:24 <mdomsch> (I started the thread on FTBFS)
18:39:24 <skvidal> pitch them all
18:39:45 <mdomsch> I hope the FTBFS list can be reviewed next week after some get fixed up or dropped
18:39:50 <pjones> I'm with seth here.
18:39:52 <Kevin_Kofler> Officially orphaned ones maybe, for the FTBFS stuff, please give us a week to fix them.
18:39:59 <Kevin_Kofler> We can revisit on Tuesday.
18:39:59 <cwickert> mdomsch: recordmydesktop was just fixed
18:40:04 <mdomsch> Kevin_Kofler, sure
18:40:10 <Oxf13> being fixed isn't enough to keep them in
18:40:18 <Oxf13> if they aren't being worked on by the maintainers, they need to be orphaned
18:40:20 <nirik> I would like to propose that even fixed they should be dropped if still orphaned.
18:40:21 <mdomsch> I wanted to be sure _someone_ was going to take on dealing with the long orphan list
18:40:31 <cwickert> +1 to nirik
18:40:33 <nirik> or still maintained by the same unresponsive people.
18:40:39 <Oxf13> I would consider anything that hasn't been buildable for that long to be orphaned
18:40:45 <Oxf13> regardless of who owns it
18:40:53 * skvidal is in favor of killing orphans
18:41:00 <Oxf13> and if nobody picks them up by feature freeze, we kill them
18:41:05 <Kevin_Kofler> If the package works, fixing the rebuild isn't a high priority for some maintainers.
18:41:08 <skvidal> I think it is a modest proposal
18:41:08 * notting notes that statement of skvidal's for future use
18:41:08 <Oxf13> just like we do with any other orphan at that point
18:41:12 <Kevin_Kofler> Plus, it's often hard for them.
18:41:14 <cwickert> Oxf13: lots of FTBFS get fixed by proven packages, but that doesn't mean that they are actually maintained
18:41:28 <cwickert> so IMO drop them all
18:41:29 <Oxf13> cwickert: right, which makes it harder to detect these things
18:41:34 <Oxf13> but we have mdomsch's original list
18:41:34 <pjones> skvidal: Oxf13: you two are getting way too in to this jonathan swift joke you're making.
18:41:48 <Oxf13> pardon?
18:41:49 <skvidal> pjones: I'm glad someone got it
18:41:57 <pjones> oh, maybe Oxf13 was playing along innocently.
18:42:01 <Kevin_Kofler> cwickert: -1
18:42:05 <Oxf13> I was.
18:42:06 <skvidal> pjones: every joke needs its straightman
18:42:14 <nirik> right. So of the ones on mdomsch's list, we should drop them unless: someone else takes over maintaining and they get the package building ok.
18:42:19 <Kevin_Kofler> I don't think we should drop working packages which aren't even officially orphaned, especially on such short notice.
18:42:21 <Oxf13> Kevin_Kofler: I'm strongly against keeping packages that don't have competent maintainership
18:42:22 <skvidal> Oxf13: google "A modest Proposal"
18:42:27 <notting> pjones: jonathan? is that taylor's brother?
18:42:37 <Oxf13> and ignoring FTBFS for this long doesn't strike me as competent maintainership
18:42:40 <pjones> notting: you're a very strange man, bill.
18:42:48 <Kevin_Kofler> If anything, we should orphan them now, ask for people to pick them up and drop them for F14 if they're still orphaned by then.
18:42:49 <skvidal> notting: burn, bitch, burn
18:43:02 <nirik> Kevin_Kofler: that would be a way to do it too.
18:43:06 <Oxf13> forced orphaning, allowance to be picked back up, then killing what didn't get picked up seems the right way forward.
18:43:17 <Oxf13> drop them for F13, not 14
18:43:22 <cwickert> +1 Oxf13
18:43:23 <mdomsch> Kevin_Kofler, it's not a new notice; they've had a year to deal with them
18:43:29 * notting is +1 to Oxf13's proposal
18:43:36 <mdomsch> and repeated warnings in each bugzilla
18:43:48 <Kevin_Kofler> mdomsch: But they assumed the official maintainers were going to fix them, like most other FTBFS bugs.
18:43:48 <cwickert> mdomsch: a year??? this is incredible
18:43:54 <skvidal> as long as there is a step where we boil and eat the orphans., yes
18:43:56 <notting> althogh we may want to cross-reference onces that were fixed by the maintainers today
18:43:57 <nirik> yeah, +1 here to that.
18:44:00 <skvidal> cwickert: 2 releases
18:44:02 <Kevin_Kofler> There's no way I can fix all FTBFS issues.
18:44:08 <Oxf13> Kevin_Kofler: you aren't expected to
18:44:09 <Kevin_Kofler> But I can fix 27 ones like those in that list.
18:44:10 <skvidal> Kevin_Kofler: then don't!
18:44:17 <Oxf13> Kevin_Kofler: the maintainers are expected to, or ask for help
18:44:22 <skvidal> now
18:44:23 <Oxf13> which didn't happen
18:44:25 <skvidal> one thing to bring up here
18:44:25 <nirik> notting: if we could mail those people that fixed them and note that the package is available now...
18:44:26 <mdomsch> but to be fair - I see 2 lists: 1) those that can't be fixed - nuke them.  2) all orphans
18:44:27 <skvidal> if we orphan them
18:44:34 <cwickert> Kevin_Kofler: the question is not if someone can fix them but if someone can maintain them
18:44:34 <skvidal> we need to nuke them from people's systems on upgrades
18:44:40 <Kevin_Kofler> I think we should have an official task force of provenpackagers fixing this sort of things.
18:44:43 <Oxf13> this old problem.
18:44:54 <Oxf13> Kevin_Kofler: that's all well and good but that papers over the problem
18:44:56 <nirik> skvidal: can-o-worms. ;) Come up with a proposal and bring it to us?
18:44:56 <Kevin_Kofler> Not just me running around (and alexlan for broken deps sometimes).
18:44:59 <Oxf13> of improper maintainership
18:45:02 <skvidal> nirik: I did.
18:45:06 <skvidal> nirik: I'll do it again
18:45:16 <skvidal> Oxf13: how do you like a big obsoletes list in fedora-release? :)
18:45:31 <Oxf13> not very much
18:45:35 <pjones> *vomit*
18:45:42 <notting> skvidal: we odn't necessarily do that to other orphans
18:45:44 <Oxf13> means bumping fedora-release should the package ever be revived
18:45:47 <skvidal> notting: and we should
18:45:51 <pjones> skvidal: that's pretty ugly when one of the packages comes back in the next release.
18:45:59 <nirik> proposed (from Oxf13): all packages on mdomsch's list are orphaned now, we note that they are to the list. If someone doesn't pcik them up and make them work, they get dropped in the usual orphan way in the cycle.
18:46:00 <pjones> (or worse, in an update)
18:46:00 <skvidal> notting: mainly b/c I'm still picking gnome-blog out of people's frelling rpmdbs
18:46:02 <Oxf13> how about a big static list in anaconda?
18:46:04 * Oxf13 ducks
18:46:11 <pjones> Oxf13: Die in a fire please ;)
18:46:21 <skvidal> pjones: worse is when it kills the update process
18:46:42 <skvidal> pjones: gnome-blog is the recurring example b/c it requires python 2.5 - from fedora 7
18:46:42 <nirik> Do we all agree to that proposal?
18:46:48 <skvidal> nirik: I do
18:46:53 <pjones> skvidal: yeah, that's pretty unfortunate
18:46:55 <Kevin_Kofler> Then the best solution is: don't remove the package (if at all possible).
18:47:10 * nirik notes we talked about this back in the fedora-extras days. It's been a topic that long.
18:47:11 <Kevin_Kofler> That's why I'm saying we should try to fix the build if possible rather than removing stuff.
18:47:12 <skvidal> pjones: roughly 30 tickets opened at yum's trac about that
18:47:15 <pjones> +1 on the proposal not as stated, without the removal-from-systems bits.
18:47:25 <pjones> skvidal: yes, users do file bugs.
18:47:29 <nirik> Kevin_Kofler: having a package that "builds, ship it" in the distro, with no one maintaining it is bad.
18:47:39 <skvidal> the removal from system bits are not necessary
18:47:42 <skvidal> I'm just grumbly
18:47:46 <skvidal> I am in favor of forced orphaning
18:47:51 <skvidal> as Oxf13 suggested
18:47:51 <nirik> +1 on the proposal here.
18:48:03 <skvidal> partially I'm grumbly b/c I wanna go get lunch :)
18:48:08 <nirik> Kevin_Kofler: if no one cares to maintain it, does it need to be shipped by fedora?
18:48:17 <Kevin_Kofler> skvidal: But we need to give people some time to pick them up before removing them.
18:48:19 <Oxf13> skvidal: I agree that not being able to clean a user's system out of dead packages is a problem
18:48:26 <Oxf13> skvidal: I just don't like the solutions so far
18:48:27 * notting is +1 to Oxf13's proposal. or did i already say that?
18:48:31 <Kevin_Kofler> Not necessarily a full release cycle, but not something like 24 hours or less!
18:48:31 <dgilmore> if its unmaintained its not fair to keep it around
18:48:34 <skvidal> do we have 5?
18:48:35 <pjones> nirik: people do use things that are effectively unmaintained (see also: hardlink++)
18:48:36 <Oxf13> Kevin_Kofler: they have time, weeks
18:48:40 <dgilmore> +1
18:48:50 <nirik> yes.
18:49:07 <cwickert> +1 to Oxf13
18:49:09 <skvidal> Oxf13: then a obsoletes pkg that is not fedora-release but is installed by default (but required by nothing)
18:49:13 <Kevin_Kofler> Oxf13: The solution to the cleaning up problem is, ship the stuff as long as possible.
18:49:16 <nirik> mdomsch: can you work with whoever to do this / mail the list?
18:49:20 <skvidal> Kevin_Kofler: dear god, no
18:49:30 <Oxf13> skvidal: yeah, that seems a bit more reasonable
18:49:32 <skvidal> Kevin_Kofler: that doesn't solve anything - b/c things are orphaned and never picked back up
18:49:38 <Oxf13> Kevin_Kofler: I respectfully disagree.
18:49:39 <cwickert> skvidal: let's call it "fedora-update" or alike
18:49:41 <skvidal> Oxf13: I'll work on a quick draft for next meeting
18:49:43 <Kevin_Kofler> Ideally, I'd like a model where packages are not "owned" at all.
18:49:50 <Kevin_Kofler> If somebody wants to update a package, they just do it.
18:49:51 <skvidal> cwickert: I was going to call it Ihatecrap
18:49:52 <mdomsch> who can forcibly orphan a package? I can't.
18:50:01 <skvidal> cwickert: but your name might not be a bad choice :)
18:50:01 <cwickert> skvidal: even better!
18:50:02 <Oxf13> when nobody owns a package, nobody is responsible for fixing the package
18:50:02 <nirik> #agreed packages that have FTBFS for years will be orphaned and removed in the normal orphan removal process.
18:50:11 <nirik> mdomsch: abadger1999 could probibly do it...
18:50:14 <Oxf13> it becomes somebody else's problem.
18:50:18 <skvidal> cwickert: fedora-mp - modest proposal :)
18:50:32 <Kevin_Kofler> That way we solve the problem of packages not getting updated, whoever cares can just push a one-time update.
18:50:37 <skvidal> cwickert: I think I do require a jonathan swift reference in there
18:50:47 <Oxf13> Kevin_Kofler: the latter half of your desire, anybody can update anything anytime can be done without sacrificing an entity that is ultimately responsible for the package.
18:50:47 <abadger1999> mdomsch: Anyone in cvsadmin
18:50:55 <abadger1999> .members cvsadmin
18:50:56 <zodbot> abadger1999: Members of cvsadmin: ausil huzaifas @jkeating jwboyer kevin lmacken mikeb @mmcgrath @notting petersen spot tibbs toshio @wtogami
18:50:58 <mdomsch> so we need 2 steps - 1) orphan them all; 2) block anything not un-orphaned at alpha freeze
18:51:02 <nirik> mdomsch: then I can do it. See me after the meeting. ;)
18:51:08 <Oxf13> mdomsch: 2 happens naturally
18:51:18 <Oxf13> mdomsch: we purge orphans near feature freeze each release cycle
18:51:29 <Oxf13> the orphans created in 1 would be swept up at that time
18:51:42 <mdomsch> Oxf13, ah, good; I didn't realize it was SOP
18:51:43 <Oxf13> but we better orphan then ASAP to give maximum amount of time to be picked up
18:51:46 <nirik> anything further today from anyone?
18:51:52 <Oxf13> mdomsch: I think I need to add it to the list of tickets
18:52:17 <Kevin_Kofler> And for the record, a 0 vote from me (it's tolerable as people can pick the packages up, but I'd rather just have let people fix the packages and be done with it).
18:53:04 <Southern_Gentlem> Kevin_Kofler,  so are you willing to pick those packages up yourself
18:53:06 <Oxf13> Kevin_Kofler: this is a lesson learned over and over.  Look at what OLPC has done, when kids 'owned' the laptops as opposed to community "everybody can use it" workstations
18:53:13 <nirik> as a side note I would like to see a group that monitors orphan bugs, but thats another proposal for another time.
18:53:22 <Oxf13> people actually treated the machines far better and kept much better care of them then when the machines were "somebody elses problem"
18:53:33 <Oxf13> ownership is a very good thing
18:53:44 <Oxf13> non-ownership very quickly leads to problems
18:53:58 <nirik> as well as frustrated users with no one answering their bugs.
18:53:58 <pjones> just a quick side proposal - I'd like to propose that I be added to provenpackagers.  any takes? ;)
18:54:14 <Oxf13> mdomsch: ah, we do have it listed in the tickets: https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets  #6 in the Alpha list
18:54:24 <pjones> (I'm already on one of the secondary arch acls, so it's /effectively/ already the case)
18:54:32 <nirik> pjones: I thought we had something a while back of adding fesco folks to there... but not sure.
18:54:33 <Oxf13> yeah, I'd +1 pjones
18:54:34 <Kevin_Kofler> Southern_Gentlem: I can't permanently maintain 10000 packages, I can fix the occasional FTBFS or broken dependency which doesn't get fixed by the official maintainer.
18:55:07 <Kevin_Kofler> Ultimately, I could fix a lot of stuff, but I don't want to be ultimately responsible for hundreds of packages.
18:55:19 <Kevin_Kofler> I only have so much time.
18:55:42 <che> Kevin_Kofler, it makes more sense to focus on less things and maintain them properly.
18:55:43 <mdomsch> quick question: prctl is on the FTBFS list; but it is ExclusiveArch ia64
18:55:51 <skvidal> mdomsch: diaf?
18:55:57 <Oxf13> ia64 is dead dead dead
18:56:04 <nirik> pjones: we can add it next week? or I can find the policy we decided a while back that will just let us grant it. ;)
18:56:20 * nirik will close this meeting out in a few here.
18:56:40 <pjones> nirik: sure, whatever ;)
18:56:44 <Kevin_Kofler> che: Actually, I think making Fedora as a whole work well is much more useful than maintaining 1 or 2 individual packages.
18:57:00 <Oxf13> Kevin_Kofler: the two are not mutually exclusive
18:57:10 <Kevin_Kofler> But sadly, everyone else believes in the ownership model where commits to stuff you're not officially responsible for are the exception rather than the rule.
18:57:15 <Oxf13> Kevin_Kofler: you can be ultimately responsible for a few packages, but provide services to many more as needed
18:57:23 <nirik> Kevin_Kofler: who handles bugs for these drive by packages?
18:57:26 <che> Kevin_Kofler, well thats why i am not maintaining any packages at all anymore...
18:57:31 <che> Kevin_Kofler, there is enough work with existing stuff ;)
18:57:32 <Oxf13> Kevin_Kofler: "everyone else believes" is a rather sweeping statement to make.
18:57:38 <Kevin_Kofler> Oxf13: I want to do that, but they get orphaned under me…
18:57:49 <nirik> who updates them when there are security issues? who updates them when their are new features?
18:57:54 <Oxf13> Kevin_Kofler: because every package ultimately needs a person responsible for it
18:58:01 <Oxf13> Kevin_Kofler: not for the 5 minutes you're willing to give it
18:58:12 <Kevin_Kofler> And if I want them to stay, even if I fix them, I need to take responsibility for them permanently. That's 27 packages now, 100 the next time etc. and it quickly blows out of proportion.
18:58:19 <Oxf13> if there isn't anybody willing to be responsible for it, it has no room being carried forward.
18:58:27 * nirik ends the meeting.
18:58:30 <nirik> Thanks for coming everyone!
18:58:31 <Oxf13> thanks nirik
18:58:34 <nirik> #endmeeting