3:53 p.m.
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 http://wiki.debian.org/MeetBot.
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 -
https://fedorahosted.org/fesco/ticket/385
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:
http://lists.fedoraproject.org/pipermail/devel/2010-June/137032.html
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
https://bugzilla.redhat.com/show_bug.cgi?id=563844#c49
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> http://zim-wiki.org/downloads/
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 -
https://fedorahosted.org/fesco/ticket/382
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 -
https://fedorahosted.org/fesco/ticket/351
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> https://fedoraproject.org/wiki/Stable_release_updates_vision
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> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
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 https://fedoraproject.org/wiki/Package_update_guidelines
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 https://fedorahosted.org/fesco/ticket/351
20:23:02 <zodbot> nirik: Error: 'https://fedorahosted.org/fesco/ticket/351'
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 -
https://fedorahosted.org/fesco/ticket/351
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> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
20:24:26 <abadger1999> https://fedorahosted.org/rel-eng/ticket/3740
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> https://fedorahosted.org/bodhi/ticket/433
20:25:35 <nirik> https://fedorahosted.org/bodhi/ticket/434
20:25:38 <nirik> for bodhi
20:26:05 <notting> abadger1999: which 'this'?
20:26:23 <abadger1999> notting:
https://fedorahosted.org/rel-eng/ticket/3740#comment:7
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> https://fedorahosted.org/fedora-engineering-services/report/6
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> http://whenisgood.net/ee8prq
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> http://whenisgood.net/ee8prq/results/z5binx 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 - https://fedorahosted.org/fesco/ticket/347
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 doodle.com 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