#fedora-meeting: FESCO (2010-08-31)
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
* init process (nirik, 19:30:01)
* mclasen said he would be a bit late. (nirik, 19:30:53)
* #351 Create a policy for updates - status report on implementation
* #382 Implementing Stable Release Vision (nirik, 19:35:34)
* LINK: https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy
* ACTION: ajax to add to the draft and fold in other updates critera.
* 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. (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. (nirik, 20:36:52)
* ACTION: kylem will send the email to devel-announce about rawhide
builds. (nirik, 20:37:06)
* #453 Fedora Annual User Survey (nirik, 20:38:56)
* AGREED: jonmasters will ping the board and marketing about this and
see if we can get something together. (nirik, 20:54:17)
* #448 Disallow packages whose primary owner is group. (nirik,
* AGREED: will revisit this next week. (nirik, 21:08:14)
* #455 gupnp-dlna bundled library exception (nirik, 21:09:12)
* AGREED: will talk to gstreamer maintainer and revisit next week.
* FES roundup (nirik, 21:18:49)
* LINK: https://fedorahosted.org/fedora-engineering-services/report/6
is the f14 one. (nirik, 21:21:55)
* ACTION: nirik will file rel-eng ticket about the FTBFS processing.
* ACTION: will ask mdomsch to re-run his suite and revisit next week.
* Open Floor (nirik, 21:33:30)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=628695
FESCo to handle that bug, not me :) (Oxf13, 21:49:21)
Meeting ended at 21:50:41 UTC.
* ajax to add to the draft and fold in other updates critera.
* 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.
* kylem will send the email to devel-announce about rawhide builds.
* nirik will file rel-eng ticket about the FTBFS processing.
* will ask mdomsch to re-run his suite and revisit next week.
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
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik
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
19:32:03 <nirik> .fesco 351
19:32:04 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
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 -
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
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
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
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
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
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
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
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
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
19:57:52 <ajax> gholms|work: if nobody in that sig learns how to backport code,
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
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
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
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
20:03:19 <nirik> SMParrish: so they are 6months, but not the same 6 months as
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
20:05:26 <nirik> gholms|work: they are close I think... but yeah, they align with
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
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
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
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
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
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
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" !=
20:16:01 <nirik> notting: how many things are we inheriting? is there an easy way to
20:16:11 <pjones> because if you make that a different repo, you don't have the
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
20:19:01 <Oxf13> nirik: as soon as you do one build for rawhide, inheritance is
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
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
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'
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
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
20:29:29 <Oxf13> unless we fundamentally change how packages move from one state to
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
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
20:31:57 <notting> Oxf13: cutting the inheritance makes the need to build more
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
20:33:01 <nirik> the inheritence could be usefull if rawhide was busted after the
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
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
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 -
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
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
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
20:43:15 <notting> i'm not against it. seems more of a board issue than a fesco
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
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
20:48:01 <nirik> jonmasters: what kinds of information would you see us collecting
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
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
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
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
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,
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
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
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
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
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
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
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
21:12:38 <nirik> we could revisit this next week if people want time to look over
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
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
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
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
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:57 <nirik> 118 bugs
21:22:21 <nirik> 100 for f13:
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
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
21:24:52 <nirik> the http://fedoraproject.org/wiki/FTBFS
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
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
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
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
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
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
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
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'
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-*"
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
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
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