Summary/Minutes from today's FESCo meeting (2010-06-01)

Kevin Fenzi kevin at
Tue Jun 1 20:53:08 UTC 2010

Forgot to attach minutes: 

19:00:03 <nirik> #startmeeting FESCO (2010-06-01)
19:00:03 <zodbot> Meeting started Tue Jun  1 19:00:03 2010 UTC.  The chair is nirik. Information about MeetBot at
19:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:03 <nirik> #meetingname fesco
19:00:03 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:00:03 <nirik> #topic init process
19:00:03 <zodbot> The meeting name has been set to 'fesco'
19:00:03 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:00:12 <pjones> it's that time again
19:00:29 <kylem> _o/
19:00:35 * notting is here
19:00:36 <ajax> i think so, brain, but if they called them sad meals, kids wouldn't buy them
19:00:40 <nirik> cwickert indicated that he would not be making this meeting or likely the next
19:00:45 * SMParrish here
19:00:55 <nirik> mclasen indicated that he would be a bit late.
19:02:01 <nirik> welcome to the fun SMParrish, kylem
19:02:17 <SMParrish> 8-)
19:02:44 <nirik> #info cwicket will be unable to attend. mclasen will be a bit late.
19:02:55 <nirik> ok, I guess we can go ahead and get started...
19:03:01 <nirik> #topic Elect Chair
19:03:06 <ajax> it's storming pretty spectacularly here, so if the power cuts, so will my network access
19:03:17 <nirik> I'm happy to keep chairing... but if someone else really wants to take over thats fine with me too.
19:03:31 <mjg59> I've no complaints with nirik's work
19:03:32 * notting is fine with nirik continuing
19:03:36 <pjones> I'm +1 to keep you doing it
19:03:38 <kylem> i'm happy with that if you want to continue. thanks for doing it.
19:03:49 <SMParrish> +1 to keeping nirik in the hotseat
19:04:10 <nirik> ok...
19:04:40 <nirik> #agreed nirik will keep chairing for now.
19:04:48 <nirik> #topic New meeting time?
19:04:58 <nirik> So, how well does this time work for our new folks?
19:05:13 <nirik> mclasen has a conflict at the beginning, so we might want to adjust based on what he can do...
19:05:19 <nirik> SMParrish / kylem ?
19:05:30 <SMParrish> Should be fine for me, new schedule should have me off on Tuesdays
19:05:43 <notting> from what he said, he has a conflict both at the beginning and at the end (of our longer meetings)
19:05:45 <kylem> the time is fine for me (both for the foreseeable, and when i'm back in north america.)
19:05:59 <mjg59> Possibly best to run another of those whencanyoumakeit or whatever thingies?
19:06:17 <ajax> whenisgood
19:06:42 <nirik> yeah, I guess we can do that...
19:06:55 <nirik> or the fine google wave thing. ;)
19:07:52 <nirik> I can setup one I guess.
19:08:12 <nirik> #action nirik will setup a whenisgood and will adjust next weeks meeting based on that.
19:08:37 <kylem> groovy.
19:08:51 <nirik> ok, anything else on this? or shall we move along...
19:09:34 <ajax> next
19:10:08 <pjones> sounds good
19:10:20 <nirik> #topic #385 Zim / zim package issues.
19:10:20 <nirik> .fesco 385
19:10:22 <zodbot> nirik: #385 (Zim / zim package issues.) - FESCo - Trac -
19:10:36 <nirik> so, this is a bit of a fun one.
19:10:42 <nirik> I summarized in the ticket.
19:10:52 <ajax> (bong noises)
19:11:02 <pjones> I don't have a problem with the guy forking this if that's really what he wants to do, but I think he should rename it as well, and leave the package tracking upstream.
19:11:10 <pjones> I'm kindof betting he's not going to want to do that, though.
19:11:16 <pjones> also what ajax said ;)
19:11:38 <kylem> i looked at the bug and such earlier, i'm of the same opinion as peter... upstream had the name first, it should trump a fork.
19:11:49 * nirik nods. I agree.
19:11:57 <SMParrish> I agree with pjones on this form and rename
19:11:58 <nirik> What about the 'Zim' vs 'zim' rename?
19:12:00 <SMParrish> s/form/fork
19:12:34 <pjones> It seems like as Fedora we shouldn't really care if he forks it or not, but we want the package tracking what upstream does.  And if he does fork it, he ought to pick something very distinct as the name for the new thing, just because it's kindof a dick move not to.
19:12:47 <notting> yeah, name the fork 'InvaderZim', or whatever.
19:12:53 <pjones> users don't benefit from having name collisions (or almost collisions as in zim vs Zim)
19:12:59 <kylem> agreed.
19:13:05 <ajax> yeah, perl-zim should be renamed dib or something
19:13:08 <sgallagh> IANAL (or on FESCO) but I think there would be trademark issues with keeping the name as well
19:13:32 <pjones> ajax: or mvz
19:13:43 * mclasen apologizes for showing up late
19:13:49 <pjones> sgallagh: only if there's a trademark, etc.  but that's not really an issue for us.
19:13:58 <nirik> ok, so, that leaves us with: a) reassign Zim to the new person who wants to maintain it, b) accept the 'zim' package review that obsoletes Zim, c) something else?
19:13:59 <pjones> if he forks it, that really has nothing to do with fedora.
19:14:12 <nirik> mclasen: welcome. No worries.
19:14:59 <ajax> so, since i think i hear rough consensus: "zim", the new python thing, gets the right to the name in fedora.  if the perl version forks, we'll name it something else, and we would encourage them to rename it to something unambiguous.
19:15:18 * nirik nods. I agree with that.
19:15:22 <kylem> ditto.
19:15:25 <pjones> yeah, that's what I'm saying.
19:15:31 * SMParrish agrees
19:15:45 <ajax> me, nirik, pjones, kylem, smparrish. +5.
19:15:49 <mjg59> +1
19:16:06 <nirik> #agreed The upsteam zim (python) should have that name in fedora. The forked version of Zim (perl) can rename itself to something else and get reviewed/imported seperately.
19:16:19 <nirik> So, we just need to decide the Zim vs zim name.
19:16:31 <ajax> zim-perl, if all else fails?
19:16:37 * notting is +1
19:16:44 <mjg59> I don't see zim being confusing to anyone
19:16:49 * mclasen scrambles to find the agenda
19:16:51 <nirik> ajax: sure... just !zim or !Zim
19:17:13 <pjones> "yum search zim" returning two things with a capital letter difference and the same description is /terrible/.
19:17:37 <nirik> mclasen:
19:17:44 <mclasen> nirik: thanks
19:17:55 <SMParrish> Use 'zim' and have it obsolete 'Zim'
19:17:58 <nirik> pjones: well, the 'zim' package obsoletes Zim
19:18:17 <nirik> the problem is that we might hit corner cases in pkgdb or something...
19:18:23 <nirik> but I suppose those could be fixed.
19:19:04 <pjones> Oh, sorry, I misread.
19:19:09 <SMParrish> can we just dead package 'Zim'
19:19:19 <pjones> yeah, I don't really care which letter the new python version picks.
19:19:24 <nirik> yes... but it will still exist in pkgdb
19:19:35 <nirik> and in cvs
19:19:37 <nirik> and etc.
19:19:52 <sgallagh> Is the version number bumped, at least?
19:20:01 <nirik> I think so.
19:20:02 <mclasen> is that the first case of a case-only packagename difference ?
19:20:05 <pjones> it'd be slightly preferable for it to use 'zim' and for us to eliminate all traces of 'Zim' from everything
19:20:15 <pjones> OR... maybe I got that backwards.
19:20:19 <SMParrish> but it wont get further branches in cvs so will eventually fade away
19:20:22 <nirik> there was one other one. Let me find the info
19:20:41 <nirik> see abadger's comments in
19:21:52 <notting> mclasen: we did a SysVinit -> sysvinit rename at one point
19:22:29 <nirik> I think there have been font packages that renamed ok.
19:22:33 <mjg59> Why do we want to rename?
19:22:33 * abadger1999 is here for questions
19:22:42 <abadger1999> Renaming works fine.
19:22:55 <pjones> renaming is fine, but it seems... inane?  unnecessary? useless?
19:22:57 <nirik> well, depends on what you mean by rename I guess.
19:23:02 <abadger1999> VLGothic-fonts => vlgothic-fonts  exposed some bugs that should all be fixed now.
19:23:12 <pjones> it'd be preferable for the new python package to keep the old name.
19:23:24 <nirik> abadger1999: will there be problems with us allowing a 'zim' package that obsoletes 'Zim' and making Zim dead.package ?
19:23:40 <pjones> as much as I think upper case letters are bad ideas in package names, I don't really see changing things as being better.
19:23:45 <abadger1999> nirik: There should be no technical problems -- if there ware they're issues that we need to fix anyway.
19:23:52 <mjg59> I really must be missing something here
19:23:57 <mjg59> What's the problem with it being called Zim?
19:24:14 <nirik> the case has changed upstream in their release.
19:24:20 <nirik>
19:24:24 <pjones> I think we re-assign the old package to the new maintainer, let him put in the perl one, and let the fork submit their package when it's actually a fork.
19:24:26 <nirik> used to be Zim is now zim
19:24:41 <pjones> er
19:24:45 <pjones> let him put in the python one.
19:24:53 <pjones> damn, but I'm getting typing wrong on this issue.
19:24:59 <mjg59> I think upstream changing their mind over a capital letter doesn't seem to be worth renaming a package
19:25:08 <kylem> mjg59, indeed
19:25:21 <pjones> yeah, we've never required that package names have to match upstream's capitalization scheme before, I don't know why we'd start now.
19:25:51 <mjg59> proposal: Python code is packaged as Zim, perl code must be renamed and coexist reasonably
19:26:00 <pjones> mjg59: +1
19:26:02 <nirik> "When naming a package, the name should match the upstream tarball or project name from which this software came"
19:26:14 <pjones> nirik: should, not must.
19:26:38 <pjones> tbf, I really don't care which they choose.  It's up to the (python) maintainer.
19:26:43 <pjones> the fork needs to be named something else.
19:26:53 <kylem> it also doesn't specify case sensitive or insensitive matching. :)
19:27:02 <kylem> anyway.
19:27:08 * abadger1999 agrees with pjones' on what's imprtant here.
19:27:09 <mjg59> nirik: It matches the project name regardless of case
19:27:20 <pjones> kylem: I think probably the naive understanding of "match" is probably the one we should go for ;)
19:27:27 <pjones> but again: it doesn't matter.
19:27:27 <nirik> well, the project name really is 'zim-wiki'... ;)
19:27:37 <nirik> anyhow, I am ok with that...
19:27:47 <nirik> +1 to mjg59's proposal
19:27:51 <kylem> +1
19:28:10 <nirik> does that imply we reassign the package ownership?
19:28:10 <SMParrish> +1
19:28:22 * notting is +1 to either pjones or mjg59's proposal
19:28:52 * nirik guesses the zim submitter will complain about being forced to name it Zim.
19:28:54 <mclasen> yeah, +1
19:29:10 <mclasen> maybe amend the package naming guidelines to mention that case-only difference is not a good idea
19:29:17 <kylem> nirik, we can cross that bridge when it comes to it.
19:29:40 <nirik> kylem: true.
19:29:43 <skvidal> mclasen: don't they already say 'no' to that?
19:29:52 <nirik> mclasen: they do forbid that.
19:29:58 <mclasen> ah, ok
19:30:21 <nirik> so really this new 'zim' package should have been flagged for that much sooner.
19:30:35 <mclasen> clear case of 'si tacuisses', then...
19:30:41 <nirik> #agreed Python code is packaged as Zim, perl code must be renamed and coexist reasonably
19:30:52 <nirik> so, do we reassign the Zim package ownership?
19:31:22 <SMParrish> nirik: since we are keeping the name I would say yes
19:31:30 <pjones> it's weird, and more than I really prefer being involved in other maintainer's decisions, but I think the current maintainer is basically opting out.
19:31:43 <pjones> so yes?
19:32:23 <nirik> yeah, they haven't answered my emails...
19:32:36 <nirik> but I know they are otherwise active. I have seen reviews from them, new package submissions, etc.
19:33:38 <nirik> proposal: add zim submitter as maintainer of Zim package.
19:33:45 <pjones> that makes this pretty delicate - we certainly don't want to alienate the old maintainer.
19:33:50 * nirik does not want to do this without a vote.
19:34:14 <pjones> I think adding the new maintainer as a co-maintainer and letting the current maintainer move to his fork if/when he wants to is probably best, but still icky.
19:34:22 <notting> well
19:34:30 <notting> if we are already stating that the fork must rename
19:34:32 <kylem> why don't we ask politely, and if he doesn't respond in a week, then we take more drastic action?
19:34:38 <mjg59> Is there any reason to think that the maintainers won't just sort this out themselves if we give them our opinion?
19:34:41 <notting> should we just wait and see if the maintainers DTRT?
19:34:44 <mjg59> Yeah
19:34:47 <pjones> mjg59: that's what I'm wondering
19:34:49 <mclasen> can we first tell them our decision on the naming issue, and ask them to resolve package ownership peacefully ?
19:34:57 <mjg59> I think just mention this in the ticket and the bug and then revisit if things don't work out
19:35:00 <ajax> sounds like a wise idea to me.
19:35:05 <pjones> I'm +1 to the mclasen/mjg59 plan
19:35:20 <nirik> well, they haven't in months.
19:35:24 <kylem> i mean, a week one way isn't going to mean slipping a release now, or something.
19:35:40 <pjones> nirik: but they haven't had our decision on naming as a guideline, either.
19:35:48 <SMParrish> Give them a week to work it out if they done then we step in
19:35:49 <pjones> nirik: also: if they haven't in months, can another week really hurt?
19:35:59 * abadger1999 is with nirik on this one... it's been escalated to fesco b/c the maintainers couldn't work it out.
19:36:23 <nirik> last response from the Zim maintainer was 2010-03-27 12:45:37 EDT
19:36:30 <pjones> I'm not against making this decision for them as a last resort, but I do think we should give them the opportunity to decide how they want to do it based on our package input.
19:36:31 <mjg59> abadger1999: There's a difference between presenting our opinion and enforcing our opinion
19:36:34 <nirik> so 2 months of limbo
19:37:55 <nirik> if folks want I can tell them we want the python version as Zim and ask them to work it out for a week...
19:38:03 <nirik> I just think there is little chance of that.
19:38:06 <mjg59> That's be my preference
19:38:31 <pjones> I really would prefer we give them that opportunity to resolve this... peacefully.
19:38:31 <ajax> same.
19:38:31 <nirik> but then the zim submitter I suspect will not like the naming anyhow, so I guess we would have to address that again anyhow.
19:38:31 * SMParrish agrees
19:38:48 * nirik waits for more votes.
19:38:54 <mjg59> I think it's insane to change a package name purely because upstream has changed the case of a letter
19:39:11 <pjones> tbh, we don't have to /force/ them to do 'Zim' v 'zim'; I think we can leave that out entirely and let them do as they please.
19:39:25 <pjones> I think the perl fork shouldn't get either, and the python version should get whatever they happen to land on.
19:39:42 <mjg59> Anyway. I'm +1 to telling the submitter that the package name should remain Zim, the maintainer that their fork should be renamed and that we leave at least a week to see if they handle this before we attempt to enforce anything
19:39:46 <nirik> pjones: I would agree with that, which likely would mean the Zim->zim rename. ;)
19:39:46 <SMParrish> But what would it hurt to call it zim and obsolete Zim, thta solves the ownership issue as well
19:39:58 <pjones> nirik: yeah, I really don't care about that facet.
19:40:13 <nirik> pjones: right, but I think the zim submitter and mjg59 do. ;)
19:40:20 <abadger1999> nirik: Well.. naming is actually silly -- we'd allow them to rename the package after they become maintainer anyway...
19:40:22 <pjones> SMParrish: it hurts the people who already have the package name in their muscle memory, but that's about it.
19:40:22 <nirik> (in opposite directions)
19:40:48 <nirik> abadger1999: via a new review, etc.
19:40:51 <mclasen> pjones: there would probably provides / obsoletes in the new package anyway, no ?
19:40:57 <abadger1999> nirik: Yep.
19:40:59 <nirik> mclasen: there are.
19:41:06 <mjg59> On the other hand, I think we're past the point where anything new and interesting is going to come out of this discussion
19:41:13 <mclasen> so muscle memory is preserved...
19:41:15 <pjones> mclasen: there would have to be (and there are), yes.
19:41:20 * nirik realizes he forgot his 15min timer. ;(
19:41:39 <pjones> mjg59: you're probably right.
19:41:39 <nirik> mjg59: yes, but we need some resolution.
19:41:46 <nirik> So, votes to keep going on this topic?
19:41:51 <mjg59> -1
19:41:53 <kylem> -1
19:41:55 <nirik> +1 from me, I would like to have a decision here.
19:42:10 <mjg59> I thought we'd made a decision several times over
19:42:21 <abadger1999> nirik: How many votes are you missing?
19:42:23 <nirik> well, on part of it.
19:42:24 <pjones> does anybody object to telling them our opinion about "[zZ]im" being the python package and the fork getting something new, and then letting them settle it?
19:42:30 <pjones> and if that doesn't work, we can revisit?
19:42:47 <ajax> no objection here.
19:42:49 <abadger1999> (with a 1 week doesn't work period)
19:42:51 <nirik> abadger1999: 1 more to tell them our decision and wait a week.
19:43:12 <nirik> pjones: I don't object to that, but mjg59 does to the lower case zim name there.
19:43:16 <SMParrish> +1 to pjones proposal
19:43:58 <nirik> ok, fine... +1 to pjones proposal.
19:44:00 <notting> pjones: no objection
19:44:05 <mjg59> I think it's insane to change package names like that, but if the people who actually need to do the work are happy to do the work then it's not a real problem
19:44:22 <nirik> ok, I think thats passed.
19:44:38 <pjones> mjg59: I totally agree.
19:45:05 <nirik> #agreed notify maintainers about [Zz]im being the python package and the fork gets a new name, revisit next week
19:45:15 <nirik> is that ok to everyone?
19:45:21 <kylem> yup.
19:45:24 <mclasen> yes
19:45:29 <SMParrish> yes
19:45:39 <ajax> hooray.
19:45:47 * nirik notes that this is almost sure to result in: no answer from Zim maintainer and zim submitter asking why wait a week, but ok.
19:45:56 <nirik> ok, on to the fun topics. ;)
19:46:03 <nirik> #topic #382 Implementing Stable Release Vision
19:46:03 <nirik> .fesco 382
19:46:04 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac -
19:46:18 <nirik> so, the Board gave us a "Stable release vision" a while back.
19:47:20 <nirik> first they want to know if we agree with it or would like them to revisit parts of it.
19:47:38 <nirik> Then when/if we are going to implement it. ;)
19:48:11 <drago01> "only fix bugs and security issues. " ... the word "only" kind of worries me ... that would mean backport hell like rhel for many packages
19:48:34 <nirik> We have a new updates policy we are working on implemented that should cover/overlap with some of this, but not all
19:48:38 <ajax> "like rhel" is a bit of an overstatement.
19:48:45 <ajax> given that fedora lives for a year, and rhel for seven.
19:49:04 <pjones> drago01: I was interpreting that to mean no major version changes, and not to mean "isolate fixes in minor version changes and backport them without the minor version change"
19:49:25 <pjones> (where neither of those statements necessarily has anything to do with version numbers)
19:49:59 <drago01> pjones: I'd be fine with that but I don't want to start doing backports because upstream did not _only_ fix bugs but added small features that nobody cares about or don't change anything significantly anyway
19:50:03 <mjg59> In terms of what we can do technologically:
19:50:43 <mclasen> drago01: it is clearly easier if your upstreams have a notion of 'stable/devel branch'
19:50:54 <nirik> The things that worry me from an implementation standpoint are: finding/noticing "user experience" changes, and all the measuring section. It's hard to measure this stuff in a qualitative way, imho.
19:51:00 <drago01> mclasen: yeah but "if"
19:51:19 <SMParrish> The "No major version updates" works when your upstream releases about the same time as Fedora.  The stability proposal I wrote for KDE allows for one major update per Fedora release which I think makes sense, atleast for KDE
19:51:39 <brunowolff> It would be nice if there was an exception process for things that need to sync up with stuff outside of Fedora.
19:52:02 <brunowolff> Multiplayer games often need to match versions with other players or game servers.
19:52:19 <notting> i think discussing an exception process before we have a policy written down is probably putting the cart before the horse
19:52:35 <pjones> brunowolff: there is always an exception process of "take it to FESCo" if all else fails
19:52:48 <pjones> but notting is probably right
19:52:55 <nirik> so, yeah.. this is a 'vision'... it needs to go to being a policy, then be implemented.
19:53:14 <nirik> could we fold in more things to our existing as yet not implemented policy?
19:53:33 <nirik> .fesco 351
19:53:34 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
19:53:47 <mjg59> Is it worth stating that nvr should always be monotonic through successive releases, and actively enforce that?
19:53:51 <notting> well, the existing policy is more ... technological; it's at least somewhat designed to be an automatable process
19:53:53 <nirik>
19:54:01 <pjones> mjg59: oh god, no.
19:54:02 <drago01> notting: well the wording of the policy "only" don't leave much room for anything ... also adding support for new hardware should be allowed (i.e I agree with the overall idea to have more stable updates but this might be a bit to restrective)
19:54:05 <notting> having restrictions on *types* of updates, or what versions go in them, can't really be automated
19:54:31 <nirik> notting: right, detecting 'user experence' changes in an automated way is... not likely.
19:54:34 <drago01> mjg59: no
19:54:39 <pjones> mjg59: that kind of restriction only results in more creative versioning schemes.
19:55:01 <notting> mjg59: well, tests for upgrade paths can certainly be done as part of autoqa
19:55:25 <mjg59> Well, I think it's a prequisite for any real technical implementation of the proposal
19:55:40 <nirik> mjg59: autoqa / out new policy should enforce that.
19:55:45 <nirik>
19:55:52 <nirik> is the link I was meanting to paste above.
19:56:06 <drago01> well there is no way to technically implement this
19:56:19 <Oxf13> if I might interject.  Focusing on "major version" as a value of a number is probably going to fail, because different upstreams use numbers differently to express things
19:56:24 <mjg59> I'd like to say "Critpath packages cannot be updated to the same version as is in a later release without a certain amount of time passing"
19:56:35 <drago01> you could add some heuristic but they will be wrong in to many cases
19:56:43 <pjones> Oxf13: I've mentioned twice now that discussing version numbers specifically is a bad idea.
19:56:50 <notting> well, there's certainly the 'updates czar with a stick' solution.
19:56:51 <Oxf13> pjones: yeah, you have.
19:56:54 <drago01> the only way this would work is to have people check the updates and verify that they comply with the policy
19:57:11 <Oxf13> drago01: that's one method of enforcement.
19:57:23 <Oxf13> having policy in the first place will guide maintainers into doing the right thing
19:57:28 <mjg59> The alternative is to grade the amount of time between -testing and -stable in any release
19:57:44 <pjones> I think we need to focus more on people understanding how they're supposed to do it than "enforcement".
19:57:53 <mclasen> drago01: thats why it is a vision; finding ways to implement some of it falls onto us...
19:57:58 <pjones> and for that we need clear policies.
19:58:02 <mjg59> So a week in stable, two weeks in stable-1, whatever in rawhide
19:58:05 <Oxf13> pjones: right, I totally agree with that.
19:58:16 <drago01> pjones, mclasen : *nod*
19:59:31 * nirik notes we have which could be updated to this vision.
20:00:19 <nirik> so, not sure where we will get to today on this. Perhaps we should schedule a special session with the Board and work on any changes we want to the vision before going too far down the implementation path?
20:00:30 <nirik> or does everyone agree with the vision as written ?
20:00:43 <mjg59> The vision as written seems reasonable to me
20:00:58 <kylem> seems reasonable to me as well.
20:00:59 * mclasen has no objections to the vision
20:01:13 <pjones> I don't think we necessarily need more input from the board on this (unless they have some compelling wish to put forward a vision that's less vague - hah!)
20:01:35 <mjg59> I think the real point of discussion is how much of this we want to be policy and how much we want to be enforced via technical means
20:01:37 <nirik> I think some of this is going to be difficult to objectvely measue... the last bullet may be not possible.
20:01:45 <mjg59> Also, how much *can* be enforced via technical means
20:02:14 <nirik> right.
20:02:42 <notting> mjg59: and whether we want to be the bad guys?
20:02:47 <pjones> nirik: I think the last is measurable if we treat it as a metaphor - we need to make specific criteria for judging if it works (lower rate of updates, that sort of thing), and those need to be measurable.
20:03:01 <nirik> we could measure bugs filed per release/component... or look at bodhi karma as a indicator of more testing, if there is more usage of rawhide/branched releases...
20:03:23 <nirik> yes, slower rate of updates might indicate something.
20:03:30 <pjones> nirik: I guess what I'm saying is that we also have to define it's effectiveness.
20:03:43 <nirik> right. It could mean several things. ;)
20:03:53 <pjones> which isn't necessarily going to match up word for word with the vision, but it's not intended to.
20:04:06 <nirik> ok, we are at 15min on this topic. Votes to go on?
20:04:22 <nirik> I'd like to move forward on this, but not sure what the best way to do that is.
20:04:52 <notting> +1 ,  don't want to table this just yet
20:05:02 <kylem> +1
20:05:06 * nirik is a weak +1 to going on.
20:05:15 <pjones> I think a) this is going to be ongoing, and something we need to think about generally rather than a single item to Conform To The Vision, and b) somebody needs to write specific proposals if they think there are specific ways we could better comply with the vision.
20:05:25 <pjones> (oh no, I'm arguing for "we need to do more work")
20:05:38 <SMParrish> +1 to continue discussion but would like to see a resolution soon
20:06:01 <kylem> well, it sounds like we agree with the vision, which is a start.
20:06:25 * nirik sees 4 +1's to continuing... one more?
20:06:40 <mclasen> sure, +1
20:06:50 <nirik> ok. on we go. ;)
20:07:47 <nirik> ok, so I think our current updates policy change is addressing point 1 and the second to last point, but none of the rest.
20:07:56 <nirik> "The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates."
20:08:20 <nirik> well, I guess not even the second to last.
20:09:08 <nirik> so, we need to: a) update our packager guidelines to note the other items in the vision, b) come up with ways to measure
20:09:31 <nirik> then if b shows we are failing, look at c) enforce somehow
20:09:54 <SMParrish> I do think we need to take into account other DEs release schedules and include policies that allow for atleast 1 major bump per Fedora release
20:10:15 <nirik> SMParrish: that could be part of an exception process?
20:10:49 <notting> SMParrish: i'm curious ... why do DEs need this when other things don't?
20:11:30 <mjg59> SMParrish: That does seem to go against the stable release vision
20:11:44 <SMParrish> notting: not saying other items dont but DEs are relativly major parts of the user experience
20:11:57 <mjg59> SMParrish: Right, which is a good argument for them not being bumped within a release
20:12:09 <notting> ... right, which means they would be the *most* user-visible experience change
20:12:13 <pjones> and here we are again.
20:12:17 <SMParrish> mjg59: In a way yes but how to you tell someone that just becase there preferred DE release 1 month after Fedora that they have to wait 5 more months to experience it
20:12:38 <pjones> SMParrish: you don't - you make another repo of "updated DE for those that want to try it out before next release"
20:12:45 <nirik> SMParrish: do you have any influence with upstream release schedules?
20:13:23 * pjones thinks KoPeRs or something similar is the Right Way for that scenario.
20:13:27 <SMParrish> nirik: No we have no influence there.
20:13:52 <nirik> bummer. ;(
20:14:14 <mjg59> SMParrish: I'm certainly not averse to a mechanism for making major releases available to users of stable releases, but I don't think it's in line with what the board described to do so to an otherwise unexpecting user
20:14:43 <nirik> the real problem is that in some cases upstream releases N+1 and stops supporting N.
20:14:47 <ajax> SMParrish: while i can appreciate the sentiment there, other DE's _don't_ do this, even though they have a comparable release beat to fedora.
20:14:53 <ajax> f12 doesn't have gnome 2.30.
20:15:36 <SMParrish> ajax: and when 4.5 KDE does release I would say it goes to F13 but not F12, F12 would have already had its one bump to 4.4
20:16:10 <ajax> that's significantly more sane than how kde's been updated in fedora in the past, yeah.
20:16:30 <nirik> SMParrish: when 4.5 comes out, does support stop for 4.4?
20:16:58 <SMParrish> nirik: Yes, no bug fixes etc..
20:17:06 <ajax> i suppose i could let that slide, to the extent that we get some data on how disruptive such updates are.
20:17:11 <mjg59> SMParrish: My concern is that the 4.4 update in F12 /did/ cause problems for various users
20:17:40 <Oxf13> mjg59: that's just hard to balance against upstream abandonment
20:17:40 <SMParrish> ajax: I proposed a KDE stability guideline after the last FUDCon but we delayed a vote on it until this was resolved
20:17:41 <pjones> the 4.4 update shouldn't have happened in F12 - it should have been in a separate repo for those who wanted it, and should have been in F13.
20:17:48 <Oxf13> really it's a case of upstream sucks
20:17:57 * abadger1999 disagrees with copr being the "right way" for anything.... but we might end up with a lot of things shoved in there anyway.
20:18:07 <pjones> upstream stopping maintenance of the old version is... really, amazingly unfortunate.
20:18:21 <mjg59> Oxf13: It is, but really, isn't that what we have maintainers for?
20:18:24 <pjones> abadger1999: I'd actually prefer a slightly different version of Oxf13's proposal, but it's better than nothing.
20:18:24 <nirik> yeah, I personally would say this could be addressed with an exception... and really try and press upstream for a better schedule.
20:18:25 <notting> it's not *that* uncommon, though. see mofoco.
20:18:44 <SMParrish> mjg59: Yes it did, which is why I think major bumps like that should be optional for the user, but they need to be in an official Fedora repo
20:18:44 <ajax> and X, for that matter.  although at least there cherry-picking is occasionallystraightforward.
20:18:46 <Oxf13> mjg59: sadly most of our maintainers seem to be only able to jump the hurdle of working a spec file, not doing actual code backporting
20:18:48 <pjones> nirik: or for, I don't know, releasing software they could commit to maintaining.
20:18:49 <ajax> (i have a space bar, really)
20:19:08 <mjg59> SMParrish: Ok, we just need to find a way to make that possible
20:19:10 <kylem> Oxf13, then they're 'packagers' if that.
20:19:11 <nirik> pjones: fantasy world! :)
20:19:18 <Oxf13> kylem: that is correct
20:19:21 <pjones> nirik: yep
20:19:25 <mjg59> Perhaps we need to be able to separate "security" and "feature" streams within a release?
20:19:28 <Oxf13> kylem: Fedora has gone way off in the side of "packagers"
20:19:36 <kylem> Oxf13, indeed.
20:19:47 <Oxf13> kylem: amount of packages seems to have taken precedence over ability to manage the software within the package.
20:19:51 <nirik> well, not sure what else we are going to decide here today. ;)
20:19:55 <abadger1999> pjones: We've already changed a lot of that -- I can point you to updated stuff after the meeting if you're still interested.
20:20:22 <nirik> do folks want to ponder and come up with proposals and revisit next week?
20:20:48 <kylem> sounds good to me. +1.
20:20:49 <nirik> do we want to agree that we agree with the board vision at least now?
20:21:02 <ajax> i agree with the board vision.
20:21:14 <pjones> abadger1999: sure
20:21:32 <pjones> the board vision will do
20:21:35 <notting> i'm agreeable to agreeing
20:21:39 <SMParrish> I also agree with the vision, just need a good way to implement
20:21:46 * nirik mostly agrees, but the measurement could be difficult/impossible.
20:21:53 <kylem> i agree with the board vision, more discussion needed about implementation.
20:22:02 <mjg59> Ditto with kyle
20:22:31 <nirik> #agreed FESCo agrees with the board vision statement.
20:22:50 <nirik> #agreed will solicit more proposals and revisit/discuss more next week.
20:23:01 <nirik> #topic #351 Create a policy for updates - status report on implementation
20:23:02 <nirik> .fesco
20:23:02 <zodbot> nirik: Error: '' is not a valid integer.
20:23:06 <nirik> oops.
20:23:11 <nirik> .fesco 351
20:23:12 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
20:23:19 <nirik> Do we have any new news on this implementation?
20:23:28 <nirik> notting / abadger1999 / lmacken ?
20:23:35 <Oxf13> nirik: "see above"  ?  (:
20:23:51 * abadger1999 grabs the releng ticket
20:23:52 <nirik> well, this is implementing our approved updates policy.
20:24:23 <nirik>
20:24:26 <abadger1999>
20:24:49 <abadger1999> notting: I listed a couple of options at the end of that -- Do either look like we can move forward with them?
20:24:50 <nirik> cool.
20:25:00 <abadger1999> notting: Or are we stuck with, cannot implement for F13?
20:25:16 <notting> abadger1999: i only did the comps changes for f-14
20:25:30 <abadger1999> notting: Okay -- so what's the issue for enabling this for F13?
20:25:32 <nirik>
20:25:35 <nirik>
20:25:38 <nirik> for bodhi
20:26:05 <notting> abadger1999: which 'this'?
20:26:23 <abadger1999> notting:
20:26:51 <notting> hm, point
20:27:12 <notting> i may have misspoke. we could certainly turn on the auto-updating for f-14
20:27:16 <nirik> anyhow, sounds like things are moving forward.
20:27:20 <notting> i didn't think we landed code for doing it for updates, anyway.
20:27:31 <nirik> continue out of band, and move on with meeting?
20:28:27 <abadger1999> Sure.  I just wasn't sure from nottings last comment on the ticket.
20:29:03 <abadger1999> (wasn't sure if we were moving forward)
20:29:08 <nirik> ah, ok
20:29:55 <nirik> notting: shall we continue and address this out of band?
20:30:02 <notting> sure
20:30:38 <nirik> #topic FES tickets
20:30:44 <nirik>
20:30:54 <nirik> mmcgrath: you around for a update on fedora engineering services tickets?
20:31:01 <mmcgrath> nirik: hey
20:31:15 <mmcgrath> not on specific tickets.  I can say as of Friday F13 has zero broken deps.
20:31:18 <mmcgrath> so that was exciting news.
20:31:21 <nirik> mclasen / SMParrish / kylem: This is a thing we setup a while back to allow fesco to make quick tasks... then get folks to work on those tasks for us.
20:31:32 * mclasen knows about it
20:31:47 <mmcgrath> oh is this the new fesco?
20:31:54 * mmcgrath waves at new fesco
20:32:09 <kylem> nirik, cool.
20:32:11 <kylem> hi. :)
20:32:16 * SMParrish read up on it.
20:32:20 <nirik> mmcgrath: yep.
20:32:21 * nb congratulates new fesco
20:32:24 <mmcgrath> so really most of the ticket movement this last week from me was closing of broken dep tickets.  Generally in good shape there.
20:32:33 <mmcgrath> I did my usual followup
20:32:56 <mmcgrath> some ftbfs updates came through and generally went fine
20:33:05 <mmcgrath> I continue to look at nvr updates, the list is getting smaller at least.
20:33:08 <mmcgrath> that's really about it.
20:33:20 <nirik> ok.
20:33:38 <abadger1999> mmcgrath: What's happening with tickets that don't have anyone interested in doing them (yet)?  Are you planning on assigning someone or letting them accumulate until someone expresses interest?
20:33:41 <nirik> If folks come up with additional small tasks that need doing or ideas on existing ones, please do file new tickets or comment on old ones.
20:33:59 <nb> mmcgrath, fyi both slicehost and linode just released f13 images
20:34:15 * nb just saw ticket # 1
20:34:19 <mmcgrath> abadger1999: I'll have to go back and verify but I think all of the current FES team members have stuff assigned so I'll just wait till they are free or until new people come up.
20:34:25 <mmcgrath> nb: oh excellent.
20:34:58 <nirik> ok, anything else on this?
20:35:08 <abadger1999> mmcgrath: Okay.  Just wondering how you're working that -- I know someone was interested in zsync again on test list.
20:35:17 <abadger1999> and that depends on FES #19.
20:35:53 <mmcgrath> abadger1999: I basically just try to guess what the ticket will involve, look through the FES members list and assign from there.
20:36:02 <abadger1999> <nod>
20:36:12 <mmcgrath> assign is a bit incorrect, i usually ask "take a look at this ticket and let me know if that would work for you" type thing.
20:36:23 <mmcgrath> s/ask/request/ :)
20:36:35 <nirik> mmcgrath: anything else to note?
20:36:41 * mclasen has to head out to the sons soccer practice in 5
20:36:50 <mclasen> did we decide on meeting time ?
20:37:00 <nirik> #topic New Meeting time redux
20:37:02 <mmcgrath> nirik: nope
20:37:05 <nirik>
20:37:09 <pjones> mclasen: we decided to use whenisood to decide
20:37:12 <nirik> I setup a whenisgood link...
20:37:14 <nirik> see above.
20:37:14 <mclasen> cool
20:37:27 <nirik> everyone should fill that out and we can pick a time once all folks have input.
20:37:42 <kylem> great, thanks.
20:38:00 <nirik> is the results
20:38:13 <nirik> #topic Open Floor
20:38:20 <nirik> Anyone have any items for open floor?
20:38:52 <nb> yeah
20:39:02 * mclasen apologizes for leaving early
20:39:22 <notting> nirik: what's the assumed timezone there?
20:39:44 <nb> I had a question I asked nirik yesterday, I just recently sent in a sponsor request and I had saw where before, being made sponsor meant you automatically became provenpackager too.  nirik said he thought that changed but wasn't sure, /me just thought that should be clarified somewhere on the wiki perhaps
20:39:48 <kylem> notting, at the top?
20:39:48 <nirik> notting: if I set it up right, GMT... and it should work for your local timezone if you set it.
20:40:14 <nb> iirc, the reasoning in the past was so you could help with your sponsoree's packages if necessary
20:40:23 * nirik finds that site confusing. If someone has a better one, let me know.
20:41:20 <nirik> nb: yeah, I thought we uncoupled those since they are kinda seperate roles...
20:41:33 <nirik> but you are right that it would help you work with sponsorees pages.
20:41:34 <kylem> i've gotta run and get some dinner before the shops close. sorry. :/
20:42:11 <nirik> nb: perhaps we should add that as a new topic, make sure we decide something and then update the wiki?
20:42:50 <nb> yeah
20:43:18 <nirik> ok, I can do so.
20:43:21 <nirik> anything else?
20:43:25 <abadger1999> Does pwouters being open to helping out with tor change anything? -- he's not a provenpackager otherwise I think he'd fall under "if a provenpackager wants to and CAN fix this - then by all means. "
20:43:37 <abadger1999> .fesco 347
20:43:38 <zodbot> abadger1999: #347 (tor is not compliant with Fedora guidelines) - FESCo - Trac -
20:43:53 <nirik> abadger1999: I note that ensc has updated tor today.
20:44:00 <nirik> he removed the stupid message.
20:44:01 <pjones> abadger1999: if a maintainer of the package happens to fix it, that's fine too...
20:44:08 <abadger1999> Cool.
20:44:16 <nb> nirik, so i should file a separate provenpackager request?
20:44:20 <abadger1999> So it's all moot for now.
20:44:35 <abadger1999> Question for ajax: Any update on libiberty?
20:44:45 <nb> the week for my sponsor request will be up tomorrow
20:45:12 <ajax> abadger1999: yeah, still poking at it.  should have an update for next wek.
20:45:18 <abadger1999> Cool.
20:45:21 <nb> nirik, sorry for bugging you, i'm just confused because the policy appears to have changed? but isn't noted anywhere so it is confusing
20:45:22 <nirik> nb: yes, or better a ticket asking to clarify that they are or are not tied together.
20:45:30 <nb> ok, can do
20:46:14 <nb> nirik, freenode used for scheduling the GAB meeting, and it seemed to be nice
20:46:19 <nirik> I guess we could look at provenpackagers vs sponsors and see if they are all the same currently.
20:47:10 <nirik> ok, anything else, or shall we close this puppy down?
20:48:14 <pjones> end it!
20:48:16 * nirik will close the meeting.
20:48:20 <nirik> thanks for coming everyone.
20:48:27 <nirik> and welcome to new folks!
20:48:30 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : 

More information about the devel mailing list