18:30:00 <nirik> #startmeeting FESCO (2010-10-27)
18:30:00 <zodbot> Meeting started Wed Oct 27 18:30:00 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:01 <nirik> #meetingname fesco
18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
18:30:01 <nirik> #topic init process
18:30:01 <zodbot> The meeting name has been set to 'fesco'
18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
18:30:37 <pjones> yo.
18:30:39 <nirik> who all is around for meeting?
18:32:04 <pjones> just me and you I guess.
18:32:06 * notting is here
18:32:06 * nirik wonders if we have quorum today.
18:32:08 <pjones> ;)
18:32:10 <kylem> yo.
18:32:31 <pjones> mjg59 was around a few minutes ago.
18:34:11 * nirik waits a few to see if we get one more person for quorum
18:35:28 <mjg59> pjones: Hi
18:35:35 <mjg59> Sorry, briefly distracted
18:35:50 <nirik> cool. I think we can go ahead and get started.
18:36:01 <cwickert> am I late?
18:36:06 <nirik> cwickert: nope, just in time. ;)
18:36:09 <cwickert> ;)
18:36:13 <mjg59> cwickert: Fashionably so
18:36:20 <nirik> #topic Updates policy / Vision implementation status
18:36:20 <nirik> .fesco 351
18:36:20 <nirik> .fesco 382
18:36:22 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
18:36:26 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
18:36:31 <nirik> SMParrish was going to look at more stats stuff.
18:36:38 <nirik> Also, I talked with lmacken about bodhi stats.
18:37:08 <nirik> He was going to generate them for us so we could see what was in them, and also try and do a 'pre release' 'post release' split for f14
18:37:32 <nirik> the next bodhi version will allow (I think) running them from cron/regularly.
18:38:21 <nirik> It seems like we are not making much progress to finishing this up. Anyone have ideas on how we could finish things before next elections?
18:38:32 * SMParrish sorry I'm late.
18:39:01 <SMParrish> nirik: was travelling last week. just got home yesterday and have not had time to work on the metrics issue
18:39:14 <nirik> ok.
18:39:18 <cwickert> I think we still suffer from unclear board statements
18:39:33 <pjones> cwickert: I think we're always going to suffer from that
18:39:52 <pjones> we should just interpret them as best we can and if that's really something they didn't want then we do it again :/
18:39:55 <cwickert> I was talking to some board members and they were not happy with the "only security and bugfixes" thing ether
18:40:42 <notting> and...? internal board politics are a matter for the board.
18:41:19 <mjg59> The board's statement explicitly says " Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues. "
18:41:22 <nirik> I'd really like to see us try the current policy for a bit. It may be too conservative, but we can adjust it if so down the road.
18:41:42 <nirik> we also were going to look into a 'new features' repo.
18:42:46 <nirik> perhaps we could set action items and people on the remaining tasks?
18:42:58 <nirik> SMParrish: work with lmacken on metrics ?
18:43:08 <cwickert> speaking of that, I was supposed to write a propsal on the new-features repo
18:43:19 <nirik> cwickert: yeah.
18:43:24 <kylem> i think this is mostly just a reflection fo the project as a whole, looking at #fedora-dveel you'd be hard pressed to find unilateral agreement on the interpretation of our vision.
18:43:58 <SMParrish> nirik: yes i will get with lmacken on the metrics issue
18:44:02 <pjones> nirik: yeah, I'm with you in that we need more observation to see what we've done.
18:44:03 <cwickert> i have two problems: it is hard to find the status quo as there are a lot of outdated update-something pages in the wiki now
18:44:25 <nirik> we should nuke or redirect the old ones to the current one.
18:44:30 <pjones> yep
18:44:40 <cwickert> the second problem is: two weeks ago a lot of questions were raised in the meeting
18:44:48 <cwickert> but they have not made it into the wiki
18:45:13 <nirik> questions on the new feature repo? or ?
18:45:19 <cwickert> ys
18:45:21 <cwickert> yes
18:45:33 <cwickert> how things work in bodhi and all that
18:45:46 <cwickert> but they are not on https://fedoraproject.org/wiki/Talk:Stable_release_updates_vision_implementation_ideas
18:46:00 <cwickert> I guess I'll have to dig in the meeting logs
18:46:00 <nirik> https://fedoraproject.org/wiki/Updates_Policy
18:46:25 <nirik> that should be the page maintainers look at/follow.
18:46:51 <cwickert> there is a few more
18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches
18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy
18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy
18:46:59 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
18:46:59 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
18:47:05 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision
18:47:15 <nirik> the last one is the vision from the board.
18:47:34 <notting> anything in the User: namespace should obviously not be policy
18:47:37 <pjones> seems like we should make a category template for the various User: Proposal: ones and tag them so it says something at the top of the page or something.
18:47:37 <nirik> the rest should be removed probibly. (Although we do still have things to implement from the implementation_ideas page)
18:47:52 <pjones> (not that I've got any idea how to do that on the wiki)
18:48:21 <cwickert> the problem is there are conflictins statements
18:48:22 <abadger1999> pjones: Could just use {{draft}}
18:48:35 <pjones> nirik: I'm not sure I'm okay with us deciding to remove stuff under User: (unless it violates various codes of behavior of course)
18:48:38 <pjones> abadger1999: yeah
18:48:48 <abadger1999> pjones: Although you might want something that also says "rejected" or "alternative was implemented"
18:48:51 <pjones> abadger1999: I was thinking something a little stronger than that, but that's certainly the right idea.
18:48:52 <nirik> pjones: true. Althought we could add a 'note: this is NOT policy' or something.
18:49:22 <cwickert> e.g. the last paragraph of https://fedoraproject.org/wiki/Package_update_acceptance_criteria is not exactly what https://fedoraproject.org/wiki/Updates_Policy says
18:49:37 <pjones> nirik: yeah, something like {draft} but maybe a little more "don't use this as reference" since lots of people are used to reading draft documents as the canonical source for data ;)
18:50:03 <nirik> cwickert: about exceptions?
18:50:15 <cwickert> nirik, about criteria
18:50:33 * nirik is not following.
18:50:56 <nirik> The critical path / other updates sections?
18:51:02 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria#All_other_updates is different from https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
18:51:12 <cwickert> at least slightly
18:51:47 <cwickert> the information should be one one single page to make sure we have no contradictions and no redundancy
18:51:48 <nirik> well, I thought I copied it from the one page to the new one.
18:52:12 <nirik> yes, I copied Package_update_acceptance_criteria data into Updates_Policy
18:52:17 <nirik> where I messed up we should fix it.
18:52:38 <cwickert> ok, what else is left to do except a clean-up?
18:53:10 <cwickert> i guess https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
18:53:21 <nirik> if you see issues that are obviously me messing up the copy, just fix them. If it's something that should be changed, bring it up here and we can vote on it.
18:53:28 <nirik> right, we need:
18:53:31 <cwickert> i hope I can come up with a proposal for the next meeting, I'm just too busy in my dayjob
18:53:33 <nirik> metrics: how well is this working
18:53:44 <nirik> new feature repo: if it's fesable
18:53:47 <cwickert> what kind of metrics would that be?
18:54:26 <cwickert> i mean, how to judge if something is working? can we count how many people are cheating in bodhi?
18:54:37 <nirik> anything we could gather that would apply to: "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements"
18:55:23 <nirik> we can count numbers of updates, numbers of bodhi comments/tests, number of karma submitters, number of bugs, etc.
18:55:49 <cwickert> so? what do we gain when counting the number of comments in bodhi?
18:56:05 <nirik> an increase in testing?
18:56:07 <cwickert> if even rel-eng gives "proxy karma" without testing
18:56:23 * nirik is happy to listen to any other metrics you think we should gather.
18:56:50 <cwickert> I'm sorry, I don't have any
18:57:07 <cwickert> but what I see at https://admin.fedoraproject.org/updates/openbox-3.4.11.2-5.fc14 makes me think we are not doing more testing than before
18:57:17 <wwoods> you're wrong.
18:57:20 <wwoods> provably so.
18:57:21 <cwickert> just an example, I'm sure there are plenty of this
18:57:33 <wwoods> that is an anecdote; the data say otherwise.
18:57:35 <nirik> the plural of anecdote is not data.
18:57:52 <nirik> anyhow, lets see what SMParrish comes up with and go from there?
18:58:05 <cwickert> wwoods, if two out of three testers are faking results, what have we gained?
18:58:17 <mjg59> One tester
18:58:25 <wwoods> furthermore, if that were actually correct - what would be the correct solution? Do *less* testing?
18:58:28 <cwickert> well...
18:58:34 * nirik notes we are over 15min on this topic.
18:59:11 <cwickert> wwoods, not have technical limitations that make people abuse the guidelines.
18:59:29 <wwoods> finding problems with a process should probably cause you to look for ways to improve the process
18:59:32 <cwickert> anyway, I'm happy for all numbers we can gather, but I doubt they are meaningful
19:00:00 <nirik> ok, anything further on updates? or shall we move on?
19:00:01 <wwoods> so - constructive suggestions on that topic would be excellent! probably not here and now, though.
19:00:09 <cwickert> +1
19:00:51 <nirik> #action cwickert will work on new features repo ideas
19:00:59 <nirik> #action SMParrish will work on metrics
19:01:03 <nirik> #topic #416 Set EOL Date For Fedora 12
19:01:03 <nirik> .fesco 416
19:01:08 <zodbot> nirik: #416 (Set EOL Date For Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/416
19:01:11 <cwickert> can we also have somebody to clean up the wiki?
19:01:15 <nirik> Since F14 was pushed out a week, should we move EOL for F12 as well?
19:01:27 <nirik> cwickert: I can try, but I also have been very busy.
19:01:38 <pjones> nirik: yeah, we should keep them in lock-step I guess.
19:01:45 <cwickert> +1
19:02:12 <ajax> sure, why not
19:02:14 <mjg59> nirik: +1
19:02:29 <nirik> ok, +1 from me too.
19:02:36 <Southern_Gentlem> suggest 12/1/2010
19:02:44 <nirik> Further on this topic, instead of us voting on it, do we want to just setup a general rule?
19:02:50 <pjones> nirik: yes
19:02:57 <nirik> ie, nearest weekday to 1 month from release.
19:03:00 <notting> ACK
19:03:04 <pjones> +1
19:03:07 <mjg59> +1
19:03:12 * mclasen is all for auto-EOL
19:03:13 <mclasen> +1
19:03:17 <ajax> +1
19:03:25 <nirik> that would make it 2010-12-02 for this case tho (2010-12-03 was suggested)
19:03:58 * notting is +1 to lockstep, +1 to auto-lockstep
19:04:20 <pjones> nirik: nearest to or first after?
19:04:31 <kylem> +1.
19:04:32 <nirik> pjones: we could do that I suppose.
19:04:41 <pjones> not that I really care.
19:04:41 * nirik doesn't feel too strongly either way.
19:05:22 <nirik> anyone object to 'nearest weekday 1 month from release +1 day' ?
19:05:37 <ajax> fine with me
19:05:50 <cwickert> same here
19:05:56 <Southern_Gentlem> why the +1 day?
19:06:11 <kylem> latency.
19:06:12 <kylem> :P
19:06:24 <nirik> I guess that just makes it more complex.
19:06:42 <nirik> so, lets just do nearest weekday to 1 month after release.
19:07:07 <pjones> I'm thinking "first weekday after" just because that means we prefer mondays to fridays.
19:07:18 <pjones> (well, on or after.  gah.)
19:07:27 <ajax> also fine with me.
19:07:33 <nirik> #agreed F12 eol will be 2010-12-02, moving forward eol dates will be the nearest weekday to 1 month from release
19:07:42 <nirik> pjones: I don't know that it matters...
19:07:59 <pjones> fair enough.
19:08:19 <nirik> Some topics that are just announcements/notices:
19:08:21 <nirik> #topic Elections coming up.
19:08:31 <nirik> elections are starting up for board, fesco, famsco
19:09:18 <nirik> Everyone should vote. ;)
19:09:25 <kylem> lol
19:09:27 <pjones> +1
19:09:31 <ajax> early and often.
19:09:33 * nirik looks to see who is up from fesco...
19:09:44 <notting> ajax, cwickert, pjones, mjg59
19:09:45 <mjg59> Me, ajax, pjones, cwickert?
19:09:47 <mjg59> Yeah
19:09:52 <rbergeron> ...or nominate themselves for open positions :)
19:09:57 <nirik> Adam Jackson (ajax), Christoph Wickert (cwickert), Peter Jones (pjones), and Matthew Garrett (mjg59)
19:10:10 * nirik thanks notting for updating the page.
19:10:16 <nirik> http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
19:10:32 <nirik> moving on...
19:10:39 <cwickert> I haven't seen an announcement on devel list
19:10:39 <nirik> #topic Kudos for F14 release
19:10:42 * Southern_Gentlem crosses fingers that they all reapply for the job
19:10:58 <nirik> cwickert: yeah, not sure who is coordinating this time. ;( will find out tho.
19:11:11 <notting> nirik: i think everyone's coordinating their own?
19:11:24 <notting> do we want to designate someone to post to the devel list?
19:11:31 <nirik> I'd like to thank all the maintainers, qa folks, users and rel-eng for making F14 such a smooth release. :)
19:11:37 <cwickert> +1
19:11:39 <nirik> notting: oh, usually there's a coordinator.
19:11:51 <cwickert> especially for QA, adamw does a great job
19:12:10 <nirik> seconded. ;)
19:12:27 * adamw would like to thank all the people who did all the work
19:12:57 <nirik> I can find out if there is a coordinator this time, and if not, at least mail the devel-announce list about nominations being open.
19:13:14 <SMParrish> +1 kudos to all
19:13:20 <notting> nirik: wfm
19:13:22 <cwickert> nirik, there was something in the board list about coordination
19:13:24 <notting> nirik: thanks!
19:13:53 <nirik> ok, I had one f15 feature that I didn't note in time for the agenda. We could do it now, or wait until next week?
19:14:51 <cwickert> how about now?
19:14:54 <mjg59> Sure
19:14:55 <abadger1999> pjones, cwickert: Re: a template like {{draft}} I just made this for ya'll: https://fedoraproject.org/wiki/Template:Draft/declined  Go ahead and change it if you want something slightly different.
19:15:12 <nirik> abadger1999: thanks!
19:15:15 * abadger1999 sorry for jumping in with that but has to leave soon
19:15:16 <nirik> #topic #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID )
19:15:16 <nirik> .fesco 480
19:15:17 <zodbot> nirik: #480 (F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/480
19:15:36 <pjones> abadger1999: excellent.
19:15:57 * cwickert looks
19:16:15 <nirik> I'm +1 on this. I don't know how hard it's going to be, but if anyone can get it to happen dwalsh can. ;)
19:16:39 <ajax> i'm only barely +1 to this since i still think capabilities are far too coarse-grained to be of much use
19:16:46 <mjg59> I'm also +1, though concerned about the degree to which things may end up breaking
19:17:01 <pjones> I'm +0 to this for the sam reason ajax is barely +1 to it.
19:17:02 <mjg59> I can't see it /reducing/ security, but I don't think it's as big a win as it could be
19:17:22 <ajax> but f15's xserver is already shipping non-setuid, so, whatever.
19:17:50 <notting> ajax: sys_admin or raw_io?
19:18:01 <ajax> notting: both those and also dac_override
19:18:07 <mclasen> is the dependency list on the tracker bug complete ?
19:18:11 <mclasen> 24 sounds low...
19:18:29 <nirik> it does seem low yeah.
19:19:14 <notting> ajax: that doesn't remove much. if anything.
19:19:17 <ajax> notting: if that sounds like zero effective reduction in privileges, that's because it's no effective reduction in privs.
19:19:22 <ajax> so, like i said.
19:19:38 <ajax> hey cool we can use capabilities!  if only that were meaningful!
19:19:50 <mclasen> would be good if the feature page had some advice on how to find out the 'correct caps' to use
19:19:56 <notting> i'm moderately for the idea, but it remains to see if we'll come up with anything useful
19:20:17 <ajax> xserver might be a special case, but really anything that needs dac_override or sys_admin is trivially equivalent to root
19:20:27 <pjones> mclasen: the problem is that the capabilities are so poorly thought out that that's a non-trivial (and possibly non-meaningful) exercise.
19:20:41 <mclasen> and one that breaks at runtime if you get it wrong ?
19:20:48 <ajax> mclasen: indeed.
19:20:49 <pjones> yep.
19:21:41 <ajax> i would say i get the feeling the caps were designed by someone who had never tried to root a machine, but that would imply that i thought they were designed period.
19:21:54 <mclasen> so we need individual testing attention for each binary that gets that treatment, I guess
19:22:42 <ajax> yeah.  again, if dan wants to drive that, great.
19:22:58 <notting> ajax: 'designed by someone who only wanted to remove setuid from ping, other things are an afterthought'?
19:23:34 <ajax> notting: that's a bit closer, yeah.
19:24:27 <ajax> anyway.  +1 to the feature even though it's of the most marginal utility.
19:25:04 <nirik> so where are we here...
19:25:11 <nirik> +3 I see
19:25:19 <cwickert> +1, see what it brings
19:25:31 <SMParrish> +1
19:26:13 <pjones> I guess I could be +1 despite limited utility.  It's not a bad thing to do per se.
19:26:46 <nirik> #agreed the feature is approved.
19:26:50 <nirik> #topic Open Floor
19:26:55 <nirik> Anything for open floor?
19:26:57 * mclasen adds comments to the feature page and gives a +1
19:27:00 <ajax> hah!  the bugs even cite Xorg as the example.
19:27:09 * ajax ahead of the curve
19:27:32 <abadger1999> https://fedorahosted.org/rel-eng/ticket/4224
19:27:39 <nirik> ah yes,
19:27:56 <nirik> #topic break build inheritance between F14 and F15 and update deltarpm files
19:28:07 <nirik> .rel-eng 4224
19:28:09 <zodbot> nirik: Ticket #4230 (task created): build tag override request for eclipse-3.6.1-2.fc14 || Ticket #4229 (task closed): Retire OpenOffice.org from F15 || Ticket #4229 (task created): Retire OpenOffice.org from F15 || Ticket #4228 (task created): Buildroot override request for libtorrent || Ticket #4227 (task created): tag request: dist-f14-override for libgda-4.2.0-1.fc14 || Ticket #4226 (defect closed): (11 more messages)
19:28:15 <abadger1999> Oxf13: You around for this?
19:28:16 <nirik> oops. thats not right. ;)
19:28:34 <ajax> eesh, this looks vile.
19:29:15 <nirik> yes, yes it does.
19:29:36 <abadger1999> This comment is probably the best summary of the problem: https://fedorahosted.org/rel-eng/ticket/4224#comment:6
19:29:51 <abadger1999> The initial report has the proposed solution.
19:30:31 <nirik> given that it falls back to the full rpm ok and that deltas are only somewhat usefull in rawhide anyhow...
19:30:32 <abadger1999> I think Oxf13 would like fesco input because we normally don't break build inheritance by itself... although we do in practice if we do a mass rebuild 9but once again, that would normally be later in the cycle)
19:30:42 <nirik> this is just f15 right?
19:30:48 <abadger1999> Correct.
19:30:55 * nirik whews
19:31:11 <abadger1999> It won't affect f14 as jnovy isn't going to push the new xz back.
19:31:19 <nirik> thank goodness.
19:31:32 <mclasen> whats the consequence of broken build inheritance ? people have to build their stuff for rawhide ?
19:31:40 <mclasen> doesn't sound too onerous to me
19:31:55 <ajax> mclasen: yeah, f14 builds won't automatically bubble to f15.
19:31:56 <abadger1999> mclasen: Correct.  A build for F14 won't automatically go to F15.
19:32:11 <nirik> if we nuke existing deltas does that mean we would need a compose to rebuild them all? (ie, a long ass one)
19:32:35 <abadger1999> nirik: No, the idea is that we'll only have deltas for packages built after that time.
19:32:41 <nirik> ok, good.
19:32:45 <notting> rawhide deltas are just against the prior tree
19:32:55 <abadger1999> nirik: The reason is that the final package on the user's system will have been built with the xz on the user's system.
19:33:07 <nirik> I'm fine with the plan then... tag, break inhert, nuke deltas, move on.
19:33:09 <abadger1999> nirik: And when the update package was old, that's what's causing the breakage.
19:34:02 <pjones> yeah, I'm fine with this plan.
19:34:14 <ajax> works for me
19:34:22 <SMParrish> based on that I'm good with it
19:34:40 <nirik> that's +4 I think.
19:34:43 <mclasen> +1
19:35:01 <kylem> hrm.
19:35:04 <mjg59> +1, I think
19:35:05 <kylem> +1.
19:35:12 <mjg59> I can't see anything obviouly better
19:35:16 <kylem> i'd like t think about it more though.
19:35:31 <nirik> #agreed Fesco is fine with the indicated plan of mass tagging, breaking inherit, and scrubbing old deltarpms for rawhide.
19:35:34 <ajax> well, besides turning off deltas
19:35:52 <nirik> well, deltas are not usually that usefull in rawhide, unless you make sure to update every single day.
19:36:27 <nirik> and even then, if you had an day out of date mirror, etc.
19:36:40 <abadger1999> Cool.
19:36:48 * abadger1999 has to vamoose now.
19:36:52 <ajax> yeah, i really don't see much benefit in drpms for rawhide
19:36:53 <nirik> #topic Open Floor
19:37:05 <nirik> any further open floor items? or shall we wrap up?
19:37:06 <mclasen> do we have a date for that event ?
19:37:33 <nirik> mclasen: I guess when rel-eng is ready... it should be announced, etc.
19:37:46 <mclasen> sure, sounds fine
19:37:54 * mclasen was just making sure its not happening tomorrow
19:38:40 <nirik> I think the new xz has landed, but the only harm right now is that deltarpms don't work.
19:39:10 * nirik will close out the meeting in a few here if nothing comes up.
19:39:13 <notting> right, and since they fallback, i wasn't thinking it was OMG critical
19:39:34 <nirik> yeah.
19:39:39 <nirik> ok, thanks for coming everyone!
19:39:44 <nirik> #endmeeting