=================================== #fedora-meeting: FESCO (2010-02-09) ===================================

Meeting started by nirik at 20:02:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-02-09/fesco.2010-02-09-...

Meeting summary --------------- * init process (nirik, 20:02:07)

* #314 Wordpress bundles libraries (nirik, 20:04:12) * AGREED: will defer this topic until after FPC has discussed the rest of the issues. (nirik, 20:06:01)

* #336 Fedora Packaging Committee items for ratification (2009-02-03) (nirik, 20:06:12)

* Packaging: SRPM Buildtime macros - https://fedoraproject.org/wiki/SRPM_Buildtime_macros (nirik, 20:06:40) * AGREED: Packaging change is approved. (nirik, 20:08:34)

* Packaging: Emphasize correct SF.net SourceURL: https://fedoraproject.org/wiki/PackagingDrafts/SourceURL_sourceforge_downloa... (nirik, 20:08:41) * AGREED: Packaging change is approved. (nirik, 20:10:39)

* Packaging: Updated Python Guidelines https://fedoraproject.org/wiki/PackagingDrafts/Python3 (nirik, 20:11:58) * AGREED: Packaging change is approved. (nirik, 20:19:57)

* #297 Please consider the idea of a security (privilege escalation) policy (nirik, 20:20:45) * LINK: https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... (adamw, 20:21:46) * AGREED: adamw will add revisions and post to devel list. Will revisit next week (nirik, 20:38:53)

* #337 Zarafa - https://fedoraproject.org/wiki/Features/Zarafa (nirik, 20:39:20) * AGREED: Feature is approved. (nirik, 20:51:07)

* #275 Propose a soft-path via co-maintainer status to becoming sponsored (nirik, 20:51:27) * AGREED: abadger1999 will draft a new policy for consideration next week (nirik, 21:35:51)

* #338: Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert its implementation from pre-branch Rawhide (nirik, 21:35:59) * LINK: https://fedoraproject.org/wiki/DSOLinkBugs is the list (nirik, 21:38:04) * AGREED: This proposal is rejected. The feature will stay in place. (nirik, 21:52:36) * Please announce feature changes that impact other packages on fedora-devel-announce to reach the most maintainers (nirik, 21:54:15) * devel-announce@lists.fedoraproject.org (notting, 21:55:26)

* Helpers pool (nirik, 21:58:55)

* Open Floor (nirik, 22:04:00)

Meeting ended at 22:05:53 UTC. -- 20:02:07 <nirik> #startmeeting FESCO (2010-02-09) 20:02:07 <zodbot> Meeting started Tue Feb 9 20:02:07 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:07 <nirik> #meetingname fesco 20:02:07 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:02:07 <nirik> #topic init process 20:02:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:02:11 <zodbot> The meeting name has been set to 'fesco' 20:02:12 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:02:17 <nirik> Who all is around for the FESCo meeting? 20:02:24 * skvidal is 20:02:25 <Kevin_Kofler> Present. 20:02:25 * notting is here 20:02:36 * jds2001 sits in the cheap seats 20:02:45 <adamw> here for my item 20:03:09 * cwickert is here 20:03:19 * pjones is here 20:03:20 <charley> here 20:03:40 * Oxf13 is here for a later topic about sponsorship 20:04:07 <nirik> ok. I think we have quorum, so lets go ahead and get started... 20:04:12 <nirik> #topic #314 Wordpress bundles libraries 20:04:17 <nirik> .fesco 314 20:04:18 <zodbot> nirik: #314 (Wordpress bundles libraries) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/314 20:04:31 <nirik> This is still going to be discussed at an upcoming packaging meeting... 20:04:43 * dgilmore is here 20:04:49 <nirik> shall we defer until then? or would folks like to weigh in on the part that packaging has discussed? 20:04:59 * notting is fine with deferring 20:05:00 <adamw> (someone please ping me when privesc topic comes up, working on something else till then) 20:05:04 <dgilmore> nirik: i think we should wait 20:05:13 <nirik> adamw: will do. 20:05:18 <Kevin_Kofler> I'm for deferring until FPC is done discussing this. 20:05:31 <mjg59> Hi 20:05:41 <nirik> I'm fine with waiting a bit more on this one as well. 20:05:44 <mjg59> Yes, deferral sounds fine 20:05:48 <pjones> yeah, I think that sounds fine. 20:06:01 <nirik> #agreed will defer this topic until after FPC has discussed the rest of the issues. 20:06:11 * abadger1999 notes that he failed to send out an agenda for a FPC meeting this week 20:06:12 <nirik> #topic #336 Fedora Packaging Committee items for ratification (2009-02-03) 20:06:18 <abadger1999> So it will be next week. 20:06:27 <nirik> so we have 3 items from FPC... lets do them one at a time. 20:06:31 <nirik> abadger1999: ok. 20:06:40 <nirik> #topic Packaging: SRPM Buildtime macros - https://fedoraproject.org/wiki/SRPM_Buildtime_macros 20:07:07 <Kevin_Kofler> +1, we tasked FPC to come up with this, they did. 20:07:19 * notting is fine with this. +1 20:07:23 <nirik> There has been some negative feedback from the fonts folks... 20:07:34 <mjg59> Unexpanded macros are pretty clearly a bug 20:07:38 <nirik> since the current standard fonts spec does this 20:07:47 <Kevin_Kofler> Then it needs to be fixed. 20:07:47 <skvidal> +1 20:07:52 <cwickert> +1 20:07:53 <abadger1999> nirik: Actually.. I checked the template and I don't think it does. 20:07:55 * dgilmore is +1 for the guidelines 20:08:02 <mjg59> So +1 to the guidelines 20:08:12 <nirik> abadger1999: ah, so it's old fonts that are using something else? 20:08:18 <Kevin_Kofler> Any font specs which do this now should get fixed in any case. 20:08:25 <nirik> anyhow, it passes. ;) 20:08:34 <nirik> #agreed Packaging change is approved. 20:08:41 <nirik> #topic Packaging: Emphasize correct SF.net SourceURL: https://fedoraproject.org/wiki/PackagingDrafts/SourceURL_sourceforge_downloa... 20:08:48 <abadger1999> nirik: I'm unclear.. I think that nim-nim is using what he thinks best but the template isn't updated to whatever he has in his head. 20:08:56 <ajax> (also here) 20:09:01 <mjg59> +1 for this 20:09:06 <nirik> this one seems trivial, +1 20:09:07 <notting> +1. although i'm not sure why this even needs to come here 20:09:15 <cwickert> +1 20:09:16 <Kevin_Kofler> +1 20:09:18 * dgilmore hates sourceforge urls. though mysqls are worse 20:09:30 <dgilmore> +1 for making them better 20:09:38 <Kevin_Kofler> notting: SF now uses some URLs with download.sourceforge.net, but they are indirect links with a different format. 20:09:41 * cwickert uses downloads everywhere 20:09:53 <nirik> yeah, it's a mess, but downloads usually works ok. 20:09:54 <Kevin_Kofler> downloads.sourceforge.net is the round-robin redirect. 20:09:59 <abadger1999> nirik: Oh, I'm wrong. The complex font template has the macro in a different place than the simple font template :-( 20:10:08 <cwickert> how about making the use of spectool mandatory? 20:10:13 <notting> Kevin_Kofler: no, i'm just not sure why we need to approve what is essentially a one-sentence addition to the guidelines 20:10:33 <Kevin_Kofler> abadger1999: Then please put onto the FPC agenda to fix the fonts template. :-) 20:10:39 <nirik> #agreed Packaging change is approved. 20:10:40 <abadger1999> Kevin_Kofler: Will do. 20:10:44 <mjg59> Yeah, this kind of simple and obvious thing really shouldn't need to go via fesco 20:10:46 <nirik> cwickert: as part of review? 20:11:01 <cwickert> yes, or in the update howto 20:11:18 <cwickert> I mean, as part of the review the sourceurl should be checked anyway 20:11:22 <Kevin_Kofler> notting, mjg59: It doesn't take long to approve this if we don't have to discuss this kind of objections. ;-) 20:11:38 <nirik> cwickert: yeah, I think we could just add it to the update howto... thats not in packaging space... 20:11:48 <Kevin_Kofler> Can we please move on to the next guideline? 20:11:51 <nirik> sure. 20:11:55 <cwickert> move please 20:11:58 <nirik> #topic Packaging: Updated Python Guidelines https://fedoraproject.org/wiki/PackagingDrafts/Python3 20:13:01 <nirik> I know abadger1999 and dmalcolm have worked long and hard on this. 20:13:07 <notting> mmm, long 20:13:08 <mjg59> I'm a little concerned about approving something that claims to be a draft 20:13:15 <cwickert> yes, and tomspur too 20:13:20 <ajax> well, they're all drafts until they're not 20:13:21 <dgilmore> I have one question about this all 20:13:23 <mjg59> Or is that header now just waiting for us? 20:13:24 <Kevin_Kofler> It will not be a draft once we approve it. 20:13:28 <mjg59> Ok, fine 20:13:29 <cwickert> however I dislike one thing 20:13:30 <nirik> mjg59: it's waiting for us. 20:13:40 <cwickert> the use of '%global with_python3 1' 20:13:42 <dgilmore> wat is the plan to remove 2.x at some point and how we will cope with that 20:13:54 <cwickert> shoudn't we use rpms bcond macro there? 20:13:57 <dgilmore> or do we see keeping 2.x forever 20:14:17 <dgilmore> cwickert: we can not pass macros in at build time 20:14:40 <abadger1999> dgilmore: That's more of a packaging question than a FPC question but dmalcolm and I don't see a way to decide when/if we should drop python2 at this time. 20:14:52 <abadger1999> The uptake of python3 at this point is only around 1%. 20:14:54 <cwickert> dgilmore, but in the head of the spec and this can be done with bcond too 20:14:59 <mjg59> When python2 can be dropped is obviously going to depend on the rate of upstream uptake 20:15:07 <nirik> I think we need to decide that down the road when "enough" things have moved. 20:15:11 <abadger1999> So we can't guess how far in te future it will be before python2 can be dropped. 20:15:17 <Kevin_Kofler> I guess Python 2 will have to stay for ~10 years. 20:15:29 <Kevin_Kofler> (looking at the GTK+ 2 and Qt 4 transitions) 20:15:31 <dgilmore> abadger1999: right. my main thought is we will have a crap load of python-foo and python3-foo packages 20:15:52 <dgilmore> we will need to obsolete the old ones at some point 20:16:36 <abadger1999> dgilmore: Correct. At present we are not planning on obsoleting the old stuff with python3 packages. If python2 goes away entirely, we'll just have a distro with python3-* packages instead of python-* packages at some point. 20:16:41 <dgilmore> cwickert: it still needs hardcoding in the spec 20:16:42 <mjg59> Sure, but I don't think we need to worry about that now 20:16:53 <pjones> well, it's safe to assume that zope will move to python2 in a couple of years. 20:16:58 <abadger1999> It'll be like any other package that is no longer maintained upstream that we retire. 20:17:12 <abadger1999> pjones: zope is currently on python2.6 like we are. 20:17:15 <dgilmore> abadger1999: ok 20:17:15 <nirik> pjones: then we can drop it at that point. ;) 20:17:20 <pjones> abadger1999: it was a joke ;) 20:17:28 <abadger1999> pjones: :-) 20:18:15 * nirik doesn't see anything obviously blocking, so +1 here... but I bet we will need to adjust and tweak this some as people start using it more. 20:18:20 <pjones> I think I need to spend a lot more time reading this draft before I can vote on it. 20:18:28 <Kevin_Kofler> +1 to the Python 3 guidelines from me 20:18:45 <pjones> but that said, +1 with the understanding that there's probably still going to be some change in this. 20:19:11 <notting> +1 to having guidelines. a quick read seems reasonable 20:19:12 <skvidal> I've been following what they've been working on for a while 20:19:13 <cwickert> I also think some tweaks are needed here and there, but so far it looks pretty well thought out 20:19:14 <skvidal> +1 20:19:14 <mjg59> +1 20:19:17 <cwickert> +1 from me 20:19:26 <pjones> in general, it seems to be in order; in specific, I can't comment on all of the specifics yet ;) 20:19:44 <dgilmore> pjones: same. its alot of info. but im +1 to the concept. and im sure we will hit snags needing adjusting 20:19:49 <ajax> yeah, +1 20:19:57 <nirik> #agreed Packaging change is approved. 20:20:30 * nirik thinks thats the first thing everyone has agreed on. ;) 20:20:38 <nirik> ok, moving along 20:20:45 <nirik> #topic #297 Please consider the idea of a security (privilege escalation) policy 20:20:49 <nirik> adamw: you around? 20:21:05 <pjones> I'm largely +1 to the idea of a security (privilege escalation) policy. 20:21:15 <pjones> is there one we should consider? 20:21:21 <adamw> yes 20:21:31 <pjones> is there a url to it? 20:21:39 <adamw> this came up a few weeks ago, and you asked me to go away and write one, so I did. :) 20:21:41 <adamw> yep, just a sec 20:21:46 <adamw> https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalati... 20:22:20 <ajax> it seems like a pretty reasonable policy, although (like all security policies) it probably needs equally reasonable people interpreting it 20:22:22 <pjones> adamw: I don't like the second statement in "Scope". 20:22:27 <adamw> this is initially based on the list in spot's blog post at http://spot.livejournal.com/312216.html , and has been through several rounds of revision first on test list (QA group) then on devel list 20:22:53 <Kevin_Kofler> +1, this policy looks good. 20:23:00 <adamw> pjones: how would you amend it? 20:23:21 * nirik provided feedback when it was on testing list, overall I think it's a good start so +1 here. 20:23:35 <cwickert> adamw, good work! 20:23:47 <adamw> in general i've tried to write the policy just to codify existing practice and allow for already planned further developments (i.e. what's coming with PolicyKit and 'administrative users'), it's not intended to prescribe any major changes to what we currently do. 20:23:54 <mjg59> There's a couple of nits with it 20:23:59 <pjones> adamw: well, it'd be nice if it allowed for some authentication other than "root authentication", which is something we explicitly /don't/ want. 20:24:03 <adamw> so if you see any bits where this isn't true, please note it :) 20:24:07 <mjg59> "Load or unload kernel modules (with the exception of automatic loading of appropriate modules for hotplugged hardware, managed via the module-init-tools system)" 20:24:19 <notting> adamw: has this been audited against the current distro? 20:24:25 <mjg59> adamw: There are other actions which will cause modules to be automatically loaded 20:24:27 <adamw> pjones: i thought I changed all instances of 'root authentication', i'll fix any that remain 20:25:02 <mjg59> adamw: Such as filesystem mounting 20:25:03 <cwickert> pjones, if i understand the policy correctly, it does allo authentication other then root 20:25:22 <pjones> cwickert: I assume it means to and does elsewhere. 20:25:27 <adamw> pjones: i've adjusted it to 'administrative authentication' in most cases. it's certainly not intended to require authentication exclusively via root password. 20:25:30 <pjones> anyway, I need more time to read this before I've got a real opinion. 20:25:46 <adamw> pjones: oh, right, in the very first paragraph, will fix. 20:25:46 <cwickert> pjones, i see 20:26:09 <mjg59> adamw: So this may conflict with existing behaviour, right? 20:26:11 <adamw> mjg59: any others spring to mind? 20:26:23 <mjg59> adamw: Changing the clock 20:26:28 <adamw> mjg59: notting: right, it hasn't been audited against the current distro yet. 20:26:34 <adamw> mjg59: that could cause a module to get loaded?! 20:27:04 <mjg59> adamw: Oh, Using certain network protocols, that kind of thing 20:27:12 <notting> adamw: mount -t vfat loads vfat 20:27:13 <adamw> the *intention*, though, is that it mostly should not require any changes to behaviour in current fedora, unless that behaviour is pretty obviously 'bad' already and we just hadn't noticed it. 20:27:21 <adamw> notting: yes, that one mjg noted already 20:27:22 <Kevin_Kofler> AFAIK, system-config-time allows changing the clock without admin auth and your policy says it should not be allowed. 20:27:45 <Kevin_Kofler> It shall be noted that KDE explicitly does NOT allow setting the system clock without admin auth. 20:28:02 <pjones> "ping" from another machine /can/ cause modules to be loaded... 20:28:07 <Kevin_Kofler> They required kdesu auth for 4.3, now in 4.4 it uses KAuth. 20:28:08 <adamw> Kevin_Kofler: that one specifically is intentional, I think the policy should require auth to change the time and if that's true about system-config-time it ought to be changed. 20:28:30 <mjg59> adamw: I think just note that the kernel may request a module load in response to a user event, and that's always ok 20:28:38 <adamw> however, if fesco disagreed on that, we could change the policy, it's not a 'accept it all or it goes in the bin!' situation 20:28:44 <nirik> I suppose bringing up/down interfaces can as well... ie, ppp loaded, etc. 20:28:44 <Oxf13> adamw: so is this a case where you think it's "obviously bad" but other people don't? 20:28:45 <adamw> mjg59: okay, thanks, will adjust that one. 20:28:48 <Oxf13> insert pissing match here? 20:28:59 <adamw> Oxf13: there was a large thread about it shortly after I came on board iirc 20:29:05 <Kevin_Kofler> adamw: I'm for making clock setting admin-only by default, it's the upstream KDE policy so it must be right. :-) 20:29:12 <adamw> as i remember, that came down largely in favour of requiring admin auth to change the clock 20:29:18 <Oxf13> I recall the thread, I don't recally any sort of "resolution" other than "I sent more mail than you did" 20:29:25 <mjg59> adamw: I think having fesco pass a policy that directly conflicts with a design decision made by another group is suboptimal 20:29:39 <adamw> hmm, okay. well as I said, if you feel strongly, we can remove that criterion to reflect current behaviour 20:29:48 <skvidal> mjg59: umm - but we've done that before 20:29:49 <Kevin_Kofler> Right now we ship inconsistent policies there (KDE requires admin auth, system-config-time and/or GNOME doesn't). 20:29:50 <adamw> and possibly discuss adding it back as a separate change that has to go through the process 20:30:04 <skvidal> mjg59: the install-pkgs-as-an-user was just that case 20:30:07 <mjg59> Kevin_Kofler: And they have different button orders, too 20:30:25 <adamw> i would imagine in future GNOME expects to make it one of the things only admin group users can do 20:30:31 <adamw> at which point it *would* comply with the policy 20:30:45 <mjg59> adamw: I think that that's something that should be discussed with the desktop people before we pass that 20:30:57 <cwickert> Kevin_Kofler, sorry, I can't follow you. why do you say that s-c-t doesn't requie authentication? 20:31:00 <Kevin_Kofler> mjg59: Yeah (Sucks Order Button Gnome The), but that's another rant. ;-) 20:31:18 <Kevin_Kofler> cwickert: Maybe it's wrong. 20:31:20 <adamw> mjg59: right, as I said, if you'd prefer to pass it without that clause for now I can drop it and it can be discussed separately in future 20:31:24 <Kevin_Kofler> I've read it claimed somewhere. 20:31:38 <skvidal> mjg59: maybe we're turning this around 20:32:06 <mjg59> System timezone can be changed without root 20:32:06 <adamw> GNOME does require auth to change the system time, currently. 20:32:14 <adamw> mjg59: timezone, yes, but not system time 20:32:19 <cwickert> Kevin_Kofler, You are attempting to run "system-config-date" which requires administrative 20:32:20 <cwickert> privileges, but more information is needed in order to do so. 20:32:23 <dgilmore> mjg59: if the policy is sane id question the work done by upstream. 20:32:26 <mjg59> adamw: "Change the system clock" is unclear on that point 20:32:28 <adamw> which is always in UTC (by default) and what is used for logging and stuff (which is what was considered sensitive in the discussion, IIRC) 20:32:32 <adamw> mjg59: try clicking it 20:32:38 <adamw> I just did :) 20:32:42 <adamw> it pops up a policykit auth box. 20:33:01 <cwickert> that's just how it should be IMO 20:33:06 <notting> do we want to take a vote on policy minus clock? 20:33:26 <mjg59> Ok. I believe that's something that's changed within the lifetime of F12. 20:33:32 <mjg59> But possibly I'm thinking of the F11 behaviour 20:33:42 <adamw> notting: just a sec 20:33:51 <adamw> it seems like right now, behaviour is in fact as described in the document everywhere 20:33:53 <pjones> anyway, there's enough discussion here that I'd say it certainly still needs some time in the feedback loop before we actually vote on it. 20:34:00 <skvidal> mjg59: so maybe groups make changing to authorization levels should talk to fesco before that happens? 20:34:02 <cwickert> +1 for the policy with clock included. date/time changes are security relevant because you can turn back the time to a oint where a password was not yet expired 20:34:06 <adamw> kde requires auth, gnome requires auth, s-c-date apparently requires auth. 20:34:07 <nirik> if there is an upstream design that conflicts with the policy, can't we address that at the time it's found? ie, either change the policy or ask the design be changed? 20:34:16 <skvidal> +1 to cwicket 20:34:20 <skvidal> err cwickert 20:34:25 <adamw> nirik: yes, that's how i'd envisage the situation being handled 20:34:27 <notting> hm 20:34:28 <notting> so 20:34:40 <notting> "Add, remove, or downgrade any system-wide application "... implies upgrade is allowed 20:34:46 <nirik> so, we are at +4 I think now... ;) 20:34:49 <skvidal> notting: no it doesn't 20:34:55 <skvidal> notting: update == add AND remove 20:35:06 <notting> skvidal: it does not state that. 20:35:08 <skvidal> notting: at least in my horrible broken worldview 20:35:08 <adamw> skvidal: um, no, notting's right about the intention 20:35:09 <skvidal> :) 20:35:15 <notting> in any case 20:35:15 * pjones continues to beat the "this needs more time to bake" drum. 20:35:18 <Kevin_Kofler> Upgrade may be allowed without admin auth and in fact currently is. 20:35:20 <adamw> skvidal: 'upgrade' was removed from the wording, specifically at hughsie's request 20:35:28 <Kevin_Kofler> Of course the policy doesn't REQUIRE that we allow it. 20:35:37 <notting> the process of upgrading can (theoretically) do some of the things listed 20:35:38 <Kevin_Kofler> But it currently is and it's not considered an issue. 20:35:41 <dgilmore> pjones: /me agrees 20:35:43 <pjones> seriously, we've got 100+ lines of discussion including several suggestions here. I like what I see, but it's not ready. 20:35:43 <notting> of course, those could be considered package bugs 20:35:47 <adamw> on the basis that users should be allowed to perform system updates (not fedora version upgrades) 20:35:52 * dgilmore is 0 right now. this needs more work 20:36:05 * adamw would have liked this feedback on -devel-list =) 20:36:17 <notting> but if we have an updated version of bash that roots the box, we have bigger issues. so, eh. 20:36:19 <mjg59> Yeah. I think this is good, but could do with slightly longer. 20:36:29 <pjones> adamw: a fair point. as my excuse: you know today is feature freeze, right? ;) 20:36:43 <adamw> so far I've only got a couple of things on my 'definitely to be changed' list, from this discussion 20:36:50 <adamw> we spent a lot of time discussion the clock thing, which actually seems to be fine 20:37:06 <adamw> i'll change the module thing as mjg requested 20:37:17 <notting> adamw: i really would be interested in a) how we would enforce/test this b) preliminary results of this being tested on F12/rawhide 20:37:19 <pjones> adamw: I think -devel list is a perfectly reasonable place for feedback. And I think it clearly needs some more discussion there. 20:37:20 <Kevin_Kofler> I don't think this needs more discussion. 20:37:21 <cwickert> if the creator of the draft says he wants feedback on f-d-l, we should do it. otherwise someone should just give the last missing +1 ;) 20:37:29 <mjg59> adamw: I'd prefer it if we made those changes, went one more round on -devel and then basically approved as a formality in a couple of weeks? 20:37:32 <nirik> so another cycle of change/devel list, revisit next week? 20:37:38 <pjones> nirik: +1 to that. 20:37:39 <cwickert> fine with me 20:37:40 <adamw> mjg59: that's fine by me 20:37:43 <mjg59> Ok 20:37:56 <mjg59> But yeah, this seems helpful 20:38:19 <adamw> we can just start the security validation testing from beta rather than alpha, that's not a problem. and we'll probably only have time to implement very limited testing for f13 anyway. 20:38:34 <Oxf13> adamw: we can also retroactively test Alpha 20:38:36 <adamw> true 20:38:39 <cwickert> we might also ask the desktop folks as they tend to have a very sluggish view of what security is about ;) 20:38:39 <Oxf13> to help us determine what to fix for Beta 20:38:44 <mjg59> Ok 20:38:44 <ajax> postpone for a week sounds fine for me. 20:38:48 <mjg59> Shall we move on? 20:38:49 <Oxf13> Alpha->Beta is bugfix time 20:38:51 <pjones> we can also start based on this without feedback and change the results based on the feedback ;) 20:38:53 <nirik> #agreed adamw will add revisions and post to devel list. Will revisit next week 20:38:54 <Kevin_Kofler> adamw: BTW, if you need any info about KAuth for the validation, I'll be happy to provide it. 20:39:09 <nirik> thanks for working on this adamw 20:39:13 <adamw> Kevin_Kofler: thanks 20:39:20 <nirik> #topic #337 Zarafa - https://fedoraproject.org/wiki/Features/Zarafa 20:39:22 <Kevin_Kofler> (But you'll only need it if you do validation at source level. Binary-wise a KAuth mechanism and policy will basically just be a PolicyKit one.) 20:39:25 <nirik> .fesco 337 20:39:31 <zodbot> nirik: #337 (Zarafa - https://fedoraproject.org/wiki/Features/Zarafa) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/337 20:39:40 <nirik> This is a late feature request. 20:39:54 <mjg59> So, having checked: 20:39:59 <nirik> It was waiting for FOSDEM to be announced, so it wasn't ready time freeze time. 20:40:09 <cwickert> right, but it was late because of some marketing 20:40:15 <mjg59> news.google basically gives nothing for Zarafa other than PR put out by upstream 20:40:22 <cwickert> now it was announced, which means there is some public pressure 20:40:23 <dgilmore> -1 20:40:31 <mjg59> It's not a high-profile piece of software 20:40:32 <dgilmore> this can be a feature for F-14 20:40:58 <mjg59> There's no indication that it brings anything to the distribution other than a couple of packages - it's not integrated with large swathes of other code 20:40:59 * notting thinks it's no more fringe then netbeans, which we keep approving features for. so, meh. +1 20:41:01 <dgilmore> but they missed the feature deadline. and they did not send fesco an email. there is a private list for such things 20:41:09 <dgilmore> they could have given us a heads up 20:41:14 <adamw> mjg59: it's a decent groupware system, which is something we really don't have at present 20:41:21 <pjones> I'm thinking -1 not because I don't think it should be in the distro but because I don't think we should be doing these guy's advertising for them. 20:41:22 <Kevin_Kofler> dgilmore: It makes no sense to advertise a feature which got introduced in F13 as a "F14 feature". 20:41:26 <adamw> as a year's discussion on the infrastructure list indicates :) 20:41:26 <cwickert> it is *the* groupware atm 20:41:29 <mjg59> adamw: That's true, but that's not really how it's being presented 20:41:33 <adamw> mjg59: good point 20:41:33 <dgilmore> Kevin_Kofler: thats your opinion 20:41:54 <mjg59> So, personally, I'm -1 on this because it just seems to be a new package 20:42:00 <Kevin_Kofler> I'm not convinced this is a feature at all, but a F14 feature? Huh??? 20:42:11 <mjg59> And while it's potentially interesting, it's not something I'd consider a distribution feature 20:42:15 <cwickert> here in Germany it was already announced, see http://www.heise.de/newsticker/meldung/Zarafa-fuer-Fedora-und-Ubuntu-922793.... 20:42:23 <pjones> mjg59: exactly 20:42:30 <mjg59> Future integration or a groupware server spin? That kind of thing, yes 20:43:11 <cwickert> i consider it a feature, no doubt about it. of course it's just a few more packages, but this is what many features come down to 20:43:27 * nirik talleys: -3 / +1 so far I think. 20:43:31 <cwickert> +1 20:43:33 <Kevin_Kofler> I vote -1 not a feature (just a new package), but I explicitly want it noted that I don't agree with dgilmore's proposal to make this a Fedora 14 feature. 20:43:43 <mjg59> -1 20:44:02 <skvidal> +1 - seems fairly harmless to put in there 20:44:03 <dgilmore> Kevin_Kofler: all im saying is it can be considered as a F-14 feature 20:44:05 <Kevin_Kofler> It's also yet another "Community Edition" with reduced functionality. 20:44:07 <Oxf13> Kevin_Kofler: we've had examples of that in the past. A package will get in, or partially in for one release, only to be announced as a (more polished) feature the next release. 20:44:22 <Kevin_Kofler> Oxf13: I think this is really silly. 20:44:24 <cwickert> Kevin_Kofler, fedora is a community edition or RHL too 20:44:28 <Oxf13> particularly for packages which get in after feature freeze 20:44:44 <Kevin_Kofler> A feature should be announced at the point it gets in. 20:44:54 <nirik> so thats -4 / +3 ? 20:44:57 <pjones> -1 20:44:58 <Kevin_Kofler> Our feature process is failing if we announce features in the next release when they're already old. 20:45:03 <Oxf13> Kevin_Kofler: so you're saying we shouldn't allow any new packages that might be part of a feature after feature freeze? 20:45:04 <pjones> (but I think you counted me already) 20:45:05 <cwickert> Kevin_Kofler, with reduced features: no 8 year support cycle, not hardware vendor certification and so on 20:45:21 <Kevin_Kofler> Oxf13: No, I'm saying we should accept features for things like new packages late. 20:45:24 <ajax> 0. just don't care about this feature, and i think we're begging the feature/releasenote question here 20:45:32 <Kevin_Kofler> In fact IMHO we even need a way to advertise features in updates. 20:45:35 <abadger1999> cwickert: Kevin Kofler's difference is that Fedora is allowed to evolve on its own. whereas he perceives zarafa community edition not being able to do so. 20:45:52 <Oxf13> Features in Updates, that's something I'd like to us STOP doing 20:45:55 <skvidal> ajax: http://begthequestion.info/ 20:45:56 <cwickert> abadger1999, sorry, but this makes me laugh 20:45:58 <Oxf13> like immediately 20:46:10 * nirik is slightly +1 20:46:14 <Kevin_Kofler> If this is a feature, it should be advertised as available in F12 (which it is, at least it hit updates-testing already), not in F13 and certainly not in F14. 20:46:17 <ajax> skvidal: sorry, wrong usage. "indirectly arguing the". 20:46:24 <nirik> so, -4 / +4 / 0 :) wheeee 20:46:25 <skvidal> ajax: yay, thanks 20:46:38 <skvidal> nim-nim: I think it was -5/+4 20:46:43 <skvidal> err 20:46:47 <skvidal> nirik: ^^^ 20:46:53 <Kevin_Kofler> Oxf13: I think they're a good thing and essential to what Fedora is about. 20:47:00 <nirik> I'm trying to puzzle out the final tally. Would everyone revote from now: 20:47:02 <Kevin_Kofler> And our feature process fails at highlighting them. 20:47:08 <cwickert> +1 20:47:15 <dgilmore> -1 20:47:16 <Kevin_Kofler> -1 20:47:16 <notting> nirik: weak +1 20:47:19 <nirik> +1 (reluctanctly) 20:47:26 <skvidal> +1 <shrug> 20:47:29 <pjones> -1 20:47:44 <skvidal> mjg59: had a -1 before 20:47:54 <mjg59> Yeah, -1 20:48:06 <pjones> so, we're tied. 20:48:08 <nirik> so, with ajax'es 0 thats -4 / +4 / 0 20:48:11 <cwickert> so who is missing? 20:48:20 <ajax> oh goody, i get to tiebreak 20:48:29 <cwickert> ah, ajax is 0 20:48:29 <dgilmore> cwickert: ajax's 0 20:48:52 <pjones> ajax: I think you're right about indirectly arguing the release note question - and I don't think this should get a release note 20:48:57 <nirik> well, or we could just say it doesn't have enough to pass. 20:49:14 <cwickert> but also not enough to fail... 20:49:24 <skvidal> cwickert: I think the case is :if it is not in, it's out 20:49:26 <ajax> well, here's the thing: 20:49:32 <ajax> the packages are already in the F13 repo, right? 20:49:39 <cwickert> rsc, ? 20:49:45 <ajax> (koji says yes) 20:49:46 <dgilmore> ajax: they are 20:49:48 <rsc> cwickert? 20:49:48 <kanarip> cwickert, i'm here too 20:49:53 <Oxf13> from the outside, this would seem much more of a /Fedora/ Feature if we had a spin showcasing it, or a good how to set it up guide based on Fedora, or something else to make it more than just "hey we added some packages" 20:49:53 <dgilmore> one part is still missing 20:50:01 <dgilmore> the web interface is not in yet 20:50:10 <kanarip> Oxf13, actually all of that is coming up 20:50:12 <rsc> dgilmore: it is waiting for fedora-cvs+ ;) 20:50:18 <ajax> so on the grounds that features are currently misused as glorified release notes and publicity, +1 20:50:19 <Oxf13> kanarip: where/when? 20:50:21 <nirik> as a side note, our policy says: "More than 50% of voting FESCo members must be in agreement to approve or deny." 20:50:26 <ajax> but let's fix that in the future please. 20:50:28 <dgilmore> rsc: right but its not available right now 20:50:35 <skvidal> nirik: more than 50% of present? 20:50:38 <notting> wow. 3 separate vertical panes for mail? 20:50:49 <kanarip> Oxf13, when i have sufficient time to be in zarafa.com's office in march and actually do the work while on their payroll 20:50:49 <skvidal> notting: it's like razor blades 20:50:51 <mjg59> Ok, so that's -4/+5 20:50:55 <dgilmore> notting: just like outlook i hear 20:50:55 <mjg59> Let's move on 20:50:58 <Kevin_Kofler> Folks, we have 5 +1 and 4 -1 votes now (ajax voted +1), so can we move on? 20:51:07 <nirik> #agreed Feature is approved. 20:51:10 <skvidal> kanarip: then it feels like you're a paid lobbyist - how nice :) 20:51:11 <Oxf13> kanarip: so, a Fedora 14 Feature? (: 20:51:13 <dgilmore> kanarip: so F-14 20:51:27 <nirik> #topic #275 Propose a soft-path via co-maintainer status to becoming sponsored 20:51:31 <nirik> .fesco 275 20:51:33 <zodbot> nirik: #275 (Propose a soft-path via co-maintainer status to becoming sponsored) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/275 20:51:46 <nirik> This was something discussed in a previous fesco a while back. 20:51:56 * jds2001 here to discuss this 20:51:56 <kanarip> skvidal, work them from the inside out i will ;-) 20:52:05 <nirik> basically a way to make it easier for a new contributor to become a co-maintainer of an existing package without needing to submit new ones. 20:52:40 <nirik> Oxf13: you around? you had some issues with the decision/implementation? 20:52:55 * jds2001 has written code to support this - but it's not done in a way that's useful in dist-git for one. 20:53:06 <Oxf13> I'm around. 20:53:12 <Oxf13> I listed my issues in the ticket 20:53:59 <Oxf13> basically this is a social problem, not a technical one 20:54:12 <Oxf13> and adding yet another layer of user rights doesn't seem like the right way to solve this 20:54:45 <Oxf13> and I'd like FESCo to reconsider going down that path 20:55:20 <nirik> I think if we do this with the existing setup, we need sponsors to be available to deal with this... 20:56:02 <Oxf13> right, sponsers would have to be willing to work with a maintainer who wants to add a co-maintainer 20:56:04 <mjg59> The stated problem of "It's non-obvious what one needs to do to join as an maintainer of an existing package" does not appear to be something that's a technical issue 20:56:16 <abadger1999> Oxf13: Note: The "Only has access to the packages which people explicitly grant them rights to, or packages they own." is up for change too as FESCo approved doing work to enable anyone in packager to commit to packages that grant it. 20:56:41 <ajax> abadger1999: rebirth of cvsextras 20:56:45 <ajax> which i think is fine 20:56:45 <Oxf13> jesus 20:57:14 <Oxf13> sure, it's fine, it just adds complexity and confusion 20:57:15 <ajax> but, if the cvsextras bit comes back, i don't see why "limited comaintainers" should be excluded from it 20:57:22 <Oxf13> and undermines the whole provenpackager thing really 20:57:28 <dgilmore> Oxf13: i think that the hardest part with your proposal is getting some sponsor to approve the new contributor 20:57:29 <nirik> abadger1999: I don't think that was ever really approved finally was it? 20:57:49 <notting> do we have a record of the number of times people have wanted to exercise the ability requested in this ticket? 20:57:50 <jds2001> Oxf13: the problem is that a need exists between nothing and provenpackager. 20:57:54 <abadger1999> nirik: Noe. It was left as, "in theory we like this; show us an implementation please" 20:57:58 <jds2001> the desktop team is a prime example. 20:58:02 <abadger1999> nirik: Err s/Noe/Correct/ 20:58:11 <Kevin_Kofler> If we go with Oxf13's proposal, we need to have some official policy that such comaintainers should get sponsored and under what conditions. 20:58:30 <Kevin_Kofler> Right now it's basically "a sponsor decided to sponsor him without any guideline to go by". 20:58:49 <Kevin_Kofler> The only documented sponsorship process we have is with a new package submission. 20:58:53 <Oxf13> Kevin_Kofler: you kind of need that anyway 20:59:21 <Kevin_Kofler> Yeah, this needs to be done before we discuss the technical details. 20:59:28 <Oxf13> I'm with ajax though, if the entirety of packagers is going to be a "allow access" check box, these not-quite-full maintainers shouldn't be excluded for it 20:59:46 <Oxf13> we can't solve everybody's niche desires of fine grained package ACLs at the same time 21:00:09 <nirik> well, this is really 2 issues, right? 21:00:14 <abadger1999> Also, hno requested being able to tell if someone is a sponsor under the normal system (so supposedly knows a lot about packaging) or under this system (and supposedly knows less) so that approving a new comaintainer i nthe pkgdb can provide more information. That's not possible without another group. 21:00:40 <abadger1999> Oxf13: well... we can. Just, do we want to. 21:00:40 <skvidal> so I would feel more comfortable with this change 21:00:41 <Oxf13> abadger1999: I don't think another group really answers that question either. 21:00:49 <skvidal> if we had more automated ways in place 21:00:54 <Oxf13> abadger1999: it's the person's actions that answer that question, not what grou pthey might have gotten into 21:00:55 <skvidal> of catching big-ish changes to a pkg 21:01:01 <jds2001> Oxf13: i can popup something in pkgdb 21:01:06 <skvidal> so as autoqa comes online 21:01:08 <abadger1999> Oxf13: Supposedly they get into groups because of their actions. 21:01:10 <skvidal> and rpmguard is used 21:01:12 <skvidal> it would be nice 21:01:16 <jds2001> "this person is a new dude - tread carefully" 21:01:26 <skvidal> abadger1999: they get into groups b/c of their willingness and interest 21:01:27 <Oxf13> jds2001: easily enough if the person doesn't own any packages 21:01:27 <abadger1999> Oxf13: But -- whether they've gotten into those groups not based on their actions is a social issue. 21:01:33 <skvidal> abadger1999: not b/c of actions, often 21:01:38 <abadger1999> skvidal: Right. 21:01:53 <Kevin_Kofler> You can get sponsored with a "new package" which is just split from another package for some obscure technical reasons which become obsolete 2 weeks later, at which point the new package gets retired. ;-) 21:02:00 <Kevin_Kofler> Hey, that's how I got sponsored. :-) 21:02:03 <Oxf13> right 21:02:16 <skvidal> Kevin_Kofler: and look at all the trouble you cause! :) 21:02:16 <Oxf13> what group you're in is somewhat meaningless, outside of provenpackager 21:02:27 <ajax> ew. 21:02:33 <nirik> well, for example there would be no way to tell if someone was sponsored to co-maintain obscurepackage, and then they submit a new package and don't block needsponsor, so they get a less exacting review? 21:02:37 <Oxf13> what packages you're responsible for, and what commits you've made is much more telling of a story 21:02:52 <Oxf13> why would they get a less exacting review? 21:03:04 <Oxf13> why are reviews for new packagers any different for review for existing packagers? 21:03:09 <nirik> well, a less esperenced reviewer perhaps. 21:03:17 * nirik can't type today. 21:03:21 <jds2001> fact of (social) life. 21:03:23 <dgilmore> Oxf13: they should be no different 21:03:53 <jds2001> Oxf13: im more likely to not look at EVERYTHING if you submitted a package vs. someone I didn't know. 21:04:03 <jds2001> your pakcage would get a full review, sure. 21:04:17 <jds2001> but I might not go out of my way to look for things in it. 21:04:20 <Oxf13> jds2001: that would be a mistake. I made a couple rookie mistakes in my last submission 21:04:32 <Kevin_Kofler> The only difference is who is allowed to do the review, or at least the final approval. 21:04:40 <nirik> anyhow, where do we go from here? 21:05:07 <Oxf13> well, given that the current technical solution is incompatiable with dist-git, I think that needs to at least go back to the drawing board 21:05:17 <Oxf13> or be aware that it'll need to be re-done with dist-git 21:05:22 <ajax> i would still really love it if there were cli tools for the account system 21:05:23 <nirik> it's hard to come up with a policy for when to sponsor someone that could mention all the factors... 21:05:47 <notting> Oxf13: i'd be +1 to that... no sense doing something that will be obsolete in X months 21:05:48 <Oxf13> especially since we don't really have a good description of what sponsorship means 21:06:06 <nirik> well, there is: https://fedoraproject.org/wiki/Package_sponsor_responsibilities 21:06:07 <Oxf13> how often do we use the information of who sponsored whom? and in what context? 21:06:16 <abadger1999> ajax: There's a library for parts of it. Need a tool that makes use of it and expand fas as we come up with new actions that we need to be able to do from the command line. 21:06:29 <nirik> Oxf13: very seldom. 21:06:43 <Oxf13> right 21:06:58 * abadger1999 notes that he was asked to speak to a packager since he was his sponsor i nthe past 6 months. 21:06:58 <nirik> sometimes in the case of 'who is X's sponsor, can we ask them to communicate with X and help clean something up' 21:07:35 <Oxf13> why is it we do that? Because we're afraid the user won't listen to FESCo? 21:07:46 <Oxf13> or we're afraid to assert FESCo's authority? 21:07:56 <notting> Oxf13: i think it may just be delegation 21:08:09 <Oxf13> fair enough 21:08:10 * abadger1999 agrees with notting's take on it. 21:08:30 <nirik> because the sponsor would have talked to the packager before... it may sound nicer than coming from a group... 21:08:41 <nirik> and yeah. 21:09:03 <nirik> ok, so I guess +1 to not implementing this and revist after we switch to a new VCS? 21:09:09 <Oxf13> well, I've stated my case. Is it enough to rebuke the current planned technical implmenetatoin? 21:09:31 <Oxf13> I'd prefer this was solved more socially than by making our ACL system even more complex and fragile 21:10:07 <ajax> i can buy the argument for dist-git being more important, yeah 21:10:23 <abadger1999> Although... 21:10:28 <jds2001> Oxf13: im hoping we can work together on coming up wiht something else technically. I'm not tied to any particular way of doing things, obviously. 21:10:31 <Oxf13> to be fair, I /think/ I could accomplish the same with the gitolite ACL system on top of dist-git 21:10:38 <Oxf13> I'd just prefer not to 21:10:52 <abadger1999> The implementation could be made to use the same system that we currently use. 21:11:08 <abadger1999> Which has to be ported to dist-git anyway. 21:11:12 <Oxf13> jds2001: but you're working from the assumption that to answer the sponsership question, we have to invent an SCM enforced additional rights layer 21:11:21 <abadger1999> It's just that using fs-acls was seen to be more secure. 21:11:43 <Oxf13> I'm stating that I don't feel we need the SCM enforced additional layer 21:12:27 <abadger1999> Then do we need to ask that? 21:12:30 <abadger1999> I think we do. 21:13:10 <abadger1999> because we want sponsors to feel comfortable sponsoring people. And the responsibilities that go with the two groups is different. 21:13:35 <abadger1999> The responsibilities of a sponsor for someone in each of the two groups. 21:13:36 <nirik> abadger1999: which two groups? normally sponsored / sponsored only to comaintain? 21:13:44 <abadger1999> Yes. 21:14:10 <Oxf13> I don't really see a difference 21:14:24 <Oxf13> in one case, you're sponsoring them to have write access to a package they brought with them 21:14:43 <abadger1999> Oxf13: You will when they have access to all the desktop team's packages. 21:14:46 <Oxf13> in the other case, youre sponsoring them to have write access to a package who's maintainer /wants them to have access to/ 21:15:31 <Oxf13> abadger1999: I think anybody enabling that checkbox should be the ones who are responsible for what happens, not the sponsors 21:15:51 <Oxf13> we shouldn't burdon the sponsors with "ZOMG THIS PERSON IS GOING TO HAVE ACCESS TO A BUNCH OF STUFF!!!" 21:15:58 <nirik> does the desktop team still have the issue of people not being able to commit that need to? 21:16:08 <abadger1999> Oxf13: Hmm.... Okay. Fesco willing to vote on changing the responsibilities of Sponsors? 21:16:30 <Oxf13> if the desktop team wants to open their packages to anybody who can get a sponsor, that is /their/ choice and /their/ responsibility to monitor for ill doing 21:16:49 <jds2001> nirik: if someone new got hired tomorrow, we'd be right back where we started. 21:16:55 <Oxf13> we already went through this once, and came up with proven packagers 21:16:55 * nirik wonders if they still want that 21:17:02 <abadger1999> If so, then sure, we don't need an additional group because the onus is on package maintainers to watch their packages for commits rather than sponsors to be monitoring what their sponsorees are doing. 21:17:18 <ajax> nirik: often. hence me wanting acl cli tools. 21:17:19 <nirik> jds2001: why can't they be added to the packages they need to commit? ok, it's a slight hassle, but shouldn't take that long. 21:17:34 <ajax> would be _really_ nice if i could change things for N packages at once 21:17:47 <nirik> there is pkgdb-client... dunno if it works for non admins tho 21:17:57 <Kevin_Kofler> From my experience with KDE, having to approve ACLs for a whole desktop is a big PITA. 21:18:15 <abadger1999> halfline: You still want This? 21:18:17 <Kevin_Kofler> And GNOME has more packages than KDE because they don't have those big modules. 21:18:18 <abadger1999> .fesco 108 21:18:19 <zodbot> abadger1999: #108 (Would be good if there was an acl for "let all packagers edit this package" in pkgdb) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/108 21:18:37 <nirik> If there was a cli to do that/make it easy, would that remove the need for a 'allow anyone to commit' ? 21:18:55 * halfline reads scrollback 21:19:56 <abadger1999> nirik: It doesn't -- but one could be written. 21:20:17 <Oxf13> I think that's still going to suffer from the problem of remembering all the "desktop" packages which need to be tweaked 21:20:18 <nirik> ok. 21:20:38 <halfline> oh i just read a bunch of scrollback 21:20:45 <halfline> to realize there was only 2 lines of relevant scrollback 21:20:56 <nirik> oops. ;) 21:21:00 <Oxf13> halfline: sortof. 21:21:10 <ajax> Oxf13: yes, but most of the reason we ask for pkgdb admin intervention is because the web site is really slow. 21:21:12 <Oxf13> halfline: we're debating whether the "everybody" would have some change to it 21:21:17 <halfline> yea, i still want to be able to say "go ahead, commit" 21:21:19 <halfline> to anyone 21:21:35 <Oxf13> halfline: right now "anyone" == somebody who has brought a pckage and gone thorugh review process 21:21:56 <Oxf13> halfline: we're debating making "anyone" also include somebody brought in specifically to co-maintain a package, without going through the review process first 21:22:07 <abadger1999> Oxf13: Well no... anyone = someone who has a sponsor that should be expecting to ride reign over them if they do bad things. 21:22:36 * abadger1999 has sponsored people who haven't submitted packages with that understanding since we've switched to provenpackager. 21:22:47 <abadger1999> Since that was one of the impetus's for provenpackager. 21:22:49 <Oxf13> but if I recall from previous discussions with halfline, 'anyone' means anyone. Regardless of how they get in. 21:22:51 <pjones> abadger1999: which is kindof bad, because previously the person who put themself on the hook as sponsor is really only expecting to do so within a defined domain of certain packages. 21:23:09 <abadger1999> pjones: I don't believe that's true. 21:23:10 <halfline> ticket 108 is about letting people in the "packager" group commit to my packages 21:23:16 <halfline> without having to be in the "provenpackager" group 21:23:29 <Oxf13> halfline: right. 21:23:32 <halfline> that's what i want 21:23:37 <abadger1999> pjones: Wel... let me be more verbose 21:23:39 <Oxf13> halfline: the 'packager' group may change symantics 21:23:45 <jds2001> halfline: if we relaxed the standards for teh "packager" group - would that be acceptable? 21:24:05 <Oxf13> halfline: we'd like to be able to bring some contributors in, who are sponsored to co-maintain a package. 21:24:13 <abadger1999> pjones: In the cvsextras day, it could be any package. In the provenpackager era, we went to a certain restricted set of packages. If we do ticket 108, then it opens it up again. 21:24:18 <Oxf13> halfline: and without creating Yet Another Packaging Group, they'd get stuffed into 'packager' 21:24:25 <Oxf13> halfline: and thus they would have access to your packages. 21:24:31 <Oxf13> halfline: is this something that concerns you, or not? 21:24:35 <halfline> i'm okay with lowering the bar to packager 21:24:37 <halfline> i want it low 21:24:54 <halfline> but there's no way right now to allow plain packagers access 21:24:59 <Oxf13> halfline: as low as possible, without being "The Internet" right? 21:25:13 <abadger1999> pjones: So our expectations for the sponsor, (to me) is that they ride reign on what the sponsored packager does to any package... but our acl system currently limits the damage that they can do so you don't have to be as vigilant as you used to. 21:25:19 <halfline> right, they should have done the CLA etc 21:25:53 <Oxf13> I honestly think anybody who doesn't watch the commits for packages they care about is Doing It Wrong 21:26:08 <abadger1999> pjones: If we change that so it's no longer epected that the sponsor is watching but instead, the people who own the package are watching, then yeah, we don't need another group. 21:26:21 <Oxf13> placing any amount of trust in somebody else or some group membership is just wrong. People make mistakes. 21:26:30 <pjones> Oxf13: boo, hiss 21:26:45 <pjones> placing /trust/ in them is one thing. expecting that they don't make mistakes is a different thing. 21:26:50 <Oxf13> pjones: do you not notice when somebody commits to grub CVS? 21:26:59 <jds2001> but if someone who knows next to nothing about packaging came in to comaintain libfoo, would you be ok with that person being able to commit to your packages? 21:27:15 <pjones> I do notice (usualyl ;), but trusting them to commit and expecting that it's always perfect when they do so just aren't the same. 21:27:23 <Oxf13> pjones: of course 21:27:30 <Kevin_Kofler> I definitely notice when somebody commits nonsense to any package I own or have watchcommits on. 21:27:32 <Oxf13> pjones: you still review it right? 21:27:38 <pjones> placing trust in them isn't wrong. 21:27:41 <pjones> Oxf13: usually. 21:27:58 <pjones> tbf, usually, if they're doing things right, I've reviewed it /before/ they do that. 21:28:11 <Oxf13> I personally wouldn't have a problem with my packages open to anybody who's gotten through the CLA step 21:28:13 <nirik> abadger1999: so, if we don't do another group, you would say thats a change in sponsors responsibilities. Should we ask sponsors for feedback on this change? 21:28:38 <Oxf13> either they are maliciously intent on damaging my apckages, in which case they'd go through whatever hoops necessary 21:28:51 <Oxf13> or the only other way theyd' touch my package is if they just simply made a mistake 21:28:57 <Oxf13> or were trying to fix something 21:29:02 * skvidal snickers 21:29:37 <Oxf13> if we're trying to keep the Bad Guys out, this isn't the way 21:29:59 <jds2001> im not sure anyone ever proposed that it was. 21:30:07 <abadger1999> nirik: Yes -- but I'd ask all packagers. Because it's taking responsibilities away from sponsors and giving them to package owners. 21:30:17 <abadger1999> nirik: So the workload for sponsors should go down. 21:30:17 <Kevin_Kofler> My opinion is, we have way too much paranoia already, we don't need another group. 21:30:28 <nirik> so we have: a) seperate group for people brought in to co-maintain existing packages or not. and b) allowing a 'packager can commit' checkbox for all packages 21:30:42 <Kevin_Kofler> We just need a formal policy that sponsors can go by to sponsor aspiring comaintainers instead of the current ad-hoc system. 21:30:44 <abadger1999> nirik: Proposal: I'll write a new draft of https://fedoraproject.org/wiki/Package_sponsor_responsibilities 21:30:50 <nirik> abadger1999: I don't know how many sponsors closely watch their sponsorees these days... 21:31:15 <abadger1999> That has a new set of responsibilities that is more geared towards packagers watching their packages/ sponsors are just mentors, not watchdogs. 21:31:21 <Oxf13> particularly since I don't think we have any ability to "watch all my sponsor's commits" 21:31:24 <abadger1999> I'll Bring it to fesco next week. 21:31:36 <abadger1999> Sound good? 21:31:55 <Oxf13> really I think we're going to run into two, possibly 3 camps here 21:31:59 <nirik> abadger1999: +1. Would that also need changes to https://fedoraproject.org/wiki/Package_maintainer_responsibilities ? 21:32:06 <Oxf13> camp 1) get your hands off my package. These people won't even let provenpackager in. 21:32:19 <Oxf13> camp 2) I want some sort of vetting first, I'll let proven packager in. 21:32:47 <Oxf13> camp 3) Can't we all just get along? THese people will wish to let the biggest group possible have access, so that they don't haveto bother with "oh you want to fix that, but you can't, because you don't have access...." 21:32:52 <nirik> well, the current policy is only a fesco exception can remove provenpackager commits. 21:32:57 <Oxf13> camps 1 and 2 aren't affected by this change. 21:33:04 <Oxf13> camp 3 likely doesn't care. 21:33:32 <Kevin_Kofler> Oxf13: Right, and I agree with you we don't need the extra group. 21:34:00 <abadger1999> nirik: I'll look at that page but I don't think it'll change substantially... maybe an additional section about who can commit to your packages in what circumstances. 21:34:05 <Oxf13> extra group or not, that's really only affecting camp 3 21:34:05 <nirik> I think it more likely we will get: 1) I want a co-maintainer and don't want to have to bug a sponsor, can't packagers just sponsor? and 2) shouldn't we set 'packager can commit' on all packages when we implement this and make people opt out? :) 21:34:19 <nirik> but thats further issues. ;) 21:34:47 <nirik> proposed: abadger1999 will draft a updated policy for us, we revisit next week? 21:34:50 <Oxf13> nirik: right. I'm expecting that too. I'm happy with the results of proven packager, as I think it was the best compromise we could make at the time (and continue to throw more people in proven packager) 21:35:00 <notting> nirik: +1 to defer and move on 21:35:14 <nirik> +1 to move to next week and revisit it then. 21:35:18 <ajax> +! 21:35:19 <Oxf13> nirik: fine by me to defer (even though I'm not in FESCo) 21:35:22 <ajax> to that 21:35:33 <Kevin_Kofler> +1 to deferring 21:35:36 <mjg59> +1 to deferral 21:35:44 <skvidal> +1 defer 21:35:51 <nirik> #agreed abadger1999 will draft a new policy for consideration next week 21:35:53 <pjones> +1 to yes, please defer. 21:35:59 <nirik> #topic #338: Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert its implementation from pre-branch Rawhide 21:36:04 <nirik> .fesco 338 21:36:10 <zodbot> nirik: #338 (Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert its implementation from pre-branch Rawhide) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/338 21:36:21 <nirik> So, this feature just landed today in rawhide I think. 21:36:25 <Kevin_Kofler> So I filed this one very late, but that's because that change came in right before the meeting and it's breaking things. 21:36:46 <Kevin_Kofler> Seeing it's also the day of the feature freeze, it's quite a bad time to be breaking the world. 21:36:46 <pjones> On the one hand, it does sound bad so far. 21:36:55 <ajax> do we have a mass rebuild scheduled for F13? 21:36:58 <pjones> On the other hand: it may be late enough that changing it back just causes more work. 21:37:02 <notting> ajax: no 21:37:14 <Kevin_Kofler> pjones: Changing it back doesn't cause more work. 21:37:16 <ajax> notting: i am actually shocked. 21:37:18 <nirik> I think the changes/fixes are going to be pretty easy. 21:37:20 <Oxf13> changing it back should'nt cause us to 'undo' anything already done 21:37:22 <pjones> Kevin_Kofler: no? hrm, okay. 21:37:24 <Kevin_Kofler> Everything that's fixed also builds without the fix. 21:37:31 <pjones> oh, indeed. 21:37:31 <nirik> but there are just a lot of them. 21:37:42 <notting> so, i'm not so keen on reverting this, as the packages in question are relying on implementation details rather than defined behavior 21:37:43 <pjones> eh, doesn't seem that bad, even though the work is kindof annoying in general 21:37:46 <mjg59> I think it ought to be reasonable to say that a 100% complete feature does not break hundreds of package builds 21:38:04 <Kevin_Kofler> *without the ld change, I mean. 21:38:04 <nirik> https://fedoraproject.org/wiki/DSOLinkBugs is the list 21:38:08 <Oxf13> mjg59: I agree 21:38:11 <ajax> mjg59: name a gcc update that hasn't broken rebuilds. 21:38:11 <pjones> mjg59: I don't think I agree with that, actually 21:38:18 <Oxf13> feature freeze isn't "land this, let the suckers fix shit for the next month" 21:38:26 <pjones> Oxf13: of course it is. 21:38:43 <Kevin_Kofler> ajax: A GCC update isn't rushed in the day of the feature freeze. 21:38:49 <nirik> is there urgency that this land for this release? 21:38:49 <pjones> Kevin_Kofler: always has been before. 21:38:57 <ajax> also, it's worth remembering that this package does not break any existing binary rpms. 21:39:07 <Kevin_Kofler> GCC has always hit earlier as far as I remember. 21:39:07 <ajax> s/package/change/ 21:39:07 <Oxf13> pjones: we typically do the gcc mass rebuilds /before/ feature freeze 21:39:18 <pjones> right - you only need to fix packages that a) are "broken" already, and b) need to be rebuilt anyway 21:39:19 <nirik> ajax: right, but it could delay a fix for something else while this is fixed so it builds againl. 21:39:22 <Oxf13> ajax: that is a fair point. 21:39:26 <pjones> Oxf13: the mass rebuilds, yes. 21:39:29 <ajax> nirik: by entire minutes. 21:39:35 <nirik> yeah, usually. 21:39:38 <Oxf13> pjones: the mass rebuilds are done /for/ gcc 21:39:53 <Kevin_Kofler> Now those GCC changes which break things are its own issue, as are the merits of this very feature (IMHO it gains us nothing and just breaks things), but the issue we're discussing here is the timing. 21:40:08 <pjones> Oxf13: no, the mass rebuilds are done so that the resulting binaries can have some feature or protection that is delivered by using a newer gcc. 21:40:12 <Oxf13> ajax: to be fair, entire minutes for people who understand the problem and know how to fix it, which I'm betting is not the majority of folks who's packages will be broken 21:40:27 <pjones> Oxf13: which is a fine line, but an important one - it defines why we don't need a mass rebuild for this 21:40:57 <notting> if only we had a team of volunteers tasked with fixing minor issues like this 21:40:58 <Kevin_Kofler> nirik: s/could delay/definitely delays/ 21:40:58 <ajax> give me a moment, i need to do some math here. 21:40:59 <Oxf13> pjones: I think we're arguing different things. THe gcc changes, which typically lead to mass rebuilds and changes to binaries, are often landed well before the feature freeze 21:41:04 <pjones> notting: *snicker* 21:41:10 <pjones> Oxf13: right 21:41:10 <Kevin_Kofler> Here's one fix being delayed by this issue: https://bugzilla.redhat.com/show_bug.cgi?id=541353 21:41:16 <pjones> Oxf13: usually. 21:41:31 <Oxf13> pjones: I don't speak in absolutes... often. (: 21:41:32 <cwickert> IMO a big change like this should have been communicated over fedora-devel-announce. you cannot break a larg number of packages without announce and not at this time 21:41:34 <pjones> Oxf13: several times there have been gcc features (and IIRC mass rebuilds) that land /after/ feature freeze, if you recall. 21:42:14 <nirik> Kevin_Kofler: a LD_FLAGS="-ldbus-glib-1" ? or patch the cmake/whatever to add that. 21:42:33 <Oxf13> IF we land this, I think it'll require a call to arms for provenpackagers 21:42:37 <ajax> cwickert: this was announced as impending _several_ times on fedora-devel 21:42:40 <Oxf13> to be willing to step up and help out when things fail 21:42:41 * nirik guesses the feature owners are not here... 21:42:45 <notting> ajax: and approved a few weeks ago 21:42:49 <pjones> Oxf13: anyway, since there's no rebuild required, I don't see any particular problem with the fact that the gcc guys seem to have complied with the schedule. 21:43:17 * dgilmore thinks DSO changes needed to land a month ago 21:43:18 <Kevin_Kofler> It's probably already fixed upstream and we just need to fetch the fix, but the point is that this is delaying unrelated critical fixes, which is what we should be working on now, not fixing totally unnecessary FTBFS bugs. 21:43:42 <mjg59> Kevin_Kofler: Whenever this would have landed, it would have caused FTBFS bugs 21:43:44 <ajax> there are 280 packages on that page 21:43:46 <notting> i find the statement that this is blocking other fixes is a bit of a straw man. it would do that no matter when it landed, feature freeze or no. 21:43:51 <pjones> I really don't like the message we send to the compiler guys about the schedule if we roll this back. 21:43:59 <ajax> there are eleven weeks until final freeze, according to http://fedoraproject.org/wiki/Releases/13/Schedule 21:44:02 <mjg59> The question is whether it causes more problems on the day of feature freeze than earlier in the process 21:44:12 <pjones> which is, basically, "ha ha, you guys get to guess the real schedule and it's earlier than we say" 21:44:16 <Oxf13> pjones: I'm not really comfortable landing a feature which makes large swaths of packages fail to rebuild, this close to the feature freeze. I would have preferred it to land earlier, with people already lined up to fix stuff 21:44:23 <mjg59> We have a week until alpha freeze 21:44:25 <Kevin_Kofler> mjg59: Yes, and that's why I'm against it entirely, but now is the worst possible time to land it (assuming nobody would even think of landing this AFTER the feature freeze ;-) ). 21:44:33 <pjones> Oxf13: I don't think that's as bad, honestly. 21:44:34 <ajax> that means packages need to get fixed at the rate of just over 5 a day 21:44:38 <Kevin_Kofler> dgilmore: 1 month? To get into F13, this is 6 months too late! 21:44:39 <notting> Oxf13: but again, they posted multiple times to the list describing all the packages that failed 21:44:54 <Oxf13> notting: that is true, where there any offers to just fix them? 21:44:56 <pjones> Kevin_Kofler: too late? what part of "feature freeze" is confusing? 21:45:00 <Kevin_Kofler> Such a change needs to get in right after Rawhide reopens. 21:45:05 <notting> Kevin_Kofler: wait. a bugfix for correctness is six months too late for F13 when it's before beta freeze, but you want to add Features(tm) AFTER WE SHIP? 21:45:18 <pjones> I think even arguing that the features actually have to work 100% correctly today is a bit of a stretch. 21:45:37 <Kevin_Kofler> This is NOT A BUGFIX. 21:45:46 <ajax> 5 a day is not a high rate. 21:45:56 <Kevin_Kofler> It's a completely unnecessary backwards-incompatible change to the definition of ELF linking. 21:45:56 <Oxf13> either way, I don't feel strong enough about it to force it's rollback. 21:46:02 <pjones> Kevin_Kofler: no, it's a feature change that's being landed on time according to the schedule. 21:46:05 <mjg59> I would prefer packages to have been fixed before this landed 21:46:11 <Kevin_Kofler> It's NOT ON TIME. 21:46:14 <mjg59> But I don't think it's enough to revert it 21:46:15 <pjones> mjg59: I don't think that's very realistic at all. 21:46:21 <Kevin_Kofler> Feature freeze today doesn't mean you get to break half of the distro today. 21:46:27 <ajax> Kevin_Kofler: it's not broken. 21:46:37 <mjg59> Kevin_Kofler: I think you're off by at least an order of magnitude there 21:46:37 <pjones> mjg59: it's very difficult to fix packages for compiler changes without the new compiler being in the repos... 21:46:38 * poelcat thinks if FESCo wanted this to all be "done" a certain number of days before Feature Freeze they should have specified so when accepting the feature page... that's part of the point of the whoel process 21:46:41 <Kevin_Kofler> A change which impacts the entire distro needs to go in sooner so other packages can adjust. 21:46:47 <pjones> Kevin_Kofler: *nothing breaks because of this* 21:46:49 <pjones> nothing at all. 21:46:51 <Kevin_Kofler> We can argue how much sooner, but today, no. 21:46:57 <notting> Kevin_Kofler: that's ok. by your continued arguments, you can push a kde update after we ship and break 1/4 the distro then. 21:46:57 <pjones> no binary package in the repo stops working. 21:46:57 <Kevin_Kofler> pjones: We consider FTBFS to be a blocker issue. 21:47:07 <mjg59> Anyway. -1 to reversion. 21:47:10 <ajax> Kevin_Kofler: citation needed. 21:47:12 <Kevin_Kofler> So much that we retire packages because of FTBFS. 21:47:19 * notting agrees with mjg59. -1 to reversion 21:47:29 <pjones> Kevin_Kofler: FTBFS can be fixed between feature freeze and beta freeze 21:47:30 <Kevin_Kofler> And it prevents building critical fixes. 21:47:46 <Kevin_Kofler> We should be fixing actual BUGS now, not FTBFSes caused by an unnecessary "feature". 21:47:57 <pjones> I'm really very -1 to reverting this. 21:47:57 * nirik notes -2 is current tally 21:48:06 <nirik> ok, -3 21:48:09 <mjg59> Also, I think it's entirely unreasonable to carry on arguing over whether an approved feature is necessary or not 21:48:09 <Kevin_Kofler> I'm obviously +1 to reverting. 21:48:17 <mjg59> The time for that was during the initial discussion 21:48:25 <ajax> -1 to reverting 21:48:29 <Kevin_Kofler> mjg59: I did bring it up during the initial discussion! 21:48:32 <pjones> mjg59: well, things do get approved as "nice to have, let's see how they do" 21:48:35 <Kevin_Kofler> You didn't want to listen to me. 21:48:37 <mjg59> Kevin_Kofler: And that discussion is now over 21:48:38 <Oxf13> from a releng pov, as long as there are provenpackagers available to help those who don't understand the necessary work, I"m -1 to reverting the change. 21:48:42 <drago01> we aren't doing a mass rebuild anyway aren't we? 21:48:47 <Kevin_Kofler> You just all said "+1" and then "we moved on, shut up". 21:48:48 * nirik thinks the timing isn't very good here... but not sure it's worth reverting now that it's landed. 21:48:50 <Oxf13> drago01: no 21:48:52 <ajax> drago01: first thing i asked. no. 21:48:53 <drago01> ok 21:49:06 <ajax> which i'm _actually_ shocked by. 21:49:16 <pjones> drago01: no. and there's really nothing time-critical in the /short/ term about rebuilding things. 21:49:17 <cwickert> i don't like the timing, but reverting is not better 21:49:21 <nirik> -4, +1 21:49:23 <cwickert> -1 for revertiing 21:49:32 <Kevin_Kofler> cwickert: How is reverting not better? 21:49:38 <Kevin_Kofler> It'd fix the timing. 21:49:39 <mjg59> I think this is a reasonable thing to use to start a discussion on the impact of features on the rest of the distribution and the expectations we have 21:49:40 <pjones> ajax: historically we do a mass rebuild for a compiler feature that changes the resulting binary in a useful way 21:49:43 <nirik> ok, so thats -5... no revert. 21:49:45 <Oxf13> ajax: why's that? We've had other fedora releases with no mass rebuild 21:49:48 <pjones> ajax: whereas this hopefully doesn't change it at all. 21:49:56 <ajax> Oxf13: they seem to be the minority 21:49:57 <Kevin_Kofler> Have you seen the feedback on the fedora-devel-list? 21:50:16 <cwickert> Kevin_Kofler, we still have time to fix the packages and i don't think that we should revert an approved feature 21:50:18 <Kevin_Kofler> Parag A. Nemade, one of our most active reviewers, agreed with me, too. 21:50:24 <pjones> yes, there are some people that are having (minor) problems, and needs help. 21:50:26 <Oxf13> ajax: yeah, but not enough to be shocked by it. Maybe I'm too close to the action. 21:50:26 <pjones> need 21:50:27 <Kevin_Kofler> And jreznik too. 21:50:42 <cwickert> and yes, a lot of my packages are affected, but then I need to fix them 21:50:43 <Kevin_Kofler> I really don't see why this change must go into F13 at all costs. 21:50:47 <Oxf13> FWIW, any fine tuning of feature freeze policy shoudl happen at http://fedoraproject.org/wiki/Feature_Freeze_Policy 21:50:56 <mjg59> Kevin_Kofler: People are elected based on their ability to form opinions and enact decisions, not on their ability to reflect popular opinion (where popular opinion is defined as some self-selected people posting to a mailing list) 21:50:57 <pjones> This is really fixing packages that are already broken when you need to rebuild them. 21:50:57 <Kevin_Kofler> Why can't it not be postponed to F14? 21:51:06 <notting> Kevin_Kofler: the devel list was informed multiple times. why is there shock now? 21:51:14 <Kevin_Kofler> notting: Because of the timing. 21:51:16 <pjones> Kevin_Kofler: it can, it just shouldn't. 21:51:31 <pjones> there's really not a good reason to delay this change. 21:51:32 <mjg59> We can either do this now, or we can do it in F14 21:51:33 <cwickert> notting, honestly I feel like the information was not sufficient 21:51:36 <Oxf13> I should also note that this is the type of scenario that led to us moving feature freeze a week before alpha freeze 21:51:36 <notting> Kevin_Kofler: how so? i bet dollars to doughnuts the same people would have complained if their packages started failing last week 21:51:39 <mjg59> The amount of work required is the same 21:51:39 <Oxf13> so some vindication there. 21:51:40 <Kevin_Kofler> The devel list was not informed that the change would be happening the day of the feature freeze and everyone would be expected to scramble to fix the mess when we're supposed to be in a freeze. 21:51:51 <Kevin_Kofler> That information came in… today! 21:51:59 <mjg59> Kevin_Kofler: The freeze is... feature freeze 21:52:00 <notting> Kevin_Kofler: huh? nothing said fixes were required for alpha 21:52:06 <ajax> Kevin_Kofler: you don't have to fix anything today if you don't have a feature you're trying to land. 21:52:06 <mjg59> Not bug fixing freeze 21:52:07 <cwickert> notting, why not use devel-announce for changes like this? 21:52:20 <Kevin_Kofler> ajax: But not fixing that stuff prevents us from fixing other things because our builds fail. 21:52:25 <notting> cwickert: that's actually a good idea 21:52:26 <pjones> the feature came in before the feature freeze. rolling it back because it's so late would be... 21:52:29 <mjg59> Anyway, I don't think this discussion is going to get us anywhere 21:52:30 <pjones> dishonest seems like the right word. 21:52:36 <nirik> #agreed This proposal is rejected. The feature will stay in place. 21:52:52 <notting> nirik: request for feature maintainers to mail fedora-devel-announce? 21:53:07 <nirik> yeah, seems like a good idea to me. 21:53:25 <Oxf13> yeah, that makes sense 21:53:32 <nirik> how can we communicate that? 21:53:33 <Oxf13> the feature owner probably just didn't know it existed 21:53:48 <notting> nirik: put it in the log, someone pokes them post-meeting 21:53:52 <cwickert> nirik, not for each and every feature, but because you break a lot of packages. such changes MUST be announced properly 21:54:12 <Kevin_Kofler> I still don't understand why you consider it so important that this goes in into F13. 21:54:15 <nirik> #info Please announce feature changes that impact other packages on fedora-devel-announce to reach the most maintainers 21:54:22 <Kevin_Kofler> What's the benefit of this change? 21:54:37 <Kevin_Kofler> What I see is that it breaks almost 300 builds. 21:54:53 <skvidal> out of 8000 21:55:06 <Kevin_Kofler> nirik: This should have been done before the fact, so policy was not followed and as such the feature must be reverted. 21:55:07 <nirik> " the new default behaviour will help address potential problems further down the line if shared objects ever change their dependencies" 21:55:18 <Kevin_Kofler> And then it'll be after the feature freeze and thus too late to put it back. 21:55:19 <pjones> the benefit is that it means the fedora tools people don't have to maintain a fork. 21:55:26 <notting> #info devel-announce@lists.fedoraproject.org 21:55:34 <cwickert> Kevin_Kofler, to me it is not a question if it's importatn or not. the feature was approved and we still have plenty of time to fix the problems 21:55:50 * nirik wonders if we can move on now. A vote was taken... and decided. 21:55:53 <Kevin_Kofler> So this my next proposal: Revert this feature due to not having been announced on devel-announce, then punt to F14 due to having missed the freeze. 21:56:00 <cwickert> nirik, +1, move on 21:56:07 <Kevin_Kofler> And +1 to my next proposal. 21:56:18 <ajax> Kevin_Kofler: did you miss the part where we voted not to revert the feature? 21:56:22 <notting> what's next, a proposal to revert because they didn't send you a cookie? 21:56:25 <nirik> Kevin_Kofler: you wish to restate your rejected proposal on different grounds? wha? 21:56:27 <Kevin_Kofler> ajax: This is a new proposal. 21:56:37 <Kevin_Kofler> It needs a new vote. 21:57:00 <mjg59> Kevin_Kofler: Is it on trac with the meeting keyword? 21:57:17 <pjones> Kevin_Kofler: show me where in the "feature" documentation it says something about mailing to devel-announce? 21:57:26 <pjones> Kevin_Kofler: or put the double standard away. 21:57:28 * nirik sighs. 21:57:29 <Kevin_Kofler> This is a change affecting the whole distro. 21:57:37 <Kevin_Kofler> Our policy is that such changes need to be sent to devel-announce. 21:57:47 <pjones> citation needed. 21:57:48 <Oxf13> that's a rule that doesn't exist currently 21:58:13 <mjg59> #proposal We stop talking and drink beer 21:58:18 <nirik> we just said it was a good idea... it seems poor to reject someone for following a rule we just decided. 21:58:36 <skvidal> mjg59: amendment - I'd like to get a burrito in lieu of beer 21:58:38 <nirik> well, I was hoping to discuss a Helpers pool, but we are low on time now. ;( 21:58:49 <nirik> I guess I can toss out the idea. 21:58:51 <Kevin_Kofler> You didn't want to reject it on grounds that make sense. 21:58:55 <nirik> #topic Helpers pool 21:58:56 <cwickert> +1 tp mjg59s proposal ;) 21:59:08 <nirik> So, mmcgrath mentioned this the other day on the board list. 21:59:21 <cwickert> nice idea actually 21:59:22 <nirik> Fesco has no power to compel people to work on things really. 21:59:22 <notting> nirik: i just mailed the DSO feature owners with a request for them to mail devel-announce 21:59:34 <pjones> nirik: "ex post facto" does seem to be in rather poor form, yes. 21:59:48 <ajax> i wish to note i fixed five packages for this already today 22:00:00 <nirik> but what if we produced a list of things we would like to have worked on, and further got a group of people to volenteer to work on tasks as their abilities allow. 22:00:41 <nirik> sort of a tasks board 22:00:46 <Oxf13> having a nice concise list of work that needs going ( the "open tickets" query isn't the same) would go a long way to getting some volunteers 22:00:57 <nirik> people like the idea? hate it? should I come up with something more concrete? 22:01:01 <mjg59> nirik: Even having a tasks board would be nice 22:01:14 <mjg59> I don't think there's a requirement for explicitly forming a group of volunteers 22:01:18 <notting> nirik: i love the idea. i wish i had time to work on implementing infrastructure for it 22:01:40 <abadger1999> Giving volunteers the authority to just fix those types of issues does as well; that was a blocking issue for some of the work mschwendt wanted to do. 22:01:57 <nirik> ok, I will poke at making some setup and formalizing what is involved. 22:02:02 <pjones> I think a lot of us like this idea. I would like to see something more concrete. 22:02:11 <cwickert> pjones, +2 22:02:25 <nirik> abadger1999: yeah, I would be happy to bless some of his work... like the static libs thing 22:02:28 <mmcgrath> pjones: like a bill? ;-) 22:02:40 <pjones> mmcgrath: hrm? 22:02:54 <Kevin_Kofler> So what exactly is the proposal here? Or is there none yet? 22:03:10 <nirik> Kevin_Kofler: there isn't one yet really, just asking if the idea is worth persuing. 22:03:16 <pjones> I think it's just a straw poll about the idea 22:03:30 <Oxf13> Hay I like the idea 22:03:37 <notting> as long as we don't call it a tiger team 22:03:39 <nirik> we often come up with things that we would like to have done, but no one on fesco has time 22:03:47 <pjones> Oxf13: out. 22:03:49 <Kevin_Kofler> I also like the idea. 22:03:56 <nirik> ok, thanks, will see what I can come up with. 22:04:00 <nirik> #topic Open Floor 22:04:08 <Kevin_Kofler> Right now it's usually me running around fixing other people's mess, sometimes alexlan fixing broken deps or such. 22:04:09 <nirik> we are 2min over... anything for open floor? 22:04:34 <pjones> ... 2min? not 62min? 22:04:34 <nirik> Kevin_Kofler: yeah, if we could get more people involved on a short time basis... ie, 2 hours a week or something I think it would help... 22:04:36 <Kevin_Kofler> I could very much use an official team to help me there. :-) 22:04:53 <Kevin_Kofler> (And BTW, this is also why I hate backwards-incompatible changes, I'm usually the one stuck with fixing them!) 22:05:02 <nirik> also targeted things would be nice... ie, fix all packages for this one new change, etc 22:05:30 * nirik will close the meeting in a few here if nothing comes up. 22:05:50 <nirik> Thanks for coming everyone. 22:05:53 <nirik> #endmeeting