19:30:01 <nirik> #startmeeting FESCO (2010-08-31)
19:30:01 <zodbot> Meeting started Tue Aug 31 19:30:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:07 * kylem waves.
19:30:10 * pjones is here
19:30:14 * SMParrish here
19:30:53 <nirik> #info mclasen said he would be a bit late.
19:31:43 <nirik> I guess we have 5, so we can go ahead and get started...
19:32:02 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:32:03 <nirik> .fesco 351
19:32:04 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:32:18 <nirik> so, all of this is done except for autoqa. Should we leave it open until thats in place?
19:32:50 <nirik> Thinking about it, I was wondering if we couldn't make a "Updates_Policy" page that has all this info and the stuff from the next ticket and so forth.
19:32:53 <nirik> all in one place.
19:33:48 <nirik> thoughts? opinions?
19:33:59 <notting> might be simpler that way
19:34:03 <pjones> I don't know if it's worth closing it; we'd just open another ticket about autoqa
19:34:07 <SMParrish> Leave it open until AutoQA is in place.
19:34:15 <pjones> but yeah, a wiki page for UpdatesPolicy seems like a good idea
19:34:19 <kylem> sounds reasonable, i'll write up a wiki page
19:34:49 <ajax> (here now)
19:35:18 <nirik> I'd like to see all the updates policy stuff in one place we can point people to... instead of about 5 pages with weird names. ;)
19:35:30 <nirik> but, lets go on to the next ticket:
19:35:34 <nirik> #topic #382 Implementing Stable Release Vision
19:35:34 <nirik> .fesco 382
19:35:35 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:35:45 <ajax> https://fedoraproject.org/w/index.php?title=User%3AAjax%2FStable_Release_Policy&diff=195012&oldid=194074
19:36:01 <ajax> apologies for not getting to that earlier
19:36:23 <nirik> cool.
19:36:24 * nirik looks.
19:36:33 <ajax> i think that covers most of what was discussed last week.
19:37:12 <ajax> the kernel was brought up as a possible other exception class last week, but kyle seems comfortable with the "work with upstream to create stable branches" clause for that
19:37:32 <nirik> So, the exceptions section is the type of things that might be granted an exception? or is our thought that we would just allow the maintainer to decide they fall under an exception?
19:37:49 <nirik> and are exceptions per update? or per package?
19:38:32 <pjones> I think that should be at the discretion of whoever is approving such an exception
19:38:41 <nirik> is that us? ;)
19:38:46 <ajax> to the first question, i lean towards maintainer judgement up front and brutal beatings for any mistakes
19:38:46 <pjones> yes ;)
19:39:11 <ajax> and to the second, either, depends, and yes fesco would be the arbiter
19:40:59 <SMParrish> Exception should be per update IMO, and we let the maintainer decide if it qualifies for an exception and intervene if needed
19:41:08 <nirik> we might want to make it clear that exceptions are granted by fesco? or if there is any doubt about an exception ask fesco?
19:42:01 <ajax> the "per package exceptions to fesco" bit is there, though you can't see it in the diff i guess
19:42:04 <ajax> https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy
19:42:08 <ajax> right under Exceptions
19:42:27 <nirik> well, it says if you think it's a new class propose it to fesco...
19:42:31 <nirik> but ok.
19:42:46 <ajax> not really?  i might have written it too subtly.
19:43:15 <notting> i would think that any per-package exceptions would have to be granted by fesco. some per-update ones an be per discretion of packger
19:43:21 <nirik> I think maintainers will be confused on if they should ask for an exception always, or just use their judgement...
19:44:29 <nirik> so, does this handle all our big corner cases?
19:45:27 <nirik> what about the big issue of KDE?
19:45:48 <SMParrish> lol was hoping someone else would mention that :)
19:45:49 <nirik> Might fall under security if the newer version had security that couldn't be backported?
19:45:49 <ajax> man, if only they learned what maintenance was.
19:46:03 <nirik> yeah. :(
19:46:41 <SMParrish> KDE will need an exception atleast once per release cycle
19:46:53 <ajax> because...
19:46:55 <notting> but i don't see how that helps our users if they get used to being on 4.5 for 11 months, and then at the last month they get 4.7 due to some security bug
19:47:31 <SMParrish> notting: IMO N-1 should not get that, just N
19:47:41 <kylem> kde has the same problem as the kernel does more or less, backports are unpredictable.
19:47:53 <kylem> and can be a hell of a lot of work for the maintainers.
19:48:05 <nirik> right. the upstream release cycle doesn't match up with fedora's.
19:48:11 <SMParrish> KDE's release is off from Fedora's by about 2 months
19:48:20 <nirik> they release more often and don't maintain the previous stable release.
19:48:25 <kylem> not even, given we support for 12 months.
19:48:36 <kylem> right.
19:48:48 <SMParrish> When a new release comes out my vote would be to allow it into the current Fedora, but not the previous one
19:49:18 <nirik> so, the previous one would need to be maintained by kde sig without upstream? could they not do that for current stable too?
19:49:28 <SMParrish> I think rex would be comfortable with that but not Kevin
19:49:30 <pjones> so... if we don't grant an exception, what's the worst case?  we ship the bugfix version 4ish months later?
19:50:02 <nirik> yea, and the current is not supported upstream, so it's all on the sig to backport fixes.
19:50:05 <notting> that feels odd to me. it seems rather than promising we won't change things out on you, we'll only do it occasionally
19:50:20 <SMParrish> nirik: the previous one would get no love at all.  If the user has an issue they would be encouraged to upgrade to the current Fedora.  We can backport some things but not all
19:50:43 <ajax> i can live with that
19:50:47 <nirik> is there any chance we could exert any force on kde upstream to switch to another release plan? this must be causing issues for other distros too?
19:51:04 <pjones> nirik: or even just ask nicely? ;)
19:51:12 <nirik> SMParrish: or use redhat-kde repo for the latest?
19:51:22 <notting> nirik: i prefer that philosophy, honestly
19:51:27 <pjones> likewise
19:51:54 <pjones> it's perfectly okay to have an overlay repo for this and leave the release with the released version
19:51:58 <SMParrish> nirik: I have no problem with that for N-1  but for the current release I'd want the KDE updates in the official repos
19:51:59 * nirik would like to accomodate kde, but it's hard to fit their release setup into the fedora release setup. ;(
19:52:06 <abadger1999> nirik: Note, that's a step away from the Fedora philosophy of only things from the official Fedora repos is blessed.... but maybe it's time for that shift in vision.
19:52:07 <pjones> people who really want to upgrade can, people who don't can use what we shipped.
19:52:41 <nirik> abadger1999: they already use the redhat-kde repo I think... for stuff before they put it in as updates.
19:52:49 * nirik could be wrong on that.
19:53:00 <SMParrish> nirik: you are right
19:53:03 <abadger1999> nirik: Only people who are actively testing stuff out.
19:53:12 <nirik> true.
19:53:22 <pjones> abadger1999: but that just means some slight re-organization there can help
19:53:34 <notting> isn't there still an item about updates-backports or updates-features repo *in* the plan already?
19:53:38 <abadger1999> pjones: ?
19:53:46 <nirik> perhaps a official 'slipstream' repo for just those things that have this release mismatch?
19:53:53 <pjones> abadger1999: a fedora-kde-updates-testing or so...
19:53:55 <nirik> notting: there was an idea for another repo, yes.
19:54:02 <abadger1999> nirik: Would be nice.
19:54:07 <ajax> notting: it's a floated idea, yeah.  it's a bit rough since repos are still remarkably expensive objects.
19:54:14 * jonmasters is here
19:54:27 <nirik> jonmasters: we haven't gotten to the survey thing yet. ;)
19:54:39 <nirik> anyhow, where are we here? we are over 15min...
19:54:43 <nirik> votes to continue?
19:54:53 <abadger1999> pjones: Oh -- no.  I'm saying that the current way that kde-redhat is being used is as testing for things that will go into Fedora official.
19:55:10 <pjones> abadger1999: right, I got that...
19:55:21 <nirik> I'd like to keep going a few more minutes at least.
19:55:32 <abadger1999> pjones: That could change; but it's a step away from the Fedora philosophy of only Fedora repos are official.
19:55:38 <SMParrish> +1 to continue
19:55:41 <notting> +1 to either continue, or to reschedule for next meeting
19:55:48 <nirik> also, it means more work for kde sig.
19:55:55 <ajax> continue
19:56:01 <pjones> +1 to continue
19:56:09 <notting> nirik: ? it's work they're implying they are doing anyway
19:56:13 <pjones> abadger1999: that was what was being discussed as the old and not so great thing, yeah
19:56:17 <nirik> they have to keep maintaining the older version in the main repo and the updated version.
19:57:07 <nirik> SMParrish: aside from 'allow kde to push newer feature versions' is there any kind of setup the kde sig would prefer? would it be worth asking at the next meeting and bringing that back here?
19:57:25 <gholms|work> Just to make sure I understand this right, if KDE updates for F n-2 aren't going to be allowed in does that mean that Fedora releases that are purported to be "supported" will have to rely on unofficial repos for security errata?
19:57:52 <ajax> gholms|work: if nobody in that sig learns how to backport code, yeah.
19:58:10 <gholms|work> That sounds disingenuous.
19:58:11 <abadger1999> or they could stop maintaining the older version... ie: "You have bug X in Fedora kde-4.1, This is fixed in kde-4.2 which is available either by enabling the fedora-kde repo or by upgrading to rawhide"
19:58:14 <SMParrish> nirik:  I will put it on the agenda for next weeks KDE SiG mtg which is in the morning and have an answer for FESCo next week
19:58:17 <ajax> it is, in my experience, pretty rare that security fixes require complete rebases.
19:58:35 <nirik> SMParrish: that would be lovely. thanks.
19:58:36 <ajax> i've had security bugs against X that applied with only trivial massaging all the way back to xfree86 4.1
19:58:38 <gholms|work> (Unless Fedora wants to re-define "Supported")
19:58:53 <SMParrish> abadger1999: that is basically what happens.  Urgent security issues are backported
19:59:49 <nirik> ok, so shall we wait for more input from kde sig on this?
19:59:58 <nirik> and any other changes or additions to this draft?
20:00:23 <SMParrish> KDE tries to stay as close to upstream as possible, and since there are monthly bug fix releases we encourage users to upgrade.
20:00:47 * nirik wonders if we could fold https://fedoraproject.org/wiki/Package_update_acceptance_criteria into this doc and add a bit more and have a Updates_Policy page.
20:01:22 <nirik> SMParrish: sure. There are likely many people who don't hit a bug and are happy on whatever release they have tho...
20:01:30 <notting> SMParrish: sure, 4.5.0 -> 4.5.1, 4.5.2, etc. but i don't see how 4.5.3 -> 4.6.0 can be categorized as a bugfix update under these criteria
20:01:35 <ajax> nirik: probably.  i can take that on.
20:02:00 <nirik> ajax: excellent. ;)
20:02:37 <nirik> possibly also add that if there are issues/trouble with updates, we should file tickets on them, learn from them and add them to https://fedoraproject.org/wiki/Updates_Lessons
20:02:41 <SMParrish> notting: 4.5.x to 4.6 would not be considered a bug fix release but a major release (happens every 6 months) thats the release the exception would apply to
20:03:19 <nirik> SMParrish: so they are 6months, but not the same 6 months as fedora?
20:03:30 <thomasj> right
20:03:50 <SMParrish> right
20:04:02 <nirik> ah. Wonder if we could get them to shift a few months then. ;)
20:04:16 <SMParrish> 1 major release then 5 bugfix releases then repeat
20:04:32 <nirik> or since we might have more pull with gnome and they are switching to 3.0, perhaps we could shift fedora/gnome. ;)
20:04:46 <gholms|work> Are Fedora's releases close to Ubuntu's?  If they're close and one or both projects asked then KDE upstream might be convinced to move its releases a bit.
20:04:56 <thomasj> If i'm allowed to speak. I doubt that. They rather release with openSUSE ;)
20:04:59 <gholms|work> (Sorry, just throwing ideas out there)
20:05:24 <ajax> personally i don't hold much truck with trying to sync release schedules.  adopt what works when it works.
20:05:25 <mclasen> synchronizing all the world to our release schedule seems hopeless...
20:05:26 <nirik> gholms|work: they are close I think... but yeah, they align with SuSE more.
20:05:33 <nirik> yeah.
20:05:38 <pjones> ajax: yes.
20:05:38 <SMParrish> thomasj is right.  Since OpenSUSE is KDE based they align more with them
20:05:41 <nirik> ok, anything further on this topic? or shall we move on?
20:05:55 <nirik> #action ajax to add to the draft and fold in other updates critera.
20:06:20 <nirik> #action SMParrish to talk to KDE sig and see if we can come up with a process that will work for them and the new policy.
20:06:53 <nirik> ok, moving on then...
20:06:58 <nirik> #452 change inheritance of rawhide from the branched tree
20:06:58 <nirik> .fesco 452
20:06:59 <zodbot> nirik: #452 (change inheritance of rawhide from the branched tree) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/452
20:07:33 <nirik> is mattdm on irc?
20:07:39 <pjones> not usually
20:07:40 <notting> not usually
20:08:12 <nirik> ok
20:08:37 * abadger1999 also thinks there's an issue here... but from a building in rawhide perspective rather than testing.
20:08:55 <notting> what's the issue?
20:08:57 <pjones> well, I think Oxf13's issue is more pressing
20:09:01 <nirik> I'm not sure why people are not building in rawhide... is it that hard? or broken? or ?
20:09:25 <pjones> I think most people are still busy with f14 and expect it to inherit
20:09:31 <nirik> I know systemd has not been building in rawhide, only f14... but someone could ask him to build there too, or offer to do so.
20:09:48 <abadger1999> notting: Remember couple years ago when gcc fixed something that would allow python3 to build but it wasn't available in F15, only in F14?
20:09:56 <notting> no
20:10:01 <SMParrish> IMO building in rawhide should be a requirement for package updates
20:10:01 <notting> a couple of weeks ago, maybe.
20:10:06 <abadger1999> err...
20:10:08 <nirik> pjones: does it really take that long to just fire off another build?
20:10:09 <abadger1999> yeah weeks. sorry.
20:10:24 <notting> it only seems we've been working on f14 that long.
20:10:27 <pjones> nirik: it does if you don't realize you need to do it ;)
20:10:50 <gholms|work> SMParrish: And break security updates in F-n because rawhide just bumped its Python version?  No thanks.
20:10:52 <notting> nirik: well, there's always the chance that the build will fail. but i suppose that can happen in either case
20:10:58 <nirik> well, my answer to that would be: should we fire off a devel-announce post reminding people to build for rawhide too...
20:11:19 <nirik> sure, things can fail...
20:12:07 <notting> but my biggest concern with doing the change would be 0xf13's later point about rawhide inheriting the 'wrong' version once updates are pushed to stable
20:12:18 <nirik> yeah.
20:12:20 <notting> i don't like thinks that require is to go manually clean up cruft later. because we'll forget that
20:12:27 <pjones> yep
20:13:11 <ajax> this seems like it follows from abusing -updates as the way to get things into f14 though
20:13:20 <abadger1999> <nod>  Yep, Oxf13's points about how things work in koji seems like this isn't workable.  So what about kalev's idea of requiring building for rawhide?
20:13:41 <notting> abadger1999: how do we 'require' that? we don't have policy or a buildbot
20:13:56 <nirik> I think we should announce/urge maintainers to do rawhide builds... but if they fail, they could still do the f14 build and come back and fix rawhide when they have time... IMHO.
20:13:59 <pjones> ajax: yeah - which seemed like a good idea at the time.
20:14:08 <abadger1999> notting: 1) policy, 2) start doing builds.
20:14:26 <ajax> feels more like branched should go dist-f14-pending -> dist-f14 instead, and only start populating -updates after real release.
20:14:32 <abadger1999> The question would be -- is that a policy that we want?
20:14:47 <notting> ajax: that's how it works now
20:14:51 <nirik> ajax: thats how it is.
20:15:09 <nirik> well, updates-testing -> dist-14
20:15:19 <notting> we could go for a more drastic fix of tagging the latest packages from dist-f14 into dist-f15 at branch time, and stopping inheritance entirely
20:15:58 <pjones> nirik: well, his point is that "pending" != "updates"
20:16:01 <nirik> notting: how many things are we inheriting? is there an easy way to tell?
20:16:11 <pjones> because if you make that a different repo, you don't have the three-repo-monte later
20:16:33 <notting> nirik: everything that doesn't have a fc15 dist tag is inherited at the moment. but they could be tagged directly into dist-f15, so we don't inherit future things
20:17:00 * Oxf13 is here to watch this topic
20:17:16 <nirik> yeah, I was just going to say, we should ask Oxf13. ;)
20:17:41 <Oxf13> let me catch up a bit
20:18:24 <Oxf13> ajax: so I think I confused the issue with my ticket update
20:18:25 <nirik> proposed: policy is that maintainers should do rawhide builds before branched builds where possible. Keep inheritance the way we have now in the event a rawhide build fails and we want to inherit from branched.
20:18:29 <Oxf13> we don't actually use dist-f14-updates right now
20:18:42 <Oxf13> we go dist-f14-updates-candidate -> dist-f14-updates-testing -> dist-f14
20:19:01 <Oxf13> nirik: as soon as you do one build for rawhide, inheritance is over
20:19:07 <nirik> right.
20:19:16 <Oxf13> nirik: koji will never look for a 'newer' build in an inherited tag when there is any build in the local tag
20:19:29 * nirik is fine with that. It should be the exception IMHO where something is really broken and won't even build since branching.
20:20:01 <gholms|work> If you want to do that then why not manually tag everything into dist-f15 when F14 branches?
20:20:16 <gholms|work> Then there is no inheritance to be had at all.
20:20:28 <thomasj> As notting said
20:20:29 <Oxf13> lets back up a bit
20:20:42 <Oxf13> has it even been agreed that there is a real problem here that needs to be "fixed" ?
20:21:05 <nirik> the problem as I understand it is:
20:21:26 <nirik> there is a lag of some updates in rawhide because they are inherited from f14 branched and spend time in updates-testing there.
20:21:43 <pjones> Oxf13: at the very least, anecdotally we've noticed that things aren't getting built in f15 while they are in f14-updates-testing
20:21:46 <nirik> so, f14 +updates-testing people have the cutting edge goodness, and rawhide users don't.
20:22:01 <pjones> Oxf13: and the assumed reason (at least by me) has been that people don't realize it's not inheriting.
20:22:42 <nirik> gcc and systemd are examples I know of.
20:22:42 <Oxf13> ok, I suppose it's non-obvious where the inheritance point is
20:23:29 <Oxf13> I can't think of a good way to structure the inheritance though
20:23:33 * nirik notes we are at 15min on this topic.
20:23:45 <Oxf13> because of the fact that -candidate and -testing are meant to be transient tags where things come/go/rot
20:24:00 <nirik> votes to keep going?
20:24:08 <SMParrish> +1
20:24:10 <pjones> well, if we were to use f14-pending instead of f14-updates-testing, and not use f14-u-t/f14-u until after f14 lands, we wouldn't have to do the 3-repo-monte
20:24:12 <notting> +1
20:24:14 <pjones> +1 to keep going
20:24:18 * nirik is ok with a few more min.
20:25:26 <nirik> pjones: then were do we test and decide if something should go in?
20:25:45 <pjones> nirik: what do you mean?  what do you think -pending would be used for?
20:25:48 <Oxf13> pjones: I missed the proposal.  Can you re-state it?
20:26:16 <nirik> pjones: I'm not sure what pending is used for. ;) Right now it's 'someone submitted an update but it's not been pushed anywhere' right?
20:26:17 <pjones> <ajax> this seems like it follows from abusing -updates as the way to get things into f14 though
20:26:18 <pjones> <ajax> feels more like branched should go dist-f14-pending -> dist-f14 instead, and only start populating -updates after real release.
20:26:44 <ajax> so that way dist-f15 still inherits from dist-f14.
20:26:48 <pjones> right
20:27:24 <pjones> and we never have to repoint things at any point in the process once they're created
20:27:49 <Oxf13> I guess you missed my comment earlier
20:27:54 <Oxf13> we don't actually use dist-f14-updates right now
20:28:05 <Oxf13> we use 'dist-f14-updates-candidate', 'dist-f14-updates-testing', and 'dist-f14'
20:28:17 <pjones> okay sure, but that's semantics that are unrelated to the point
20:28:19 <Oxf13> dist-f14-updates-candidate is where the raw builds land.
20:28:38 <Oxf13> after the bodhi work to propose the update and get information about the update somewhere, it gets pushed into dist-f14-updates-testing
20:28:42 * nirik notes pending is between candidate and updates-testing right?
20:28:47 <Oxf13> if deemed stable, then it goes into dist-f14
20:28:48 <pjones> what he's proposing is to have essentially a different repo for d-f14-u-t before and after the release lands
20:29:04 <Oxf13> I'm not following how that helps
20:29:14 <Oxf13> the 'testing' repo, whatever you call it, is still going to be transient
20:29:29 <Oxf13> unless we fundamentally change how packages move from one state to another
20:29:37 <Oxf13> regardless of the koji tag names.
20:29:55 <ajax> yeah, let's take this aside.
20:29:55 <Oxf13> nirik: the -pending tags are something that is used by autoqa.
20:29:56 <nirik> someone could push foo-1.0-1 to testing-updates, decide it's crap and unpush it, what if rawhide inherited that? it would just disappear right?
20:30:09 <Oxf13> nirik: yeah, it'd disappear
20:30:13 <ajax> i remember why this is complicated now.
20:30:20 <Oxf13> which right now is not allowed by FESCo
20:30:35 <nirik> so, I think we should either leave it as is now, or cut the inheritance entirely.
20:31:16 <Oxf13> cutting the inheritance doesn't solve the problem alone
20:31:27 <Oxf13> we'd have to cut the inheritance /and/ force maintainers to build in rawhide when they're building for branched
20:31:39 <Oxf13> (which the second part alone would fix the problem without necessitating breaking the inheritance)
20:31:50 <nirik> right.
20:31:55 <gholms|work> What's wrong with tagging everything into F-N+2 when F-N+1 branches?
20:31:57 <notting> Oxf13: cutting the inheritance makes the need to build more clear
20:31:59 <nirik> no breaking the updates path, pretty please.
20:32:36 <jonmasters> just one suggestion from me: why not require a reference to the rawhide build when pushing through bodhi?
20:32:37 <Oxf13> notting: I don't really think that it does, it just moves what is surprising to the developer from one thing to another
20:32:52 <gholms|work> jonmasters: What if it doesn't build in rawhide?
20:32:59 <Oxf13> notting: instead of it being surprising that we don't inherit directly from -candidate or -testing, it'd be surprising that we don't inherit at all.
20:33:01 <nirik> the inheritence could be usefull if rawhide was busted after the branch.
20:33:09 <jonmasters> gholms|work: then there's no reference to it and it doesn't get pushed in stable :)
20:33:29 <Oxf13> jonmasters: we've (or at least I've) tried to avoid having any sort of hard rules that dictates developer workflow
20:33:48 <Oxf13> jonmasters: it doesn't matter to me in which order the developer does the work, what matters is the end result when the compose bots come along and process that work
20:34:01 <gholms|work> jonmasters: That's a problem.  I would like to be able to push security errata to F-n without having to first deal with the fact that rawhide may have just bumped to an incompatible version of python or whatever.
20:34:17 <nirik> I'd like to go back to my former suggestion: devel-announce and ask maintainers to pretty please build for rawhide when they build for f14 too. revisit if it's a further issue.
20:34:23 * notting backtracks, just says 'what gholms|work said'
20:34:30 <jonmasters> gholms|work: I'm talking about the non-one liner security bugfixes
20:34:44 <gholms|work> That's a different topic, then.
20:34:59 <jonmasters> ok
20:35:09 <notting> nirik: +1, wfm
20:35:26 <kylem> nirik, +1.
20:35:35 <SMParrish> +1
20:36:02 <kylem> (although, requiring an version # > in rawhide than branched seems reasonable too...)
20:36:03 <ajax> +1
20:36:24 <nirik> would someone like to draft and send the email? :)
20:36:34 <kylem> nirik, i'd be happy to
20:36:52 <nirik> #agreed Will send out a devel-announce post to clarify to maintainers that where possible they should also build for rawhide when doing f14 builds.
20:36:52 <Oxf13> yeah, autoqa should be preventing n-v-r disasters
20:37:06 <nirik> #action kylem will send the email to devel-announce about rawhide builds.
20:37:09 <Oxf13> which may mean preventing the f14 update from going anywhere until rawhide n-v-r gets higher
20:37:09 <nirik> kylem: thanks!
20:37:09 <pjones> nirik: that looks like the only short-term solution :/
20:37:12 <Oxf13> which kind of sucks, but...
20:37:15 <kylem> my first devel-announce mail. :)
20:37:30 <kylem> Oxf13, or just require an override if they're not.
20:37:31 <Oxf13> I do think we might want to have an exception in place for n-v-r issues between branched-testing and rawhide
20:37:43 <nirik> anyhow, anything more on this? or shall we move on?
20:37:51 <Oxf13> branched-testing should be allowed to (temporarily) get a higher n-v-r than rawhide, if inheritance would happen
20:38:01 <kylem> *nod*
20:38:08 <Oxf13> eg: if the build in rawhide currently comes from dist-f14, then a build in dist-f14-updates-testing should be allowed to have a higher n-v-r
20:38:15 <Oxf13> as once it goes to dist-f14 it'll be inherited forward
20:38:24 <Oxf13> once/if
20:38:39 <kylem> right.
20:38:56 <nirik> #topic #453 Fedora Annual User Survey
20:38:56 <nirik> .fesco 453
20:38:57 <zodbot> nirik: #453 (Fedora Annual User Survey) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/453
20:39:03 <nirik> jonmasters: you're up. ;)
20:39:45 * nirik has a number of questions on this.
20:40:25 <nirik> 1) we should ideally get limesurvey done first so we can host it ourselves.
20:40:49 <ajax> i'm not entirely clear why this is a question for fesco.
20:40:56 * Oxf13 just hopes and prays that the survey doesn't get written in such a way to drive survey takers into a pre-determined answer outcome
20:41:18 <nirik> yes, it will need to be worded nicely. (which is really hard to do)
20:41:19 <Oxf13> (note the recent fedora forum "survey")
20:41:29 <pjones> Oxf13: yeah, push polls suck.
20:41:59 <notting> Oxf13: obviously we need competing push polls. with drives for donations to end the evil reign of $fesco_member
20:42:22 <jsmith-busy> notting: Glad you didn't say $FPL :-)
20:42:37 * jsmith-busy knew that his background in market research would come in handy some day
20:43:15 <notting> i'm not against it. seems more of a board issue than a fesco issue
20:43:26 <nirik> also, I think we need to state up front that this is more data (which is great), but it doesn't mean we should automatically do eveything people suggest to us, or change fedora to better suit people who answered the poll where it conflicts with fedoras values, goals, or technical or legal possibility.
20:43:42 <Oxf13> data yes, conclusive data, no.
20:44:09 <nirik> notting: yeah, could well be.
20:44:22 <pjones> I'm still wondering why this is a fesco issue
20:45:00 * jonmasters catches up
20:45:00 <nirik> jonmasters: you still around? ;(
20:45:05 <nirik> ah, there you are. ;)
20:45:14 <jsmith> pjones: Depends on what you're asking in the survey, right?
20:45:34 <jsmith> pjones: If you're asking specifics about mechanics of package updates, etc. then it's probably more of a FESCo topic
20:45:46 <pjones> well, yes.
20:45:47 <mclasen> the fesco issues would presumably come _after_ the survey, when it gets to implementing eventual changes...
20:45:53 <pjones> mclasen: right
20:46:00 <jsmith> mclasen: Agreed :-)
20:46:05 <jonmasters> I'm ok if this is a Board issue. If it is, I'll ask the board directly to look into it. But I wanted to raise it here first.
20:46:07 <nirik> I'm not against it... but I think it should be written in the open in our community, talking with people who know how to make polls...
20:46:10 * notting would seriously hope that the survey would not break down to the detail of 'should fesco use trac or bugzilla'
20:46:24 <notting> nirik: and if our community doesn't know how to make polls?
20:46:27 <nirik> notting: I would write in flyspray just to be mean. ;)
20:46:32 <skvidal> if the survey results in something we don't want
20:46:36 <skvidal> what then?
20:46:50 <skvidal> obviously there is a better and worse answer in everyone's mind here
20:46:54 <nirik> notting: then I guess we end up with a bad poll.
20:46:54 <jonmasters> I understand the problem with leading questions, etc. But there are ways to have independent or semi-independent surveys that are less likely to do that. I am also not a survey-taking/making expert, but perhaps some folks have training in statistics and can help.
20:47:03 <pjones> I'd rather the board got asked and if they want our input on specific parts, we can help supply that info
20:47:05 <nirik> skvidal: see my note above.
20:47:28 * jonmasters is fine with taking this to the Board and asking them to look at it.
20:48:01 <nirik> jonmasters: what kinds of information would you see us collecting from this?
20:48:04 <jonmasters> I have joined the mktg IRC channel, but yet to mail about the survey form. Will do that.
20:48:26 <notting> my only concern is that *any* freely-answerable web survey is likely to be gamed
20:48:27 * nirik poked the limesurvey review.
20:48:46 <notting> but i wonder if restricting to one-response-per-fas account is practical
20:48:48 <jonmasters> nirik: demographic information on the userbase, what they want in the way of updates (slow and steady/bleeding edge), frequency of releases and support timeframe, etc.
20:48:59 <skvidal> notting: how many fas accounts do I need to make?
20:49:19 <jonmasters> nirik: it should be designed in the open, with some notion of being reasonably expeditious to fill in, perhaps with a rough time or question number limit.
20:49:24 <jsmith> skvidal: One, for very large values of one :-)
20:49:47 * skvidal goes ahead and starts
20:49:54 <nirik> jonmasters: ok, that could be interesting data depending on how it was worded and how big our sample size ends up being.
20:50:33 <nirik> I'll note we have already decided the updates issue as far as I know, so it would be interesting to do a poll before it was all done, and one after a release cycle with it in place...
20:51:07 <jonmasters> There's a large community out there. We've seen researchers study Fedora and other projects, and I'm convinced people will volunteer with actual credentials in writing surveys, if we ask them to.
20:51:47 <jonmasters> nirik: indeed. A survey doesn't have to tell you what to do, it just provides input of interest. You don't have to be hostage to its outcome.
20:51:51 <nirik> sure, at worst we will find that the data is suspect, useless or too small a sample to be used.
20:52:06 <jonmasters> nirik: but if a survey says 90% of people oppose something, that's useful compared with 40%.
20:52:09 <nirik> althought I suppose it could be misused by some with an agenda.
20:52:39 <jonmasters> everyone has some agenda. I have an interest in stable updates. And I'm willing to be proven totally wrong.
20:52:39 <nirik> jonmasters: sure, depending on how many people answered it, how the question was worded, etc.
20:52:49 <Oxf13> jonmasters: 90% of survey takers.
20:53:03 <pjones> Oxf13: 90% of respondants.
20:53:10 <nirik> 78.65% of stats are made up too!
20:53:12 <Oxf13> please don't confuse survey respondents with representative amounts of people.
20:53:29 <nirik> anyhow, so where do we go here... jonmasters to talk to the board and coordinate something?
20:53:33 <jonmasters> sure, I get that, I assumed it was a given that we know that surveys only "represent" respondants.
20:53:37 <jsmith> Oxf13: Right... they only represent the people who took the survey... self-selection is an interesting thing.
20:53:45 * jonmasters will talk to the board, and ping marketting folks.
20:53:56 <jonmasters> they can let us know if they want to do this.
20:54:02 <Oxf13> jonmasters: "we" get it, until the results show something that some group really wants to push
20:54:17 <nirik> #agreed jonmasters will ping the board and marketing about this and see if we can get something together.
20:54:20 <Oxf13> jonmasters: suddenly the results represent the "majority of Fedora users" and gets wielded all over the place.
20:54:26 <pjones> also we've been on this subject for 15+ minutes.  should we vote to continue discussion?
20:54:30 <jonmasters> Oxf13: people will always warp statistics in one direction or another, you just live with that.
20:54:31 <Oxf13> for example, the recent fedora forum updates "poll"
20:54:35 <nirik> pjones: I think we are done.
20:54:38 <nirik> anything more on this?
20:54:39 * jonmasters is done
20:54:45 <pjones> okay
20:54:55 <nirik> We have 3 other tickets that came in after I sent the agenda out...
20:55:13 <nirik> but we are getting close to time.
20:55:32 <nirik> 30min more... oops.
20:55:50 <nirik> #topic #448 Disallow packages whose primary owner is group.
20:55:53 <nirik> .fesco 448
20:55:54 <zodbot> nirik: #448 (Disallow packages whose primary owner is group.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/448
20:56:16 <nirik> this got reopened. ;) ajax: I assume it was just a bug closing frenzy that had you closing those merge reviews? or ?
20:57:07 <notting> i'm confused
20:57:14 <notting> parag posted a review and spec changes
20:57:16 <ajax> jesus christ you're kidding me.
20:57:19 <notting> ajax applied some of them and closed the bug
20:57:22 <notting> what's wrong here?
20:57:26 <pjones> that's the process!
20:57:40 <pjones> if everything mentioned in the review is fixed, it's done, close it.
20:58:01 <nirik> did he mark the review as done? fedora-review +?
20:58:08 <mclasen> parag seems to  have this idea that a 'formal' review is still outstanding
20:58:26 <ajax> nirik: i suppose i didn't, but i'm mostly blind to flags.
20:59:03 <nirik> my understanding of the process is: reviewer reviews, maintainer fixes, reviewer confirms and marks review as done.
20:59:22 <nirik> yeah, the interface shows them less and less and keeps moving them around too.
20:59:31 <ajax> i find it a little weird that i'd be allowed to close _other_ people's merge reviews as a provenpackager, but not my own.
20:59:34 <ajax> whatever though.
21:00:13 <nirik> yeah, I think this is just a mis-understanding... re-open and let him finish and close and everythings happy again...
21:00:19 <nirik> shall we move along?
21:00:30 <pjones> yeah
21:00:41 * notting is fine with moving along
21:00:44 <nirik> topic #454 pre-release update acceptance criteria
21:00:44 <nirik> .fesco 454
21:00:45 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454
21:00:48 <kylem> please.
21:00:50 <nirik> so, mclasen worked on this...
21:01:22 <nirik> thinking about it, perhaps we should have a Updates_Policy page that has links to 'rawhide' 'branched' and 'stable' and have those on other pages.
21:01:30 <nirik> (just from an org point of view)
21:02:11 <mclasen> yes, that might be good, I kept it out of the wiki for now, because I wasn't sure how to best organize it
21:02:13 <nirik> My concern with this is that it might confuse people to have a different branched policy, but as long as we set it up clearly perhaps.
21:02:37 <notting> it seems reasonable, although i don't know how pluggable this is in bodhi
21:02:46 <mclasen> I asked lmacken
21:02:53 <nirik> mclasen: so is it still an issue? or was right after branching mostly?
21:03:13 <mclasen> he was confident that we can have different policies for f15
21:03:36 <pjones> mclasen: usually I use the space under https://fedoraproject.org/wiki/User:Pjones for that
21:03:54 <mclasen> nirik: yes, my main trouble is over now
21:05:03 <nirik> so, I wonder as another idea: from branched until alpha change deadline, have no critpath requirements, then enable them at that point...
21:05:19 <nirik> might be more confusing tho
21:05:25 <mclasen> of course, if everybody on branched has updates-testing, the point is somewhat moot
21:05:36 <mclasen> except for the fact that buildroots don't have updates-testing content
21:06:11 <nirik> yeah.
21:06:41 <nirik> so, vote on this? alternative proposals? mull on it for another week since we just see it now?
21:06:57 <mclasen> sure, fine with me
21:07:34 <mclasen> I'll bring it back next week
21:08:06 <nirik> sounds fine to me.
21:08:14 <nirik> #agreed will revisit this next week.
21:08:44 <nirik> There's one more ticket, but again it was just filed, so I don't think we have had a chance to look at it yet.
21:08:47 <nirik> #455 gupnp-dlna bundled library exception
21:08:53 <nirik> .fesco 455
21:08:54 <zodbot> nirik: #455 (gupnp-dlna bundled library exception) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/455
21:09:12 <nirik> #topic #455 gupnp-dlna bundled library exception
21:10:53 <nirik> .whoowns gstreamer
21:10:53 <zodbot> nirik: company (ajax in Fedora OLPC)
21:11:16 <notting> if gst-convenience isn't upstream yet, i don't see a problem with rygel bundling it
21:11:56 * abadger1999 agrees with spot that if it is to be bundled, would rather see gstreamer bundling it.
21:11:59 <nirik> well, it does seem on track to go in... but not sure what the hurry is.
21:12:38 <nirik> we could revisit this next week if people want time to look over the issue...
21:12:45 <pjones> abadger1999: yeah
21:12:49 <nirik> and/or ask company what he thinks...
21:14:09 <kylem> nirik, +1 to asking company...
21:15:01 <nirik> any objections to that?
21:15:08 <SMParrish> also +1 to asking company, will also give us time to look over the issue
21:15:21 <kylem> i can't imagine bundling it with gstreamer before it goes into a stable upstream release is a great idea, in case it does change and people depend on it.
21:15:30 <mclasen> yeah
21:15:38 <mclasen> its is undergoing review and change on the way into gstreamer
21:16:13 <mclasen> so dlna will probably need adjustments after it lands in gstreamer
21:16:31 <nirik> if it's bunded with a random other package it's less likely to get taken care of though...
21:17:05 <mclasen> anyway, I'll ask company to look into the matter
21:17:08 <mclasen> and report back next week
21:17:14 <nirik> ok, I can add them to the ticket too.
21:17:37 <nirik> #agreed will talk to gstreamer maintainer and revisit next week.
21:17:48 <kylem> mclasen, thanks
21:17:58 <mclasen> nirik: it wouldn't be bundled with a random other package, but with the sole user of the library...
21:18:35 <mclasen> but lets move on
21:18:39 <nirik> yeah... ok.
21:18:49 <nirik> #topic FES roundup
21:18:57 <nirik> mmcgrath: anything real quick for a fes roundup?
21:19:05 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
21:19:14 <mmcgrath> Users have been working on tickets, I followed up with several over the last couple of days.
21:19:35 <mmcgrath> There's been instances where patches have been proposed by FES people not in provenpackager that have just sat un-touched in bugzilla.
21:19:43 <nirik> I also filed https://fedorahosted.org/fedora-engineering-services/ticket/40 last week... to add that autoqa test we talked about and make noise about the process.
21:20:05 <nirik> mmcgrath: are those the FTBFS ones?
21:20:11 <mmcgrath> not all of them
21:20:16 <mmcgrath> some are
21:20:51 <nirik> what are we doing with the FTBFS ones? shouldn't we orphan and/or drop them at some point?
21:21:08 <mmcgrath> AFAIK they're still being worked on but we can do whatever you guys want.
21:21:55 <nirik> https://bugzilla.redhat.com/showdependencytree.cgi?id=596849&hide_resolved=1 is the f14 one.
21:21:57 <nirik> 118 bugs
21:22:21 <nirik> 100 for f13: https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1
21:22:41 <mmcgrath> We can redo the list to focus on F14 if you want?
21:23:02 <nirik> I think that might be better, yeah, There's likely overlap.
21:23:27 <gholms|work> Now that we're past alpha, will packages with untouched FTBFS bugs be removed from the distro like policies dictate or not?
21:24:03 <mmcgrath> yeah
21:24:05 <nirik> gholms|work: we should.
21:24:16 <nirik> I guess thats a rel-eng task? notting / Oxf13 ?
21:24:32 <Oxf13> We're a bit behind in our tasks this go-around, I blame myself and dist-git.
21:24:34 <notting> gholms|work: i don't remember orphaning ftbfs in the past
21:24:45 * mclasen notes that for some of the bugs on the list, newer f14  builds exist
21:24:46 * mmcgrath has an NVR email to send out soon too
21:24:47 * gholms|work is referring to http://fedoraproject.org/wiki/FTBFS#Package_Removal_for_Long-standing_FTBFS_bugs
21:24:52 <nirik> the http://fedoraproject.org/wiki/FTBFS says that.
21:25:04 <Oxf13> that said, I don't see a line item in the list of releng tickets for this, nor a schedule item
21:25:27 <nirik> yeah. I think we need to decide how to handle it and get it added into all the right schedules/sop
21:26:14 <Oxf13> and increase time gaps between alpha branch and release candidate too if we're going to wipe out a bunch of packages
21:26:34 <nirik> also, might ask mdomsch to run again... I think it last ran on 2010-07-30
21:27:34 <nirik> it might make sense to do two things: at some point orphan them all since the maintainers have been unable to fix them, then later the orphaned ones can be culled with the rest of the orphans?
21:28:15 <Oxf13> I think that was the plan originally
21:28:23 <Oxf13> they would be orphaned, and picked up when we did the orphan culling
21:28:26 <notting> the orphans have already been culled
21:28:30 <notting> (more or less)
21:29:24 <nirik> ok, whats the action here then?
21:29:39 <nirik> a) something for this cycle, and b) ask rel-eng to add this to regular tasks?
21:30:18 <mmcgrath> is there any way to query what is stale at the moment?
21:30:20 <Oxf13> sounds like two releng tickets to me :)
21:30:30 <mmcgrath> like, how long something has been on the ftbfs list?
21:30:39 <Oxf13> we'd probably want to take the last list generated, check against koji for a newer build, then re-present the list of actual FTBFS
21:31:09 <nirik> well, I think another run would be good if matt could. A lot could have changed in a month.
21:31:50 <nirik> proposal: ask for another run, then see based on that what we want to do for this cycle.
21:31:50 <Oxf13> yeah.
21:31:59 * nirik notes we are over time
21:32:09 <notting> nirik: wfm
21:32:31 <nirik> Oxf13: would you like me to file re-eng ticket on the FTBFS handling? or will you do that?
21:32:35 <gholms|work> Is there another meeting after this?  I have a couple quick packaging-related questions for which I haven't been able to find enough precedence or policies to answer completely.
21:32:48 <Oxf13> nirik: can you?  I'm still trying to catch up on today's email :(
21:32:52 <nirik> Oxf13: I can.
21:33:10 <nirik> #action nirik will file rel-eng ticket about the FTBFS processing.
21:33:26 <nirik> #action will ask mdomsch to re-run his suite and revisit next week.
21:33:30 <nirik> #topic Open Floor
21:33:37 * gholms|work raises hand
21:33:39 <mclasen> One quick thing from me
21:33:42 <nirik> gholms|work: there isn't a meeting after this one I don't think.
21:33:55 <nirik> but many fesco folks have to leave. ;)
21:34:04 <nirik> mclasen: go ahead and then gholms|work ?
21:34:07 <mclasen> I took the action to remove 'important packages' from https://fedoraproject.org/wiki/Package_update_acceptance_criteria
21:34:09 <mclasen> and I did
21:34:15 <mclasen> but I am not really happy with the result
21:34:30 <mclasen> since we now have two subtly different notions of 'critical path' package set
21:34:46 <mclasen> so, if anybody feels inspired to improve on my changes...
21:35:29 <Oxf13> ugh, I never liked defining a second group :(
21:35:55 <nirik> well, yeah...
21:36:00 <mclasen> I guess the alternative is to add the extra things listed in the update policy to the critpath set
21:36:12 <nirik> they are I think named 'critical-path' 'critical-path-gnome' etc.
21:36:23 <notting> mclasen: that would be simplest, yes. and just link to it
21:38:15 <mclasen> I also learned that bodhi doesn't actually implement the larger set yet
21:38:24 <mclasen> but just uses the smaller critpath set
21:38:28 <Oxf13> For the purposes of this policy, the "critical path" package set is a union of all critical-path* groups.
21:39:02 <nirik> mclasen: which larger set?
21:39:10 <nirik> Oxf13: works for me.
21:39:17 <mclasen> nirik: critpath + major desktops + firefox
21:39:24 <Oxf13> IIRC bodhi just uses the base 'critical-path' group, and does not include any critical-path-* stuff
21:39:25 <mclasen> what the update policy lists
21:39:40 <nirik> mclasen: it seemed to for me... where did you see it not?
21:39:47 <mclasen> I asked luke
21:39:55 <nirik> ie, I had a xfce update that wouldn't go stable until it got the right amount of karma.
21:40:08 <nirik> from proventester, etc.
21:40:09 <Oxf13> also, what fun having to discover which "critical-path-*" groups exist...
21:40:16 <nirik> mclasen: strange. I thought it was in place.
21:40:31 <abadger1999> bodhi just has a hardcoded list atm.
21:40:35 <nirik> well, they are in comps, but not visible.
21:40:52 <abadger1999> We need to start generating that list and putting it into pkgdb and then bodhi can grab it from there.
21:41:01 <nirik> (as an aside, why is that? perhaps we should make them visible?)
21:41:02 <Oxf13> nirik: right, you have to enumerate all comps groups, then check them against a regex of "critical-path*"
21:41:05 <nirik> abadger1999: ah.
21:41:08 <Oxf13> as opposed to just getting "critical-path"
21:41:11 <notting> abadger1999: erp, i thought we were. my bad.
21:41:11 <mclasen> thats what luke said, right
21:41:12 <abadger1999> The generating list portion is the only part that doesn't have code written yet (AFAIK)
21:41:19 <mclasen> anyway, I have to go now
21:41:25 * nirik sighs. I thought it was done.
21:41:50 <nirik> abadger1999: is anyone working on it?
21:41:56 <abadger1999> nirik: notting :-)
21:42:19 <nirik> ah, cool. ;)
21:42:33 <nirik> ok, gholms|work: you had something? is it quick?
21:42:49 <gholms|work> Should be.
21:42:50 <notting> i am?
21:42:53 <notting> eep.
21:42:57 <gholms|work> Two quick questions:
21:43:01 <gholms|work> 1.  Say I need to build m2crypto against python26 in EPEL-5.  The base m2crypto package is in RHEL base.  As a python library, m2crypto breaks the package naming guidelines but has been grandfathered in.  Should the new package be called m2crypto26 to match the base package's name or should it be called python-m2crypto26 to satisfy the current rules?
21:43:30 <abadger1999> gholms|work: python26-m2crypto
21:43:41 <nirik> yeah.
21:43:48 <gholms|work> Isn't the standard to append 26 to the base package name?
21:43:52 <abadger1999> b/c you need to show that the package is for python26 (this matches the python3 guidelines)
21:44:16 <abadger1999> gholms|work: To the python portion.  Appending a version to the end of the name would be if m2crypto itself needed a compat version
21:44:34 <abadger1999> ie: m2crypto12-1.2.0 and m2crypto-2.0
21:44:39 <gholms|work> Ok
21:44:48 <gholms|work> Second question:
21:44:53 <gholms|work> 2.  Say I need to build python-boto against python26 in EPEL-5.  The base python-boto package is in EPEL-5.  Must I submit a new package for review or must I convince the package's current maintainer to build his package twice for just EPEL-5?
21:45:29 <Oxf13> IMHO you could start by asking for the latter, but if the maintainer doesn't agree, proceed to do the former
21:45:59 * nirik nods.
21:46:02 <abadger1999> So for that... dmalcolm was pushing for same package.
21:46:07 <abadger1999> I push for separate packages.
21:46:14 <Oxf13> hah
21:47:58 <gholms|work> Anyone else have preferences?
21:48:16 * abadger1999 notes these are probably Fedora Packaging Committee questions.
21:48:27 <nirik> yeah, talk to FPC. ;)
21:48:34 <gholms|work> True.  Thanks, people.
21:48:39 <nirik> ok, we are way over... will close in a minute if nothing else.
21:49:05 <Oxf13> I have one thing, perhaps for next meeting
21:49:21 <nirik> Oxf13: ok... file a ticket? ;)
21:49:21 <Oxf13> https://bugzilla.redhat.com/show_bug.cgi?id=628695  I"d like FESCo to handle that bug, not me :)
21:49:40 <Oxf13> rather, let fesco decide if the rfe should be done, then I'll happily do the work
21:49:58 <nirik> uh... ok.
21:50:25 <nirik> rotating media is so old school. ;)
21:50:33 <nirik> ok, thanks for coming everyone!
21:50:35 <Oxf13> wish we didn't have to make it
21:50:41 <nirik> #endmeeting