Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on irc.freenode.net.
Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9
= Followups =
#topic #516 Updates policy adjustments/changes .fesco 516
#topic #515 Investigate a "features" repo for stable releases .fesco 515
#topic #517 Updates Metrics .fesco 517
#544 List of services that may start by default .fesco 544
== New Business ==
#563 suggested policy: all daemons must set RELRO and PIE flags .fesco 563
#275 Propose a soft-path via co-maintainer status to becoming sponsored .fesco 275
#531 Orphaned package ownership claiming clarification .fesco 531
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
kevin
Hi,
2011/2/22 Kevin Fenzi kevin@scrye.com:
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on irc.freenode.net.
Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9
= Followups =
#topic #516 Updates policy adjustments/changes .fesco 516
#topic #515 Investigate a "features" repo for stable releases .fesco 515
#topic #517 Updates Metrics .fesco 517
#544 List of services that may start by default .fesco 544
Please post a log after the meeting
== New Business ==
#563 suggested policy: all daemons must set RELRO and PIE flags .fesco 563
#275 Propose a soft-path via co-maintainer status to becoming sponsored .fesco 275
#531 Orphaned package ownership claiming clarification .fesco 531
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
kevin
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 22 Feb 2011 20:55:26 +0100 Michał Piotrowski mkkp4x4@gmail.com wrote:
Hi,
...snip...
#544 List of services that may start by default .fesco 544
Please post a log after the meeting
I always do. ;)
Note that I wasn't sure if we are even going to discuss that this week, as it's still somewhat up in the air if FPC is going to handle this fully, handle it moving forward, or not handle it at all. ;)
See the above ticket for more info and the FPC's ticket on it.
kevin
=================================== #fedora-meeting: FESCO (2011-02-23) ===================================
Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-23/fesco.2011-02-23-...
Meeting summary --------------- * init process (nirik, 17:30:01) * mclasen unable to attend today. (nirik, 17:34:39) * present mjg59 kylem notting nirik SMParrish_mobile mmaslano (nirik, 17:35:08)
* #516 Updates policy adjustments/changes (nirik, 17:35:17) * ACTION: mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases. (nirik, 17:38:17)
* #515 Investigate a "features" repo for stable releases (nirik, 17:39:33)
* #517 Updates Metrics (nirik, 17:40:53)
* #544 List of services that may start by default (nirik, 17:42:35) * LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices (nirik, 17:43:18) * LINK: https://fedorahosted.org/fpc/ticket/60 (nirik, 17:44:27) * ACTION: nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week. (nirik, 17:59:04)
* #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:59:54) * ACTION: kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are. (nirik, 18:11:18)
* #275 Propose a soft-path via co-maintainer status to becoming sponsored (nirik, 18:12:08) * AGREED: proposal from https://fedorahosted.org/fesco/ticket/275#comment:10 accepted. will work to update docs and announce. (nirik, 18:23:00) * ACTION: abadger1999 to update wiki pages. (nirik, 18:25:27) * ACTION: nirik to announce new policy (nirik, 18:25:33)
* Fedora Engineering Services (nirik, 18:25:59) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 18:26:46)
* Open Floor (nirik, 18:43:08) * LINK: https://fedoraproject.org/wiki/Mass_Rebuild_SOP (nirik, 18:48:28) * LINK: https://fedoraproject.org/wiki/Alpha_Freeze_Policy (nirik, 18:49:02) * ACTION: mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages. (nirik, 18:50:42)
Meeting ended at 18:52:11 UTC.
Action Items ------------ * mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases. * nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week. * kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are. * abadger1999 to update wiki pages. * nirik to announce new policy * mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages.
Action Items, by person ----------------------- * abadger1999 * abadger1999 to update wiki pages. * kylem * kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are. * mmaslano * mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases. * mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages. * nirik * nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week. * nirik to announce new policy * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * nirik (149) * kylem (34) * mjg59 (27) * mmaslano (24) * RobbieAB (19) * notting (18) * abadger1999 (16) * zodbot (10) * ajax (10) * SMParrish_mobile (1) * glisse (1) * daniel_hozac (1) * sochotni (1) * SMParrish (0) * mclasen (0) * cwickert (0) -- 17:30:01 <nirik> #startmeeting FESCO (2011-02-23) 17:30:01 <zodbot> Meeting started Wed Feb 23 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 <nirik> #meetingname fesco 17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 <nirik> #topic init process 17:30:01 <zodbot> The meeting name has been set to 'fesco' 17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:05 <mjg59> Hi 17:30:45 <nirik> morning everyone. 17:31:16 <sochotni> damn timezones :-) 17:32:30 <SMParrish_mobile> here but mobile so will be in and out 17:32:30 * nirik waits a bit more for quorum. 17:33:02 * notting is here 17:33:07 * mmaslano too 17:33:47 <nirik> well, thats 5 I guess... 17:34:05 <mjg59> kylem is here 17:34:10 <kylem> shh. 17:34:22 <nirik> ok, 6. ;) 17:34:39 <nirik> #info mclasen unable to attend today. 17:35:08 <nirik> #info present mjg59 kylem notting nirik SMParrish_mobile mmaslano 17:35:17 <nirik> #topic #516 Updates policy adjustments/changes 17:35:17 <nirik> .fesco 516 17:35:22 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:35:26 <nirik> ok, I didn't remember to add anything here this week. ;( 17:35:31 <nirik> will try not to slack next week. 17:35:37 <mmaslano> I have something ;-) 17:35:46 <nirik> mmaslano: go ahead. ;) 17:36:01 <mmaslano> people were asking about 3 days in testing before automatical push in alpha 17:36:07 <mmaslano> but that wasn't implemented yet 17:36:18 <mmaslano> shouldn't we change guidelines after they are implemented? 17:36:19 <nirik> yeah, it's not been done in bodhi. ;( 17:36:39 <mmaslano> we should add comment to these, which are not working 17:36:47 <nirik> yeah, agreed. 17:37:00 <nirik> would someone be willing to add a note to the updates page about this? 17:37:13 <mmaslano> I can do it if I have permission to edit it 17:37:50 <nirik> yeah, it should be open. 17:37:57 <nirik> thanks mmaslano! 17:38:17 <nirik> #action mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases. 17:38:32 <nirik> any other general updates comments/discussion? 17:39:17 <nirik> morning ajax. 17:39:22 <nirik> ok, moving along then... 17:39:33 <nirik> #topic #515 Investigate a "features" repo for stable releases 17:39:33 <nirik> .fesco 515 17:39:34 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:39:49 <ajax> sorry for the late join 17:39:52 <nirik> cwickert was going to work on this. I guess we move along until we have a more concrete proposal. 17:39:59 <nirik> no problem 17:40:43 <nirik> ok, moving on unless someone has something on this... 17:40:53 <nirik> #topic #517 Updates Metrics 17:40:53 <nirik> .fesco 517 17:40:54 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517 17:41:01 <nirik> kylem: any chance to poke at this over the last week? 17:41:33 <kylem> not yet, sorry, i've been on pto this week. 17:42:06 <nirik> ok, no problem. Anyone have any general thoughts on this before we move on? 17:42:35 <nirik> #topic #544 List of services that may start by default 17:42:35 <nirik> .fesco 544 17:42:36 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544 17:42:56 <nirik> ok, FPC voted and decided to push this to fesco. So, we are on the hook for the list and policy. 17:43:09 <kylem> oh super 17:43:18 <nirik> https://fedoraproject.org/wiki/User:Kevin/DefaultServices 17:43:37 <nirik> is the one I had from our last discussions. Basically spot's proposed guidelines and our list of exceptions. 17:43:47 <mjg59> Do we have the explicit statement from fpc? 17:43:56 <nirik> there were some concerns about us allowing local things that could have a security impact I think. 17:44:14 <mjg59> If FPC are concerned about it then FPC can take responsibility 17:44:19 <mjg59> Otherwise they get to trust our judgement 17:44:27 <nirik> https://fedorahosted.org/fpc/ticket/60 17:44:44 <nirik> "FESCo is responsible for defining an approved list of services which may autostart, and/or defining criteria to determine when and if a service may autostart." 17:45:09 <notting> oooookay then. 17:45:19 <kylem> well, that's... vagueish. :) 17:45:29 <mjg59> Works for me 17:45:30 <notting> proposal: nirik's draft, with s/FPC/FESCo/? 17:45:33 <nirik> I'll note that NetworkManager wasn't on the list we had... I guess it's dbus activated now? 17:46:05 <mjg59> I'd like to talk about what "network enabled" means 17:46:07 <notting> dbus services weren't in the list of services that 'started by default'... we can certainly investigate them 17:46:28 <mjg59> If a package can work without explicit configuration, and only binds to localhost, is that permitted or not? 17:46:59 <nirik> good question. 17:47:22 <notting> imo, yes. 17:47:33 <mjg59> I'd argue that it is, on the basis that in that case it's effectively equivalent to a daemon that has a unix socket for communication 17:47:38 <nirik> on one hand it could be usefull to people (sendmail, httpd), but on the other it means there is more security exposure from local users perhaps. 17:48:00 <mjg59> nirik: Running daemons typically have some kind of mechanism for user interaction 17:48:17 <kylem> well, ideally, even most localhost only services will drop privs after binding to their socket or whatever they need to do. 17:49:09 <nirik> sure. 17:49:19 <notting> nirik: a http server that only binds to localhost is, while not completely pointless, not useful for the normal case 17:49:32 <nirik> also agreed. ;) 17:49:45 <kylem> besides, the kernel is probably the biggest single source of local privilege escalations. 17:49:48 <kylem> ;-) 17:50:25 <nirik> yeah, we shouldn't allow the kernel to start by default, that would fix that. ;) 17:50:31 <kylem> for reals. 17:50:49 <nirik> anyhow, I could see possible reasons to adjust this, but I think it's an ok first cut. 17:50:55 <kylem> me too, looking it over 17:51:00 <notting> maybe s/network enabled/publically network facing/? 17:51:17 <mjg59> notting: People might start arguing over default firewall rules 17:51:34 <nirik> do we still have a default MTA? 17:51:39 <nirik> or did we finally quash that? 17:52:33 <kylem> i have sendmail on my f14 live install, so i assume so. :) 17:53:13 <nirik> I guess it never got finalized: https://fedoraproject.org/wiki/Features/NoMTA 17:53:31 <kylem> indeed. 17:54:25 <nirik> so, further thoughts, corrections, additions? 17:54:45 * nirik wonders if we shouldn't ask devel list for feedback and finalize next week. 17:55:23 <kylem> feedback eh.. that sounds unpleasant. ;-P 17:55:54 <nirik> could be, but there could be cases we are missing... 17:56:39 <mjg59> Yeah 17:56:41 <mjg59> Probably for the best 17:57:00 <notting> are we all at least in agreement about the general concept? 17:57:05 <kylem> yeah. 17:57:16 <notting> (b/c there will almost certainly be "TURN EVERYTHING OFF" responses, etc.) 17:57:16 * nirik thinks the general ideas are sane... 17:57:21 <nirik> yeah. 17:57:45 <mjg59> Yes 17:58:00 <mmaslano> yes 17:58:07 <nirik> ok, I can mail the list and try and gather/summarize feedback and we can revisit next week? 17:58:29 <mmaslano> sounds good 17:58:33 <kylem> perhaps you should use a smurf email account. ;-P 17:58:47 <nirik> :) 17:59:04 <nirik> #action nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week. 17:59:27 <kylem> cool, ty 17:59:28 <nirik> ok, anything else here? moving on in a few... 17:59:54 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:59:55 <nirik> .fesco 563 17:59:56 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 18:00:38 <nirik> I guess 'daemons' here means anything that listens on the network? 18:01:02 <nirik> normally we discourage changing compile flags... 18:01:24 <mmaslano> not only on network 18:01:26 <notting> it's not really defined well in the proposal 18:01:36 <mmaslano> also services like cron 18:01:57 <notting> none of the listed examples are network services (except non-default rsyslog configs) 18:02:07 <nirik> so the guidelines say: "Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there' 18:02:07 <nirik> s a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." 18:02:09 <kylem> i think this is one of those situations where we can drive upstream improvements. 18:02:21 <mjg59> So what are the costs? 18:02:26 <notting> but there also are a whole host of daemons that i'm sure aren't RELRO/PIE that aren't listed 18:02:32 <mjg59> pie can be a performance hit 18:02:38 <mjg59> What about relro? 18:02:54 <notting> e-d-s, pulseaudio, libvirtd, etc. 18:03:04 <nirik> PIE has startup time costs. 18:03:38 <notting> if it's only on startup, then the question is how much 18:03:45 <notting> 0.1 sec? less? 18:04:22 * nirik has no idea. 18:04:37 <kylem> i'm sure it's negligible. 18:04:41 <ajax> incredibly small 18:04:53 <mjg59> My question here is really "Why are these not default" 18:05:00 <nirik> are there enough advantages to consider changing them to be default? 18:05:01 <mjg59> If there's a win for daemons, why not anything else? 18:05:04 <ajax> i started building xserver PIE and the startup time difference was down in the millisecond range 18:05:06 <nirik> jinx. 18:05:49 <notting> mjg59: startup costs for a daemon that lasts the system lifetime is negligble. startup cost for shells? 18:06:03 <mjg59> notting: Still pretty low 18:06:12 <ajax> -z relro is basically always worth doing though 18:06:12 <daniel_hozac> there's also the attack vector. 18:06:33 <ajax> if for no other reason than it means your linker can actually implement C's 'const' keyword correctly 18:06:34 <kylem> mjg59, agreed. 18:06:44 <nirik> sounds like relro might not be available on all arches? so could be an issue for secondary, but they probibly have their own flags already anyhow. 18:06:49 <mjg59> It sounds more like it should be a win for anything that consumes untrusted data 18:06:51 <kylem> perhaps the gcc folks are just overly conservative. 18:07:14 <ajax> (otherwise, const void *foo = &bar; is emitted in .data, since it requires a relocation and can't be resolved until ld.so time) 18:07:20 <mjg59> So how about we counterpropose that we just enable this globally in the F16 cycle? 18:07:45 <mjg59> And get some toolchain people to look into it? 18:07:48 <kylem> raisonable. given it requires yet another mass rebuild. 18:07:50 * nirik is fine with that, but we might gather info from tools folks about it. 18:08:14 <kylem> indeed, let's ask them why this isn't the default. :) 18:08:22 <ajax> PIE is... debatably worthwhile as a global thing. it doesn't really win you much besides the ASLR bonus (and the ability to link against executables as though they were DSOs) 18:09:05 <mjg59> The ASLR bonus is pretty much what we're looking at here 18:09:18 <nirik> proposal: suggest making it default in f16, ask for feedback on that and revisit. 18:09:22 <kylem> perhaps we should also investigate what other distros are doing. 18:09:25 <mjg59> Does it make a big difference on 64-bit as well, or is it mostly useful on 32? 18:09:30 <kylem> we don't want a randomization gap. 18:10:22 <mjg59> Strategic Randomisation Reduction Treaty 18:10:25 <nirik> proposal2: someone talks to toolchain folks and gathers info for us and we revisit next week. ;) 18:10:33 <kylem> i'll do that 18:10:47 <kylem> (promise. no backsies, no fingers crossed behind my back. :P) 18:10:50 <notting> kylem: need to send patch for -zmineshaft option? 18:10:57 <nirik> kylem: cool! 18:11:09 <kylem> notting, NO FIGHTING IN THE WAR ROOM 18:11:18 <nirik> #action kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are. 18:11:27 <nirik> ok, anything else on this? 18:11:34 <mjg59> Don't think so 18:12:08 <nirik> #topic #275 Propose a soft-path via co-maintainer status to becoming sponsored 18:12:08 <nirik> .fesco 275 18:12:09 <zodbot> nirik: #275 (Propose a soft-path via co-maintainer status to becoming sponsored) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/275 18:12:14 <nirik> ok, this is an ooooold ticket. ;) 18:12:28 <nirik> we discussed it long ago, and it kind of stalled. 18:13:02 <nirik> basically we have now a limited way for people to become packagers: submit new packages for review and get sponsored. 18:13:42 <nirik> This ticket is to try and expand that and allow us to add comaintainers of existing packages 18:14:16 <RobbieAB> Well, speaking as an outsider, I can honestly say the chances of that appealing are low. :s 18:14:59 <nirik> the problem is determining if someone has the skills/ability to maintain packages, and how to determine that. 18:15:01 <kylem> tbh i don't think lowering the bar is a useful thing. we need more people reviewing, not more packages for them to review. 18:15:15 <RobbieAB> I'm more likely to sign up to help with a package I like and care about than try and join with a new one. 18:15:38 <nirik> RobbieAB: right, so the proposed policy here would be appealing to you. 18:15:49 <nirik> kylem: this would not add more packages to review. 18:16:02 <nirik> let me throw up some cases that have hit recently: 18:16:14 <RobbieAB> nirik: Yes. :) I just meant the "current official" policy. 18:16:38 <nirik> upstream maintainer of a project wants to help maintain the fedora package. The fedora maintainer would love to have the help and knows that they know packaging and the package quite well. 18:17:04 <nirik> Currently they would have to submit a review of a package they didn't care about or have time to maintain, get that though the process then add as co-maintainer of the one they care about. 18:18:03 <nirik> another case is: some packages are poorly or not at all maintained. Someone interested in them submits patches to fix them, wants to maintain them moving forward... 18:18:12 <nirik> but they have to submit a review of a package they didn't care about or have time to maintain, get that though the process then add as co-maintainer of the one they care about. 18:18:34 <kylem> sorry, internet hiccup 18:18:58 <ajax> if the existing maintainer trusts a new person to be a co-maintainer, why would we disagree? 18:19:10 <nirik> One of the downsides to the proposed policy change in comment10 is that someone could get in with that policy, not know much or be evil, and get added as a comaintainer on another package where the maintainer didn't know they were new/didn't know/were evil. 18:19:40 <nirik> I think that risk is pretty low, as currently someone could get in as a maintainer of a small/easy/useless package and do the same thing. 18:20:01 <kylem> well, ideally, there's still the bar to provenpackager. 18:20:01 <nirik> so, all that said, I am +1 for abadger1999's proposal in https://fedorahosted.org/fesco/ticket/275#comment:10 18:20:02 <ajax> also, the bodhi process should limit the amount of damage you could do with that in any case 18:20:51 <nirik> I think having fesco folks know/sponsor should give us an idea of how popular this is or what pitfalls might happen due to it. 18:21:36 <ajax> yeah, +1 18:21:43 <nirik> so, votes? counter opinions? 18:22:00 <mmaslano> sounds good +1 18:22:04 <notting> i'm +1 to the proposal. can't imagine too many cases where we'd say no 18:22:24 <kylem> +1. 18:22:33 * nirik notes thats +5. 18:23:00 <nirik> #agreed proposal from https://fedorahosted.org/fesco/ticket/275#comment:10 accepted. will work to update docs and announce. 18:23:09 <abadger1999> Note -- the idea is not that fesco would have to strictly review people asking to be sponsored this way, just that there needs to be a way to connect package owners willing to mentor someone with someone who can sponsor. 18:23:38 <nirik> abadger1999: yeah, I can't see us not doing it, but it allows us to see how popular this will be and watch the people who are added this way.. 18:23:45 <abadger1999> and fesco seemed to fit the latter/has a ticketing system/etc. 18:23:52 <abadger1999> <nod> 18:24:05 <nirik> so, what do we need to do to make this live? just update wiki pages and announce? 18:24:10 <abadger1999> yep. 18:24:16 <nirik> we also need to change the package maintainer responsibilities pages right? 18:24:19 <abadger1999> I'll update the wiki pages now if you guys will announce. 18:24:34 <abadger1999> You could review that page 18:24:46 <nirik> ok. Cool. 18:24:56 <abadger1999> I thought the previous changes encompassed this but I haven't looked recently. 18:25:08 <nirik> let me know when all is done and I can announce... 18:25:11 <abadger1999> k 18:25:18 <nirik> thanks abadger1999! 18:25:26 <abadger1999> No problem 18:25:27 <nirik> #action abadger1999 to update wiki pages. 18:25:33 <nirik> #action nirik to announce new policy 18:25:39 <nirik> RobbieAB: you still around? 18:25:43 <RobbieAB> I am. 18:25:59 <nirik> #topic Fedora Engineering Services 18:26:12 <nirik> So, FES kind of became idle there for a while... 18:26:25 <nirik> mmgrath was driving it, and he moved on to other things... 18:26:39 <nirik> however, RobbieAB has stepped up to help move things forward again. :) 18:26:46 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6 18:27:05 <nirik> RobbieAB: so, any news from things over the last week? do we need more tickets or more engineers? 18:27:36 <RobbieAB> At the moment, I am slowly prodding people and trying to get things moving again. 18:27:39 <kylem> RobbieAB, care to introduce yourself to the class? :) 18:27:50 * abadger1999 has seen that thom has been active on the C bundled library tracker :-) 18:29:41 <RobbieAB> Hi, I;m Robert, currently in Dublin, and in a moment of madness I let nirik and mmcgrath talk me into trying to run FES# 18:30:12 <kylem> cool, nice to meet you 18:30:29 <nirik> I think we could look at setting up 'fix rawhide broken deps' and 'fix f15 broken deps' tickets at some point... 18:30:33 <RobbieAB> I ran a quick role call and got 7 or 8 responses. Thom was one of them and I asked him to poke that C bundled library tracker. 18:30:47 <nirik> if other fesco folks have small nice engineering tasks, please do file them. 18:31:34 <RobbieAB> Is "fix rawhide broken deps" actually within the guidelines for FES? It strikes me as a ticket that will grow as much as it shrinks. 18:31:54 <RobbieAB> (A point that occured to me when thinking about it today) 18:31:58 <abadger1999> It is -- but some tickets will shrink and grow. 18:32:08 <nirik> There was also some movement on the cross desktop help/support links stuff... (talks with docs and websites) 18:32:21 <nirik> yeah, some will just grow/shrink over time. 18:32:34 <nirik> I would hope a f15 broken deps fixing would shrink to 0 before release. ;) 18:33:03 <RobbieAB> Well, F15 broken deps has a clear end point. 18:33:18 <nirik> yeah, rawhide keeps on rollin. 18:33:34 <abadger1999> bundled libraries will also shrink and grow over time, although with a slower rate of change than broken deps :-) 18:33:57 <RobbieAB> nirik: Which is why I am wondering if rawhide fits within "FES specalizes on specific tasks with a beginning, middle and end" 18:34:40 <nirik> RobbieAB: yeah, although each particular broken package has a beginning,middle,end part to fixing it... so the parts of the task go away as they are fixed. 18:34:59 <nirik> in any case, rawhide isn't as important as f15... 18:35:19 <RobbieAB> Yeah, that is the logic I am using. I can set-up an F15 tracker anyway. 18:35:41 <nirik> cool. 18:35:57 <nirik> ok, anyone have anything further to ask RobbieAB or related to FES? 18:36:05 <mmaslano> hm, I thought broken depencies should be solved by maitainers of these packages? 18:36:29 <nirik> mmaslano: sure, normally so... but sometimes if a provenpackager has time and the main maintainer is busy they appreciate the help 18:37:00 <mmaslano> nirik: ok 18:37:15 <RobbieAB> Perhaps it should be set-up so a maintainer can ask for us to look at it? 18:37:44 <abadger1999> RobbieAB: thom has been doing a great job with triage on bundled libs -- he might be able to do with some additional help moving on to the next stage -- helping generate patches to fix packages where the maintainer doesn't have the time to do the coding themselves. 18:37:45 <nirik> RobbieAB: yeah, we could do that... although if they are busy they might not have time to ask... 18:38:15 <nirik> I think a 'ask maintainer and wait for a response for a bit first' might work better for those. 18:39:06 <RobbieAB> Ok, will note that. 18:39:21 <nirik> anyhow, I'd like to thank RobbieAB for taking this on, and am glad to see FES moving along again. :) 18:39:34 <RobbieAB> abadger1999: Possibly, but if that is me, it will be the blind leading the blind. :) 18:39:53 <nirik> if we end up with more engineers than tickets, we might look at opening up things to other groups to file things (the board, sigs, etc) 18:40:03 <abadger1999> <nod> If someone steps up and says I know C, what can I do? you can throw them in there :-) 18:40:03 <RobbieAB> There was one that Thom raised a question on: lua-sec 18:40:30 <RobbieAB> Which had the original filer of the review request say he was no longer interested in. 18:41:07 <RobbieAB> abadger1999: Thom claims he knows C too... It's why I pointed him at that ticket. :) 18:41:21 <abadger1999> Cool 18:41:40 <nirik> ok, anything else to discuss here? or shall we move on? 18:41:53 <abadger1999> RobbieAB: POint me at the lua-sec thing and I'll look at it after the meeting with you. 18:42:55 <RobbieAB> abadger1999: Will do. :) 18:43:08 <nirik> #topic Open Floor 18:43:16 <nirik> Anyone have anything for open floor? 18:43:33 <mmaslano> yes 18:43:44 <mmaslano> number of broken packages in F-15 ;-) 18:44:29 <mmaslano> could we move next mass-rebuild? 18:44:30 <nirik> yeah, broken deps you mean? 18:44:39 <mmaslano> this one was done too late 18:44:45 <nirik> yeah, the mass rebuild timing was unfortunate here... 18:44:53 <mmaslano> or alpha freeze should be done later 18:45:25 <nirik> I think it was unavoidable due to dgilmore traveling before that... 18:45:32 <mmaslano> I have there a lot of packages, I'm not aware if they are fixed or not, because they are in "testing queue" 18:45:34 <glisse> btw it seems gcc 4.6 + -fno-omit-frame-pointer doesn't play well with mesa 18:45:41 <nirik> but yeah, doing sooner would be better. 18:45:44 <mmaslano> the F-15 branch report doesn't help me at all :-/ 18:46:04 <nirik> mmaslano: yeah, doesn't help that we are in alpha freeze right now, so hard to tell how much is still messed up. 18:46:16 <nirik> as soon as that unblocks it should help a lot. 18:47:06 <mmaslano> also there was no message about freeze or I miss it 18:47:09 <nirik> not sure what else we can really do right now. ;( But we can do better next time. 18:47:35 <mmaslano> yes, if we have some how to mass rebuild, it should be there ;-) 18:48:14 <nirik> there was a note about the freeze in the mass rebuild announcement... but yeah, another would be good. 18:48:28 <nirik> https://fedoraproject.org/wiki/Mass_Rebuild_SOP 18:49:02 <nirik> https://fedoraproject.org/wiki/Alpha_Freeze_Policy 18:49:23 <nirik> could you add notes to those? 18:49:56 <mmaslano> ok, I'll edit it, thanks 18:50:23 <nirik> thanks. 18:50:42 <nirik> #action mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages. 18:50:54 <nirik> ok, anything else? or shall we call this a meeting? 18:51:27 * nirik listens to the crickets chirp 18:51:30 <kylem> heh 18:51:38 <nirik> ok, will close out in a minute if nothing else comes up. 18:51:39 <kylem> nothing on my end... just writing up my action item 18:52:08 <nirik> Thanks everyone! 18:52:11 <nirik> #endmeeting
On Wed, 23.02.11 11:53, Kevin Fenzi (kevin@scrye.com) wrote:
- #544 List of services that may start by default (nirik, 17:42:35)
- LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices (nirik, 17:43:18)
- LINK: https://fedorahosted.org/fpc/ticket/60 (nirik, 17:44:27)
- ACTION: nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week. (nirik, 17:59:04)
This list does not mention bus services at all. Traditionally they weren't really that visible and if they were bus activatable they were always enabled with no way to disable them. With the advent of systemd we now ideally make them visible in the list of active services like any other service.
Traditionally bus activated services were enabled by default. I think this kinda made sense, so I don't think this new policy should now force the maintainers of udisks, pk, CK, upower and so on to disable their services by default. That would be backwards.
And yupp we have more bus services on a default fedora install than non-bus services.
Lennart
On Wed, 23 Feb 2011 20:02:48 +0100 Lennart Poettering mzerqung@0pointer.de wrote:
This list does not mention bus services at all. Traditionally they weren't really that visible and if they were bus activatable they were always enabled with no way to disable them. With the advent of systemd we now ideally make them visible in the list of active services like any other service.
Yeah, I noted that in the meeting...
Traditionally bus activated services were enabled by default. I think this kinda made sense, so I don't think this new policy should now force the maintainers of udisks, pk, CK, upower and so on to disable their services by default. That would be backwards.
And yupp we have more bus services on a default fedora install than non-bus services.
Whats the easy way to list them? To show if they are set to start by default or not? (or does that make sense for dbus at all, since they would start when asked to?)
kevin
On Wed, Feb 23, 2011 at 2:27 PM, Kevin Fenzi kevin@scrye.com wrote:
Whats the easy way to list them?
ls /usr/share/dbus-1/system-services
(There is a dbus method for this too, "ListActivatibleServices", but just "ls" is easier)
To show if they are set to start by default or not? (or does that make sense for dbus at all, since they would start when asked to?)
What Lennart is saying is that in Fedora <= 14, they would always start when requested (any uid could do so), and dbus exposed no administrator interface to change this (other than "rm" on the .service file) but with systemd it's possible.
On 02/23/2011 07:53 PM, Kevin Fenzi wrote:
===================================
#fedora-meeting: FESCO (2011-02-23)
Action Items
- mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases.
- nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week.
- kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are.
- abadger1999 to update wiki pages.
- nirik to announce new policy
- mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages.
FYI I updated these guidelines about rebuilds [1] and update policy [2] [3] [4]. There are sometimes outdated information or same information on more pages. It would be nice to have a maintainer of important pages.
[1] https://fedoraproject.org/wiki/Mass_Rebuild_SOP [2] https://fedoraproject.org/wiki/Updates_Policy [3] https://fedoraproject.org/wiki/Branch_Freeze_Policy [4] https://fedoraproject.org/wiki/Alpha_Milestone
-
Colin Walters -
Kevin Fenzi -
Lennart Poettering -
Marcela Mašláňová -
Michał Piotrowski