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
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
