17:30:02 <nirik> #startmeeting FESCO (2011-02-16)
17:30:02 <zodbot> Meeting started Wed Feb 16 17:30:02 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:02 <nirik> #meetingname fesco
17:30:02 <zodbot> The meeting name has been set to 'fesco'
17:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:02 <nirik> #topic init process
17:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:31 <nirik> who all is around today?
17:31:05 * mclasen is somewhat around
17:32:04 * nirik guesses it might be a short meeting if we don't have quorum. ;)
17:32:04 <notting> sorry, here now
17:32:27 <SMParrish_mobile> here but mobile
17:32:27 <nirik> #info SMParrish and mmaslano unable to attend today.
17:32:34 <nirik> oh, my mistake. ;)
17:33:06 <kylem> yo.
17:34:00 * nirik waits a few more for more folks to show.
17:34:10 <nirik> I guess we do have 5 now tho.
17:35:08 <nirik> ok, I guess lets go ahead and dive in...
17:35:20 <nirik> #topic #516 Updates policy adjustments/changes
17:35:20 <nirik> .fesco 516
17:35:21 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516
17:35:31 <nirik> I added 2 new thoughts from the ideas container for this week:
17:35:36 <mjg59> Hey, sorry
17:35:42 <ajax> hello again
17:36:12 <nirik> welcome ajax and mjg59
17:36:17 <nirik> so, first:
17:36:20 <nirik> 1) reduced karma requirement on other releases when one has gone stable.
17:36:47 <nirik> The idea here is that if someone tested out ok in one release, it should be fine in another
17:37:49 <nirik> so, say a openchrome driver goes stable in f14, the f13 update where no one with hardware to test it could go stable at a lower criteria.
17:37:53 <kylem> i know we have problems with getting karma and stuff, but making it /easier/ to push updates to older stable releases doesn't seem entirely the answer...
17:38:20 <ajax> not really a fan of that idea, i gotta say.
17:38:21 <kylem> nirik, or, break everything because of a subtle version difference in a dependency that went unnoticed and then is pushed out...
17:38:27 <nirik> yep.
17:38:32 <mjg59> Yeah, if anything we'd prefer that older releases get fewer updates
17:38:58 <kylem> i mean, everything sucks, we're never going to win on this. i think i'm in favour of an edict from on high versus endless debate. :)
17:38:59 <nirik> I personally am -1 to this for two reasons: it add more complexity to an already complex thing (bodhi rules) and it's not entirely true.
17:39:28 <nirik> #info mmaslano voted +1 on this in ticket.
17:39:52 <nirik> other votes/thoughts?
17:39:56 <mjg59> -1
17:40:03 * notting is -1 as well. the point is not to make older releases move faster with less testing.
17:40:16 <nirik> to be fair, it could be the other way too...
17:40:22 <tibbs|h> The problem is that there are classes of packages where this makes sense and others where it doesn't.
17:40:33 <nirik> ie, f14 update goes stable, should f15 update thats the same have a reduced requirement
17:40:50 <kylem> i'd be much more positive about that.
17:40:58 <SMParrish_mobile> -1
17:41:06 <kylem> than the original proposal.
17:41:17 <nirik> we are at -4 / +1 (I think)
17:41:48 * mclasen hasn't voted yet
17:41:51 <mclasen> -1
17:42:15 <nirik> #agreed idea is not accepted at this time.
17:42:16 <kylem> -1 for the above discussed logic.
17:42:33 <nirik> 2) aggregated karma across the releases for the same package version.
17:42:56 <kylem> heh.
17:42:59 <mjg59> -1
17:43:00 <nirik> so, in this case you could push updates to testing for several branches, when any/all of them collect enough karma they all go out at the same time.
17:43:15 <kylem> -1 for the same reason. i could be convinced of "karma flows uphill" tough.
17:43:22 <mjg59> I'm utterly against anything that allows an older branch to get autopushed just because a newer branch has been tested
17:43:22 <kylem> s/tough/though/
17:43:45 <nirik> -1 from me as well.
17:43:54 <nirik> #info mmaslano voted -1 on this in ticket.
17:44:01 <nirik> #undo
17:44:01 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2b026469f390>
17:44:05 <nirik> #info mmaslano voted 0 on this in ticket.
17:44:12 * notting is -1 as well
17:44:30 <kylem> if someone karmas f(n-2) it karmas f(n-1), since the increased testing for f(n-1) should likely outweigh the added karma if the update is bogus on f(n-1)
17:46:27 <nirik> so we are at -4?
17:46:38 <kylem> looks like.
17:47:40 <nirik> any other votes or comments?
17:48:13 <ajax> -1
17:48:27 <nirik> #agreed idea is not accepted at this time.
17:48:37 <nirik> #topic #515 Investigate a "features" repo for stable releases
17:48:37 <nirik> .fesco 515
17:48:38 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
17:48:44 <nirik> cwickert was going to work on this...
17:48:54 <nirik> since he's not here, shall we move on?
17:49:18 <kylem> ack.
17:49:36 <nirik> #topic #517 Updates Metrics
17:49:37 <nirik> .fesco 517
17:49:38 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517
17:49:55 * kylem burrows his head in the sand :/
17:49:55 <nirik> we don't really have anyone driving this I don't think... so, if anyone is willing to step up that would be great.
17:49:59 <nirik> :)
17:50:32 <kylem> i feel guilty for shirking this, but i'm not going to step up... if nobody else does i'll try to spend an hour on it though.
17:51:08 <nirik> cool. It would be good to at least collect an idea of stats we would like so they might be easy to get in bodhi 2.0 or the like.
17:51:27 <kylem> yeah, i did poke luke a bit about it at fudpub
17:51:28 <kylem> ;-)
17:51:32 <nirik> #info kylem will try and spend a bit of time on this.
17:51:38 <nirik> #topic #544 List of services that may start by default
17:51:38 <nirik> .fesco 544
17:51:39 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544
17:52:01 <nirik> so, not sure entirely where we stand. I was busy when the FPC meeting was going earlier. It sounds like they would like us to deal with it entirely...
17:52:27 <nirik> abadger1999 / spot / tibbs|h: should we discuss this this week? or wait for you guys to vote on something in ticket?
17:52:51 <abadger1999> nirik: better wait.
17:53:02 <nirik> ok, fair enough.
17:53:16 <abadger1999> No one's voted yet -- we (FPC) are clearly in disagreement but we don't know where the majority stands
17:53:19 <kylem> if they want us to make an edict i propose we disallow all daemons from listening on non-localhost by default and disallow all root privileged daemons from running by default entirely. ;-P
17:53:57 <abadger1999> I can critique what you have but I don't know ifyou want that or not :-)
17:54:02 <kylem> hehe.
17:54:20 <abadger1999> For instance, the current guidelines would allow mysql and httpd to start by default
17:54:34 <abadger1999> since they can be configured to not listen on the network.
17:54:43 <mjg59> That doesn't seem like a problem
17:54:45 <abadger1999> curren tguideliens == current draft guidelines.
17:54:50 <nirik> I think this might be something thats hard to have a understandable guideline on. It might just take: 'here's a list, if you aren't on it and would like to be, ask. If you aren't on it you don't start by default'
17:55:26 <abadger1999> The current FPC guideline would say no to mysql and httpd.
17:56:10 <nirik> anyhow, how about we defer and discuss next week...
17:56:15 <abadger1999> <nod>
17:56:18 <mjg59> abadger1999: Right. If FPC want to control this, FPC can control it.
17:56:30 <nirik> but some part of FPC at least doesn't want to. ;)
17:56:44 <mjg59> abadger1999: But I'm *indescribably* uninterested in a situation where FPC ask us to implement something without giving us control over that policy
17:56:51 <abadger1999> <nod>  We must vote to see whether the majority of FPC wants this or not.
17:57:02 <mjg59> Either take responsibility or devolve it. Don't try to do both simultaneously.
17:57:28 <abadger1999> mjg59: Is it our responsibility if we want it currently?
17:58:00 <mjg59> abadger1999: I've got no problem believing that this is under the realm of FPC if they want it to be
17:58:05 * nirik could see it either way honestly.
17:58:06 <abadger1999> b/c the main argument for giving it to fesco is that it is outside the scope of fpc.
17:58:19 <mjg59> If FPC doesn't think it's in their scope then we'll probably take it
17:58:20 * abadger1999 <nod>'s to nirik's evaluation
17:58:24 <mjg59> But it's then out of FPC's scope
17:58:52 <abadger1999> anyhow -- fpc probably should decide whether they think it's in scope or not.
17:58:55 <nirik> "when I make a package that has a service, should it start by default?" (seems to be something that many maintainers would ask and look for guidence in packaging guidelines.
17:59:00 <mjg59> So don't be upset if we end up with guidelines that FPC disagrees with :p
17:59:04 <abadger1999> and no use taking up meeting time here to do that :-)
17:59:11 <nirik> right. Lets move on.
17:59:24 <abadger1999> mjg59: Oh I will be -- b/c I'm voting against handing it to fesco
17:59:38 <abadger1999> but then, can't please everyone... :-)
17:59:39 <nirik> #info Will defer this and see what FPC decides over the next week.
17:59:46 <nirik> #topic #562 Transifex migration
17:59:46 <nirik> .fesco 562
17:59:47 <zodbot> nirik: #562 (Transifex migration) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/562
17:59:55 <nirik> notting: you added this?
18:00:04 <notting> yes
18:00:21 <notting> so, there has been discussion in the l10n community and infrastructure about what to do with Transifex
18:00:34 <notting> the version we have in Fedora is out of date, and doesn't really have willing maintainers
18:00:55 * nirik nods.
18:01:00 <notting> l10n + infrastructure have decided to move from hosting our own transifex instance, to using upstream transifex.net
18:01:22 <notting> this will cause some changes in workflow for developers (most of which are actually due to the transifex version upgrade)
18:01:26 <notting> #info l10n + infrastructure have decided to move from hosting our own transifex instance, to using upstream transifex.net
18:01:30 <notting> #info this will cause some changes in workflow for developers (most of which are actually due to the transifex version upgrade)
18:01:53 <nirik> is this going to end up having a 'flag day' ? or can we move things as maintainers/translaters are ready?
18:02:02 <notting> essentially, maintainers of software that is translated (in fedorahosted, or whatever) will need to pull translations from transifex
18:02:07 <notting> they won't be automatically committed to the SCM
18:02:22 <notting> it's going to be a flag day
18:02:58 <notting> the translators are going to attempt to move to doing their translations by Feb. 18th (friday)
18:03:11 <nirik> wow. Thats quick. cool.
18:03:15 <notting> the goal is to have all the developer tools ready, documented, etc. by Feb. 25th (the next friday)
18:03:34 <mclasen> do we have a list of affected modules ?
18:03:38 <ajax> that's quick, but i don't really see any better option
18:04:12 * nirik thinks this is a good idea and is glad it's happening. I think it will end up being a win.
18:04:26 <ajax> and technically string change freeze was yesterday, so, might as well
18:04:51 <nirik> everything currently at https://translate.fedoraproject.org/ right?
18:05:16 <notting> nirik: yes
18:05:23 <nirik> 115 projects it looks like.
18:06:17 * glezos is here
18:06:29 <nirik> so, any actions fesco needs to take here? or is this informational / getting more news out about it?
18:06:38 <notting> the latter
18:07:16 <notting> we're going to, once we get all the docs and tools in shape, be informing people directly, and via devel-announce
18:07:26 <glezos> FYI I already migrated the 21 core projects of ours: http://fedora.transifex.net/projects/p/fedora/r/fedora-15/l/en/
18:07:41 <nirik> glezos: great. ;)
18:07:58 <kylem> i have to confess utter ignorance to all this translation stuff.
18:08:07 <glezos> These are affected by the string freeze, so they are urgent. Docs can be migrated by FDP, and the rest by the upstream developers themselves.
18:08:14 <nirik> glezos: is there going to be any namespace issues? ie, something called "install guide" in our transifex might need to be 'fedora install guide' in the upstream one?
18:08:33 <glezos> nirik: yes.
18:08:58 <glezos> nirik: I already renamed initscripts to fedora-initscripts. But in the end, that's the developer's choice, I suppose.
18:09:14 <nirik> yeah, as long as the translators and maintainers know it shouldn't be too bad.
18:10:08 <nirik> ok, anything further on this topic? or shall we move on?
18:10:17 <nirik> glezos: thanks for working on this!
18:10:34 <glezos> nirik: let me know if I can help in any way, foo.
18:11:11 <nirik> will do. ;)
18:11:27 <nirik> ok, next one wasn't on the topic list either, so we could defer it, but I thought I would bring it up:
18:11:33 <nirik> #topic #561: Should bugz.fedoraproject.org give links to security/private bugs?
18:11:37 <nirik> .fesco 561
18:11:38 <zodbot> nirik: #561 (Should bugz.fedoraproject.org give links to security/private bugs?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/561
18:12:25 <nirik> do we want to discuss this today? or leave it for next week?
18:12:39 <kylem> heh.
18:12:49 <kylem> i'm happy with either.
18:13:03 * mclasen doesn't think there is much to discuss
18:13:07 <notting> wasn't there also the epel issue?
18:13:10 <nirik> I will say I liked some of Oxf13's reply on the devel list. Possible solution: a disclaimer that not all bugs might be listed + a link to the bugzilla query you could run as your user that could see security bugs.
18:13:26 <mclasen> revealing bug numbers seems harmless
18:13:33 <Oxf13> oh hai
18:13:53 <nirik> mclasen: well, if you see bind has a new bug that you can't read, you might fish for some exploit or security issue thats not yet widely announced.
18:14:16 <abadger1999> Well -- if the admonition is present or not present depending on if there are private bugs... it defeats the purpose of not showing the private bugs.
18:14:21 <nirik> notting: oh yeah. Will do next.
18:14:34 <nirik> abadger1999: I would say always show the note.
18:14:35 <abadger1999> You'd have to always show it.
18:14:38 <notting> my assumption would be that if the bug is filed, someone already knows
18:14:39 <abadger1999> <nod>
18:14:57 <notting> so disclosing that there may be a private issue isn't a huge information leak
18:15:23 <mclasen> next step would be to add fake private bugs to all packages, to hide the real ones...
18:15:29 <nirik> abadger1999: "Note: bugs that are private for any reason will not be listed here. See <linktobugzilla> to see those if your permission allows"
18:15:51 <notting> nirik: that does also work
18:15:54 <notting> what does the SRT think?
18:16:19 <ajax> one problem with revealing bug numbers is that (iirc) we tend to get one bug per affected release
18:16:36 <abadger1999> I don't know -- I've only been in contact with two people who aren't primarily Fedora guys.
18:16:49 <ajax> which means you could count the number of security bugs against a package and maybe work out when the bug was introduced, which would let you narrow down where to start looking for exploits
18:16:54 <ajax> but you know what?  who cares.
18:17:27 <Oxf13> Fedora has never claimed to do embargo work
18:17:47 <hicham> ajax: wayland/gallium-egl issue seems to be fixed in mesa master
18:17:49 <mclasen> ajax: hiding the source code might be even safer...:-()
18:17:57 <Oxf13> although I suppose if the bug is originally discovered and filed in our bugzilla we have some obligation to try and keep embargo.
18:18:43 <abadger1999> So what I'm taking away from this is: 1) FESCo is tentatively okay with showing bug numbers 2) I should send an email to the fedora security response team list to see if they have any input.
18:19:18 * nirik thinks the disclaimer and link to query is better, but I don't feel super strongly about it. If folks are ok with showing the bug numbers thats ok with me too.
18:19:19 <ajax> yeah, i don't have any objection to showing bug numbers for unviewable bugs
18:19:22 <kylem> sounds good to me.
18:20:02 <SMParrish_mobile> works for me
18:20:37 <nirik> ok, so it sounds like thats enough votes to "showing bug numbers is ok with us"
18:20:38 <notting> ack.
18:20:42 <nirik> ?
18:21:10 <mjg59> Sure
18:21:18 <Oxf13> abadger1999: regardless of outcome, would you consider adding the direct bugzilla query link anyway?
18:21:43 <nirik> so, does this sound like something people agree to: Fesco is ok with showing bug numbers of private bugs. Or using some other method pkgdb maintainers wish like a disclaimer/link to query?
18:21:46 <abadger1999> Oxf13: Yes -- the one thing is -- I'm using bz xmlrpc so I'll have to figure out what the non-xmlrpc link would be.
18:21:55 <Oxf13> nod
18:21:58 <abadger1999> There's no real correlation between the two.
18:22:31 <abadger1999> Sounds good.
18:23:10 <mclasen> nirki: I agree
18:24:11 <nirik> #agreed Fesco is ok with showing bug numbers of private bugs. Or using some other method pkgdb maintainers wish like a disclaimer/link to query?
18:24:22 <nirik> #topic #560 Adding packages to EPEL without adding it to Fedora
18:24:22 <nirik> .fesco 560
18:24:28 <zodbot> nirik: #560 (Adding packages to EPEL without adding it to Fedora) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/560
18:24:59 <nirik> so, the question here is what level of maintainership we should require of people in fedora who also maintain packages in epel.
18:25:29 <nirik> In this case the package maintainer plans to support the package in rawhide and epel6 only.
18:26:00 <ajax> i don't really understand what that would mean...
18:26:01 <nirik> we already have some packages (and have for a while) that are epel only.
18:26:25 <ajax> given things get inherited from rawhide to fedora, how do you do something "rawhide-only"
18:26:29 <nirik> ie, compat packages for something in rhel thats not in fedora anymore, or alternate stacks (like python 26 for epel5)
18:26:50 <SMParrish_mobile> he clarified that he will maintain in f15+
18:26:58 <nirik> ajax: I think they mean that they wish to land the package only in devel, but will continue to maintain it in fedora over time.
18:27:06 <nirik> they simply don't want to maintain f13 / f14 / f15 branches.
18:27:17 <nirik> ok, my mistake... f13/f14
18:27:46 <notting> ???
18:27:47 <ajax> that seems utterly uncontroversial
18:27:53 <notting> we add new stuff only in rawhide all the time
18:28:11 <ajax> i mean, when i've newpkg'd things like pixman or libpciaccess because rawhide needs them, i don't branch them for older releases that don't need them
18:28:14 <nirik> notting: yep.
18:28:40 <tibbs|h> I think the basic issue was a misunderstanding.
18:28:41 <kylem> i'm with ajax on this one... most other distros just have stuff roll downhill like that... i think it would be unusual to add stuff to ancient releases as well.
18:28:45 <nirik> I'll also note in this case the package submitter is completly fine with people maintaining those branches they don't want to...
18:28:53 <nirik> tibbs|h: yeah, I think so too.
18:28:56 <tibbs|h> The packager originally indicated that he was not interested in Fedora but only in EPEL.
18:29:11 <tibbs|h> But that's not really what he meant.
18:29:35 <nirik> right, I think the mistaken impression was that they would build in rawhide and then when f15 came out they would just orphan it and not maintain it in any stable branches.
18:29:45 <tibbs|h> The question is still valid, though; we do expect maintainers to actually maintain their Fedora branches.
18:30:16 <nirik> I would say the supposition is: yes.
18:30:22 <tibbs|h> At least, we should.
18:31:03 <ajax> if you don't maintain at least one fedora branch, you're not really playing the same game as everyone else
18:31:08 <notting> sure, once it goes out in a fedora branch. but i don't see why we would require someone to put it there
18:31:21 <ajax> (assuming you build for fedora at all, of course)
18:31:50 <nirik> right, and in some cases it's makes no sense to be in fedora.
18:32:02 <kylem> i'm not sure i agree, if someone is only interested in epel, we shouldn't require people to care about something else. (yes, i realize there's man power issues for reviews and such) but signing volunteers up for things they don't want to do isn't really fair either.
18:32:02 <tibbs|h> I do expect that eventually we really will find a case of someone who really does not care at all about Fedora and gets packages in for EPEL only which would still be useful in Fedora.
18:32:14 <tibbs|h> But I don't think that's come up yet.
18:32:17 <kylem> if they don't care about fedora, someone else should maintain it in fedora...
18:32:31 <nirik> right.
18:33:03 <ajax> even if it does, it's in git, learn to branch.
18:33:04 <nirik> having a maintainer that cares about a package really is much more ideal than someone who doesn't. But you can't force someone to care about a package.
18:33:14 <kylem> agreed.
18:33:52 <notting> tibbs|h: i thought that was what chitlesh was doing
18:34:14 <tibbs|h> notting: I'm afraid I don't quite know what chitlesh is or was doing.
18:34:20 <nirik> proposal: re-iterate that package maintainers should follow all the responsibilities of being a package maintainer for all the branches that their package has. No requirement should be forced for which branches a maintainer can request.
18:34:50 <nirik> (well, thats probibly poorly worded... there are requirements for which branches... ie, not things that don't exist, etc)
18:35:01 <mclasen> nirik: the much bigger constraint that caring is time...
18:35:42 <nirik> yeah, true.
18:35:51 <tibbs|h> Personally I think EPEL is a neat thing and but if it begins to actually be detrimental to Fedora then someone's going to have to think about how to handle that.
18:36:20 <tibbs|h> Currently there's some detriment due to the epel-only stuff in the review queue, but it's not a huge deal.
18:37:06 <ajax> i would think the fedora community could reasonably say "look, these are addons for a non-free product, if you want them reviewed promptly hire someone who's competent to review them"
18:37:43 <tibbs|h> To be fair, CentOS is free.
18:38:11 <tibbs|h> But if it gets bad I'll make a separate EPEL-only review queue, I guess.
18:38:12 <nirik> so, what do we wish to do here? does anyone have a better worded proposal to vote on?
18:38:13 <ajax> true.  but that suggests its own pool of potential reviewers.
18:38:37 <nirik> tibbs|h: yeah, we could do that I suppose... Package Review component under Fedora EPEL.
18:38:53 <tibbs|h> Or just something in the whiteboard.
18:39:01 <ajax> nirik: +1 to your proposal, the wording's a little awkward but not misleading.
18:39:12 * notting is +1 to it as well
18:39:19 <nirik> a query for it would be nice... then I could try and ask epel folks to do more reviews on those.
18:39:43 <tibbs|h> I tried pinging EPEL folks for a while, but didn't have all that much luck.
18:39:48 * nirik is +1 as well, wishes there was a better way to phrase it.
18:41:15 <nirik> any other votes or comments?
18:41:20 <kylem> pardon my ignorance, couldn't we synergize branch requests and review requests somehow, so that reviewers could actively avoid epel-only things or something. (thus ensuring a lesser amount of 'detrimental-ness'?)
18:41:24 <kylem> +1 to the proposal.
18:41:43 <nirik> kylem: yeah, thats what we were talking about above. ;)
18:41:44 <notting> kylem: pre-declare what you're intending to branch for?
18:41:50 <kylem> notting, yeah
18:42:00 <gholms> FWIW, doesn't that usually happen in epel-only review requests?
18:42:16 <kylem> (tbh i'm entirely ignorant about rhel/epel/centos, happily i think. :)
18:42:29 <mjg59> +1
18:43:21 <nirik> I guess the things currently that would be epel only would only be the python26 stuff.
18:43:28 <nirik> or if a new compat package came along.
18:43:46 <ajax> i'm sure someone will want boost or openssl compat someday
18:44:16 <nirik> #agreed proposal: re-iterate that package maintainers should follow all the responsibilities of being a package maintainer for all the branches that their package has. No requirement should be forced for which branches a maintainer can request.
18:44:24 <nirik> ajax: some say this has already happened. ;)
18:44:33 <nirik> (there is a boost epel only review pending)
18:44:48 <nirik> .bug 673839
18:44:50 <zodbot> nirik: Bug 673839 Review Request: boost141 - The free peer-reviewed portable C++ source libraries - https://bugzilla.redhat.com/show_bug.cgi?id=673839
18:44:53 <nirik> #topic Open floor
18:44:59 <nirik> anyone have anything for open floor?
18:45:10 * gholms raises hand, begins typing
18:45:20 <nirik> => gholms go ahead
18:46:54 <gholms> Systems running branched but unreleased releases have updates-testing enabled by default until shortly before release.  At that point people end up with packages that never made it out of testing installed, but not in enabled repos.
18:47:14 <gholms> This can cause occasional breakage when installing things.  Is FESCo all right with this?
18:47:33 <gholms> People can run dist-sync, but that's a manual step.
18:47:38 <ajax> ick.
18:47:58 <notting> presumably they'd make it out of updates-testing at some point. but that's not always the case
18:48:10 <ajax> i'd be okay with that if everything in -testing got tagged into the release, i guess
18:48:21 <ajax> otherwise, yeah, people will forget things
18:48:23 <kylem> erk. yeah, that's a nasty one.
18:48:38 <nirik> well, I think the idea was that people installing pre-releases should be helping us test... so should have testing enabled.
18:48:48 <nirik> but they could also test without that of course.
18:49:07 <gholms> For that matter, testing-by-default makes using bodhi for branched prereleases largely superfluous.
18:49:27 <kylem> maybe we just need to heavily lart people as we approach release to make sure packages from testing are moving properly.
18:49:28 <gholms> (I could be wrong about that last bit, though)
18:50:19 <lmacken> wg 29
18:50:20 <nirik> well, it's still usefull as composes don't use testing.
18:50:25 <nirik> ie, the base stuff is all in stable.
18:50:39 <gholms> Right, but no one runs stable.
18:50:50 <mclasen> snapshots / alpha / beta do
18:50:54 <ajax> well, we had that upgrade-path test script a while ago that would tell you about EVR inversions
18:51:01 <nirik> well, we don't know that... ;) You can disable updates-testing pretty easily.
18:51:26 <ajax> we could probably just run that against -15 and -15-updates-testing and have it whine on the mailing list, as a first cut
18:51:28 <gholms> mclasen: They do until after they install and PK tells them there are a bunch of updates all from updates-testing.
18:51:39 <ajax> i don't know that it's really so critical that we need to change policy, yet.
18:52:00 <nirik> I could see it going either way...
18:52:05 <nirik> or perhaps we should change it at beta ?
18:52:13 <gholms> My main complaint is that people who install beta have to go backwards at release time, which is a manual step.
18:52:18 <nirik> or perhaps we should ask rel-eng / qa for their thoughts.
18:52:18 <kylem> nirik, that's not a bad idea.
18:52:54 <nirik> gholms: yeah, I remember in f14 there were a number of people who installed from prereleases and then had some yum issues later (I think there was a newer glibc or something in testing right before release)
18:53:01 <nirik> but it wasn't too bad to fix.
18:53:32 <gholms> Yeah, it's not hard to fix, but the problem is non-obvious to people who don't know how the repos interact.
18:53:46 <ajax> sometimes, even to people who do.
18:54:25 <nirik> so, does someone have a proposal for what to do here?
18:54:50 <gholms> I'm hesitant to just propose "No updates-testing by default".
18:55:00 <gholms> …but that IS an option.
18:55:06 <ajax> i'd talk to rel-eng, really.
18:55:40 <ajax> it's a process wart but i don't have a good feel for how crucial it is or whether changing the rules would make life worse somewhere else.
18:56:17 <nirik> gholms: yeah, how about pinging rel-eng and qa about it and see if they have thoughts?
18:56:31 * nirik is wondering if changing it at beta would be a good compromise.
18:56:32 <gholms> They have lists, right?
18:56:36 <nirik> yep.
18:56:43 <nirik> test list and rel-eng list.
18:56:59 <gholms> An easy alternative would be just documenting "run yum distro-sync" after release" for beta users.
18:57:14 <gholms> Gah, too many "s
18:57:38 <nirik> yeah, although people don't read docs. ;)
18:57:53 <nirik> gholms: can you do that? or would you like me to?
18:58:19 <gholms> nirik: I can if you want me to, though I think it might be taken more seriously if it came from you.
18:58:30 <gholms> But if you want me to I'm fine with that.
18:58:51 <nirik> if you could that would be great...
18:58:56 <gholms> Okee dokee
18:59:05 <nirik> #info gholms to ask rel-eng / qa about updates-testing enabled by default.
18:59:14 <nirik> Thanks for bringing it up.
18:59:19 <nirik> Any other topics for open floor?
18:59:40 <gholms> Should I post to both the test and rel-eng list?
18:59:42 <gholms> *lists
19:00:04 <nirik> sure.
19:00:25 * nirik will close out the meeting in a minute if nothing else comes up
19:00:57 <ajax> nothing from me
19:01:17 <nirik> Thanks for coming everyone!
19:01:20 <nirik> #endmeeting