Minutes/summary for 2010-02-09 FESCo meeting
kevin at scrye.com
Tue Feb 9 22:06:47 UTC 2010
#fedora-meeting: FESCO (2010-02-09)
Meeting started by nirik at 20:02:07 UTC. The full logs are available at
* 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)
* Packaging: SRPM Buildtime macros -
* AGREED: Packaging change is approved. (nirik, 20:08:34)
* Packaging: Emphasize correct SF.net SourceURL:
* AGREED: Packaging change is approved. (nirik, 20:10:39)
* Packaging: Updated Python Guidelines
* AGREED: Packaging change is approved. (nirik, 20:19:57)
* #297 Please consider the idea of a security (privilege escalation)
policy (nirik, 20:20:45)
* 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,
* 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
* AGREED: This proposal is rejected. The feature will stay in place.
* Please announce feature changes that impact other packages on
fedora-devel-announce to reach the most maintainers (nirik,
* devel-announce at 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_downloads_admonition
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_escalation_policy
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.html
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100209/e1edd2ca/attachment-0001.bin
More information about the devel