=================================== #fedora-meeting: FESCO (2010-10-12) ===================================
Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-12/fesco.2010-10-12-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:01) * mclasen said he would be about 15min late. (nirik, 19:31:10) * #473 new meeting time (redux) (nirik, 19:34:03) * LINK: https://fedorahosted.org/fesco/ticket/473 (nirik, 19:34:03) * AGREED: new meeting time starting next week: Wed at 19 UTC (nirik, 19:49:45) * ACTION: nirik will check with other meeting thats scheduled then. (nirik, 19:50:11) * LINK: http://fedoraproject.org/wiki/Fedora_meeting_channel (nirik, 19:50:53) * Updates policy / Vision implementation status (nirik, 19:52:28) * #351 Create a policy for updates - status report on implementation (nirik, 19:52:28) * #382 Implementing Stable Release Vision (nirik, 19:52:28) * AGREED: Scratch that last time, will try 18:30UTC next wed. (nirik, 19:59:10) * LINK: http://fedoraproject.org/wiki/Category:Copr (nirik, 20:11:17) * ACTION: cwickert to work on feature updates repo/ideas. (nirik, 20:13:20) * #472 About Mozilla's decision to not allow using the system's libvpx (nirik, 20:14:19) * LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:14:20) * LINK: https://bugzilla.mozilla.org/show_bug.cgi?id=577653#c9 (nirik, 20:17:40) * AGREED: firefox has a exception with libvpx for now. (nirik, 20:35:34) * #302 libssh2 - non-responsive maintainer (nirik, 20:35:48) * LINK: https://fedorahosted.org/fesco/ticket/302 (nirik, 20:35:48) * AGREED: will allow kdudka to commit to libssh2 (nirik, 20:43:49) * #474 Package Criteria 'upgradepath' not clear (nirik, 20:43:55) * LINK: https://fedorahosted.org/fesco/ticket/474 (nirik, 20:43:55) * AGREED: Don't consider updates-testing repo for now. (nirik, 20:57:51) * Open Floor (nirik, 20:58:06) * LINK: https://fedorahosted.org/fesco/ticket/475 (nirik, 20:59:09) Meeting ended at 21:03:31 UTC. Action Items ------------ * nirik will check with other meeting thats scheduled then. * cwickert to work on feature updates repo/ideas. Action Items, by person ----------------------- * cwickert * cwickert to work on feature updates repo/ideas. * nirik * nirik will check with other meeting thats scheduled then. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (154) * cwickert (54) * mjg59 (39) * pjones (32) * ajax (32) * notting (24) * SMParrish (23) * jlaska (18) * spot (17) * mclasen (12) * zodbot (6) * drago01 (3) * cwickert_ (1) * skvidal (1) * kylem (0) -- 19:30:01 <nirik> #startmeeting FESCO (2010-10-12) 19:30:01 <zodbot> Meeting started Tue Oct 12 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 <nirik> #meetingname fesco 19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 <nirik> #topic init process 19:30:01 <zodbot> The meeting name has been set to 'fesco' 19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:09 <mjg59> Afternoon 19:30:41 <nirik> morning. 19:31:10 <nirik> #info mclasen said he would be about 15min late. 19:31:38 * notting is here 19:31:46 * pjones is too 19:32:06 * nirik waits for at least one more to have quorum. 19:32:23 <ajax> I think so, Brain, but why would anyone want to Pierce Brosnan? 19:32:29 * SMParrish here 19:32:45 <nirik> har. 19:32:57 <SMParrish> Sorry I missed last week but wife totaled the car :( 19:33:03 <pjones> SMParrish: ugh :/ 19:33:05 <nirik> yikes. :( She ok? 19:33:06 <pjones> sorry to hear that. 19:33:34 <nirik> I guess we can go ahead and get started then... shall we start with the meeting time discussion? 19:33:40 <SMParrish> Yes she is fine, She rolled the car, so now I have to deal with insurance and got into debt to buy a new one 19:33:56 <nirik> :( no fun. 19:34:03 <nirik> #topic #473 new meeting time (redux) 19:34:03 <nirik> https://fedorahosted.org/fesco/ticket/473 19:34:27 <nirik> I talked with cwickert_ the other day... he said his times are pretty much the same as always... 19:34:39 <nirik> so, we have: http://whenisgood.net/ee8prq/results/z5binx 19:35:16 <nirik> leaving us with our current time that kylem can never make, or switching to another time at least one other person cannot make. 19:36:18 <nirik> thoughts? 19:36:54 <SMParrish> So it sounds like no matter what one person is always going to miss the mtg 19:37:05 <ajax> could alternate weeks 19:37:11 <mjg59> Let's pick a random day and time at the start of every week 19:37:22 <mjg59> Fate will guide us 19:37:26 * cwickert_ is here 19:37:31 <pjones> yeah, because that will encourage more participation. 19:38:25 <nirik> mclasen says he will get more time wed afternoons, but it's unclear to me which 5-6pm he means there? mine/the time the thing is in? 19:38:35 <mjg59> To be honest, it doesn't really seem like mclasen can make this time either 19:38:40 <notting> ajax: i'm ok with that, although that assumes we can keep it straight 19:38:50 <cwickert> for me the time is ok, but Tuesday is the worst day in the week 19:39:08 <SMParrish> If I have a few days notice I can change hours to make sure I am available 19:39:45 <mjg59> In terms of actually having people turn up, I think we'd be better doing this on Wednesday 19:40:51 <nirik> well, wed 1-2 we miss mclasen... I don't know if he could adjust for that though. 19:41:03 <mjg59> Well, right now we miss Kyle and we often miss mclasen 19:41:19 <pjones> yeah 19:41:24 <mjg59> So losing 0.5 of a person in return for gaining one sounds like a win 19:41:32 <pjones> moving to just missing one of them (some,all) of the time is still net gain 19:41:36 <nirik> I'd be ok switching to wed 1-2pm... is the channel open then? 19:42:17 <mjg59> No 19:42:43 <nirik> yeah, looks like EMEA then 19:43:36 <cwickert> mjg59, who is 0.5? 19:43:52 <mjg59> cwickert: mclasen 19:44:16 <cwickert> I have just updated my response and added one more hour each day 19:44:22 <nirik> so wed at 2pm? or do 1-2 and see if we can get EMEA to move and/or move to another channel 19:44:23 <cwickert> this is really getting late for me then 19:44:30 <cwickert> but we still have no match 19:44:43 <mjg59> nirik: I've got no problem with us moving to a -1 channel 19:44:48 <cwickert> nirik, is 2pm UTC? 19:45:06 <nirik> cwickert: it's apparently in my timezone... MDT. 19:45:17 <nirik> UTC+6 19:45:26 <mjg59> nirik: -6 19:45:40 <nirik> yeah, sorry, -6 19:46:00 <mjg59> cwickert: 1PM on would be 30 minutes earlier than current, on Wednesday rather than Tuesday 19:46:06 <nirik> I kinda hate to go to a subchannel as here it's much easier to drag someone in or ping them or have them notice when we talk about them. ;) 19:46:22 <cwickert> mjg59, fine with me 19:46:34 <pjones> that's fine with me as well (as I marked on whenisgood) 19:46:34 <nirik> we could also try noon on thursday, if SMParrish could get that hour available. 19:46:38 <nirik> friday sorry. 19:46:40 <cwickert> and wednesday is better than tuesday 19:47:40 <SMParrish> nirik: Thursday would be np 19:48:02 <SMParrish> nirik: Ooops Friday I mean 19:48:23 <nirik> so, we have: a) wed at 19:UTC, or b) friday at 18UTC 19:48:45 <pjones> all in favor, say "yawn" ;) 19:48:53 * cwickert prefers wednesday 19:49:01 <mjg59> Either works equally well for me 19:49:03 <notting> either works for me 19:49:13 <nirik> either works for me too. 19:49:15 <pjones> Either works for me, though I prefer to keep fridays meeting-free. 19:49:19 <ajax> wednesday preferable, yeah 19:49:25 <cwickert> +1 pjones 19:49:27 <nirik> ok, so sounds like wed is the winner. ;) 19:49:28 * SMParrish preferes Wednesday 19:49:35 <cwickert> hooray 19:49:45 <nirik> #agreed new meeting time starting next week: Wed at 19 UTC 19:49:58 <nirik> I'll try talking to ENMA and see if we can figure out if we need a new channel or whatever. 19:50:11 <nirik> #action nirik will check with other meeting thats scheduled then. 19:50:16 <cwickert> ouch 19:50:26 <cwickert> you mean emea ambassados meeting? 19:50:42 <nirik> yeah. 19:50:48 <nirik> it's listed as then in this channel. 19:50:49 <cwickert> then I will have a hard time follwing two meetings at the same time :( 19:50:53 <nirik> http://fedoraproject.org/wiki/Fedora_meeting_channel 19:51:07 <nirik> I don't know if they still do meet then... the wiki page is often not updated. 19:51:36 <cwickert> they do, but only every second week 19:51:50 <SMParrish> git --help 19:51:53 <SMParrish> miss 19:52:01 <nirik> ok, I can see if they can change or we can use meeting-1 or something. 19:52:15 <nirik> cwickert: do you know who I should ask ? who runs those meetings? 19:52:20 <nirik> anyhow, lets move on 19:52:21 <cwickert> liknus 19:52:28 <nirik> #topic Updates policy / Vision implementation status 19:52:28 <nirik> .fesco 351 19:52:28 <nirik> .fesco 382 19:52:28 <nirik> #topic #351 Create a policy for updates - status report on implementation 19:52:28 <nirik> #topic #382 Implementing Stable Release Vision 19:52:30 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:52:33 <nirik> ok, the updaates topic. ;) 19:52:34 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:52:53 <nirik> we still need to work on stats. Any news on that SMParrish ? 19:53:10 <nirik> mclasen: welcome. 19:53:13 <cwickert> hi mclasen 19:53:24 * mclasen apologizes for being late all the time 19:53:30 <nirik> mclasen: we are going to try and switch to wed at 19UTC... is there any way you could be available then? 19:53:32 <SMParrish> nirik: No with the RL issues did not get to it, will have it ready by next week 19:53:50 <nirik> SMParrish: ok, great. 19:53:52 <mclasen> err, utc...what is that in boston ? 19:54:10 <nirik> 3pm I think? 19:54:22 <ajax> mclasen: -4 hours in daylight savings, -5 otherwise. 19:54:33 <mjg59> 3PM, yes 19:54:33 <mclasen> I'll usually be picking up kids at 3:30 and at 5 19:55:00 <mclasen> so 3-5 is kinda pessimal for continuous online presence for me 19:55:06 <SMParrish> fedpkg build 19:55:26 <SMParrish> bah too many windows open :) 19:55:42 <nirik> mclasen: ;( 19:56:01 <nirik> could folks do 18:30? that would give us an hour of mclasen... 19:56:23 <SMParrish> I can 19:56:33 <ajax> i'm nearly infinitely flexible. 19:56:48 <mjg59> kyle is the only person who potentially can't, but he's not here 19:56:49 <cwickert> I can make it if I hurry 19:57:38 * nirik sighs. ok, how about we try 18:30 wed next week 19:57:44 <notting> that's 18:30 UTC? 19:57:49 <nirik> yeah. 19:57:54 <mjg59> Yes, 14:30 eastern 19:57:54 <nirik> 2:30 19:58:01 <pjones> okay. 19:58:08 <ajax> sure. 19:58:52 * mclasen apologizes in advance for not making it next week (in Spain all week) 19:59:06 * notting will also be out next week 19:59:10 <nirik> #agreed Scratch that last time, will try 18:30UTC next wed. 19:59:13 <nirik> ok. 19:59:20 <nirik> so, back to updates. ;) 19:59:43 <cwickert> I have a question 19:59:48 <nirik> We still have no enforcement setup... We also have several packages looking to update that have opened discussion on the mailing list. 20:00:04 <nirik> banshee and publican were talked about. 20:00:08 <nirik> cwickert: go ahead. 20:00:17 <cwickert> the updates policy is already in place, but we have no alternative update channels yet like updates-features" 20:00:36 <nirik> correct. 20:01:17 <nirik> kylem was going to work on a proposal for that, but hasn't been able to. 20:01:23 <cwickert> IMHO we first need to care about the implementation before we can enforce the policy 20:01:25 <nirik> would someone(s) else like to work on that? 20:02:00 <cwickert> I can do it 20:02:50 <nirik> so, basically what I would like to see is a proposal/outline that describes any such other channel, how it would work with our SCM/buildsystem/updates system and what could be allowed to be in it... 20:03:21 <cwickert> where is the wikipage with the current suggestions? 20:03:51 <nirik> I don't know that we have one. 20:03:54 <cwickert> found it: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas 20:03:57 <nirik> It was a suggestion there... 20:04:02 <nirik> but just in general terms. 20:05:10 <cwickert> well, some suggestions from that page no longer apply 20:05:18 <cwickert> as we already ratified the policy 20:05:31 <cwickert> basically it comes down to an addtional repo now, right? 20:06:16 <nirik> right. But lots of questions around that would need to get answered. 20:06:41 <cwickert> such as? 20:08:19 <nirik> are they seperate SCM branches or how do the fit in git? Does the tag inherit from anything? I assume base stable repo. Do maintainers need buildroot overrides for it? Does bodhi need work to be able to manage another set of updates streams? Can anything be built for it? Would this work for KDE folks for their releases? but wouldn't that leave stable with security issues / more bugs? 20:09:31 <nirik> How would bugs be reported? against the same product/release? or do we need bugzilla 'feature' components? 20:10:06 <notting> that's an impressive list of questions 20:10:11 <cwickert> indeed 20:10:19 <nirik> sorry, just brainstorming them. ;) 20:10:29 <cwickert> thanks for your question 20:10:30 <nirik> instead of another repo, could copr's work for this? 20:10:37 <nirik> (I don't know what state they are in) 20:10:42 <cwickert> copr? 20:11:17 <nirik> http://fedoraproject.org/wiki/Category:Copr 20:11:28 <nirik> basically something like PPA's in other distros for fedora 20:11:48 <cwickert> ah, I remember, I just didn't know the term 20:12:18 <nirik> anyhow, I'd say lets gather info and try and see what we can do. It would be nice to have an easy feature setup... 20:12:25 <nirik> we do also have repos.fedorapeople.org 20:12:45 <nirik> any other questions or comments on updates? 20:12:59 <cwickert> I wil ask for more questions on the mailing list and try to come up with a proposal that covers them all (hopefully) 20:13:20 <nirik> #action cwickert to work on feature updates repo/ideas. 20:13:22 <nirik> thanks. 20:13:25 <cwickert> welcome 20:13:56 <nirik> ok, will move on then if nothing else right now on updates? 20:14:19 <nirik> #topic #472 About Mozilla's decision to not allow using the system's libvpx 20:14:20 <nirik> https://fedorahosted.org/fesco/ticket/472 20:14:37 <nirik> I guess blizzard couldn't make it. 20:14:49 <nirik> spot: you around? anything to add to this fine ticket? 20:15:19 * nirik notes no one but him voted on the ticket. 20:15:27 <notting> crap, forgot to 20:15:39 <mjg59> I was +1 to both 20:15:42 * mclasen wonders if his question has been discussed last week 20:15:43 * notting is -1, +1 20:15:51 <notting> mclasen: my concern is that it's modified 20:16:09 <mclasen> well, if we patch the 'system' libvpx, its modified too... 20:16:14 <pjones> mclasen: it was, but we didn't really have enough people to come to a decision. 20:16:15 <nirik> it has 1 patch... 20:16:26 <nirik> basically to stop it requiring static libs be produced. 20:16:50 <nirik> I've exchanged some emails with blizzard and invited him here. 20:17:03 <nirik> upstream also seems like they might be willing to unbundle. 20:17:40 <nirik> https://bugzilla.mozilla.org/show_bug.cgi?id=577653#c9 20:18:45 <nirik> anyhow, it was discussed last week... do we just want to vote? or ? 20:18:51 <SMParrish> I am -1/+1 but would want to try and get them back on the system libs b4 f15 final 20:19:03 <spot> nirik: honestly? 20:19:09 <spot> nirik: you dont want to hear what i think 20:19:15 <nirik> I can guess. ;) 20:19:18 <spot> and since i'm not on fesco, i don't get a vote. 20:20:39 * cwickert would like to hear spot's opinion 20:20:44 * nirik gets more and more uneasy giving them more rope. After a point it's not worth it for the trademarks... but given this is rawhide only and they seem to be moving to unbundle I'd be ok with letting them for now until f15. 20:20:49 <spot> Okay, then. Here it is. 20:21:01 <spot> I'm tired of Mozilla jerking us around, using the trademark as a club. 20:21:18 <spot> There is no reason not to permit users/distributions to use their copy of libvpx. 20:21:20 <cwickert> so am i 20:21:32 <spot> No technical reason, no functional reason, not even a performance reason. 20:22:01 <spot> Their code runs through the same compiler as everyone else, yet every time we hit an issue like this, it gets treated like a ming vase. 20:22:08 <spot> Too valuable and fragile to risk it. 20:22:18 <spot> Get. Over. It. 20:22:27 <spot> and if they won't, then we should get past the trademark. 20:22:36 <spot> EOF 20:22:37 <notting> i agree and disagree 20:22:44 <mjg59> I don't see any significant technical benefit to us using system libraries over using their bundled libraries 20:22:49 <cwickert> well said spot 20:22:49 <pjones> that's not without merit, though it is a little reactionary 20:22:55 <notting> note that, in fact, the ff maintainer was against unbundling regardless of the trademark 20:23:02 <nirik> yeah, same here. I don't think I am to that point yet, but if they keep doing this I would be. ;) 20:23:02 <mjg59> Given that Mozilla's security track record is sufficiently bad that we have to keep rebuilding it anyway 20:23:27 <mjg59> Given that, I see no benefit to us in losing the trademark. I do see harm in it. 20:23:41 <ajax> and that we spend far more time talking about the horrors of bundling than it would take to just build all N copies. 20:24:02 <spot> ajax: my concern is that this is a growing trend with them 20:24:02 <nirik> mjg59: how about them commiting a local fix that we could be applying to our system version and leaving gstreamer vulnerable to some issue? 20:24:19 <spot> ajax: and everytime we permit "just one more", we end up with chromium level ick. 20:24:31 <pjones> spot: hrm. to me it seemed the other way - it used to be a bigger problem, and it's getting better. 20:24:34 <mjg59> spot: That's why I think we should just grant Mozilla a broad exemption 20:24:39 <spot> pjones: they haven't unbundled _anything_ 20:24:51 <spot> they dangle out that they might do one soon, but they havent 20:24:52 <spot> ever. 20:25:04 <mjg59> spot: I'm tired of talking about this, but I don't see any interesting people (other than you) arguing for the "Drop the trademark" solution 20:25:07 <notting> spot: they unbundled nspr and nss 20:25:09 * mclasen has the heretic thought that having everybody just run the mozilla build would not be the end of the world 20:25:09 <pjones> they've added more stuff to the list that can use system libs, haven't they? 20:25:42 <pjones> mclasen: well, their build isn't as nice as rebuilding it, but... yeah. 20:26:07 <ajax> and they think they have to continue to produce binaries for winxp, so they really do need a copy of zlib and cairo in the source 20:26:19 <cwickert> mjg59, I do see them, they have already written that on fedora-devel 20:26:21 <SMParrish> I am willing to let them bundle since its just f15 and its still in development, but like I mentioned earlier I want them back on the system libvpx at f15 release. Dont want to keep giving them an exception for every release 20:26:41 <mjg59> SMParrish: Why draw the line at libvpx? 20:26:50 <mjg59> If we object to their bundling then we should do so period 20:26:52 <notting> cwickert: i think you and mjg59 might be disagreeing as to who counts as 'interesting' 20:27:28 <mjg59> cwickert: The people I've seen doing so on f-d-l are either people who don't appear to make any great contribution to the project, or are arguing in favour of patches that would need rebasing for every release and have seen no serious push for upstreaming 20:27:39 <mjg59> cwickert: The latter group wouldn't get their patches merged *anyway* 20:27:54 <mjg59> So unbranding doesn't benefit them 20:28:10 <SMParrish> mjg59: I dont draw the line there, in fact I think they should adhere to the policy in total. 20:28:27 <mjg59> SMParrish: Ok. It's absolutely clear that Firefox will have bundled libraries by F15. 20:28:40 <mjg59> Even if libvpx is unbundled. 20:28:44 * nirik nods. 20:29:00 <SMParrish> I am willing to give them some time, but not alot to either comply or get booted 20:29:06 <mjg59> If we're unhappy with that then we should say so now in order to get the change through as early as possible 20:29:16 <cwickert> mjg59, speaking of upstreaming patches. do we know how much mozilla has invested to push their libvpx patch upstream? 20:29:25 <mjg59> Because it's going to be disruptive and should happen right at the start of a rawhide cycle 20:29:25 <nirik> cwickert: we don't even know if they have any. 20:29:47 <cwickert> so, this is less than the fedora contributors are willing to do 20:30:03 <cwickert> even if they are not 'interesting' contributors ;) 20:30:23 <mclasen> cwickert: going from 'don't know' to 'less than' is a bit of a leap 20:30:38 * nirik would be happier about dropping the trademark if we already had a iceweasel package/group of maintainers. We don't even know if the current firefox folks will be willing to maintain such a thing. 20:31:07 <nirik> ok, we are over 15min here. Votes to keep going? 20:31:10 <notting> i think having both ff and iceweasel is profoundly stupid. 20:31:28 <notting> (that's 'in the distro at the same time') 20:31:47 <pjones> yeah, I'm definitely -1 to having _both_ of them. 20:31:48 <nirik> notting: sure, I'm just saying if we tell firefox to go away, we should have something ready to replace it... 20:31:58 <drago01> do we have any "don't ship any fork of an existing package" ? 20:32:02 <drago01> rule 20:32:04 <nirik> drago01: no 20:32:34 <drago01> (does not change that it _is_ stupid though) 20:32:47 <notting> nirik: disregarding bloviating about trademarks, what's the current vote on the actual proposal? 20:33:02 <nirik> so, no votes to continue discussion, folks want to vote on the proposals in ticket? 20:33:08 <nirik> notting: good question. 20:33:24 * nirik was -1 / +0.5 20:33:38 <mjg59> Well, we've got enough people here to take the vote 20:33:40 <mjg59> So +1/+1 20:33:50 <mjg59> (broad exception/libvpx exception) 20:34:08 <notting> -1, +1 20:34:21 <pjones> I'm also -1, +1 20:34:38 <SMParrish> -1/+1 20:34:43 * nirik notes we never really gave them an exception for all the other junk... it's just not been asked. 20:34:45 <ajax> 0/+1. i like the blanket exception idea but i think the proposal as worded is unclear. 20:34:59 <pjones> ajax: fair. with better wording I might not be -1 on it. 20:35:03 <mclasen> -1/+1 20:35:14 <ajax> that's +6.5 to vpx exception 20:35:15 <mjg59> Well, I think that's our answer for now 20:35:15 <ajax> hooray 20:35:16 <notting> that reads as the libvpx exception is approved, and we can move on? 20:35:20 <mjg59> Yes 20:35:21 <pjones> yep 20:35:34 <nirik> #agreed firefox has a exception with libvpx for now. 20:35:44 <SMParrish> I have a hard stop in 10mins have to pickup the wife 20:35:48 <nirik> #topic #302 libssh2 - non-responsive maintainer 20:35:48 <nirik> https://fedorahosted.org/fesco/ticket/302 20:35:57 <nirik> so, this is a re-opened ticket from a while back. 20:36:07 * mclasen has to go in 10 too 20:36:18 <nirik> we have this and 1 more item pending... 20:37:08 <nirik> so, our options here are: 20:37:21 <nirik> a) just let the epel co-maintainer try and fix the bugs and go on. 20:37:48 <nirik> b) add kdudka to commit to the package and fix the bugs even tho the primary maintainer doesn't like working with them. 20:37:53 <ajax> interestingly: https://admin.fedoraproject.org/pkgdb/acls/name/libssh2 20:38:07 <ajax> where kdudka is marked as having asked for commit and been denied 20:38:22 <nirik> yes, that is from the former time this ticket was opened. 20:38:30 <nirik> cweyl didn't like working with them. 20:38:53 <pjones> can we maybe try to find somebody more active that cweyl does like working with? 20:38:59 <SMParrish> nirik: What was the issue, quality of work or just a personal issue? 20:39:01 <nirik> sure, any ideas? 20:39:03 <pjones> who can act as a comaintainer? 20:39:34 <pjones> whoowns openssl? 20:39:34 <pjones> ;) 20:39:48 <nirik> he said to me "He has always rubbed me the wrong way" but didn't get specific. 20:40:08 <notting> pjones: well, there's the epel maintainer 20:40:14 <pjones> fair enough 20:40:17 <ajax> notting: who already has commit access 20:40:33 <nirik> but is also busy 20:40:36 <ajax> i feel more and more like i'm arbitrating schoolyard fights 20:40:46 <nirik> yeah. 20:40:47 <ajax> people need to harden up 20:41:14 <pjones> no kidding. 20:41:53 <pjones> well, if the epel maintainer is basically the comaintainer, and *he* says he doesn't have a problem with kdudka getting access... 20:41:57 <ajax> on that basis, and also because i think collective responsibility is the only sane thing, +1 to giving kdudka commit access 20:42:01 <nirik> I'd be ok doing either of the above. 20:42:06 <pjones> then, well, cweyl can come up with something a bit more specific if there's a real problem with it. 20:42:26 <pjones> yeah, I'm +1 to giving him commit access at this point. 20:42:29 <ajax> if there's a real quality-of-work issue then i'll be happy to hear it 20:42:47 <nirik> no objection here... +1 to doing that. 20:42:50 <SMParrish> IMO until such time as cweyl can give us a legitimate reason why kdudka should not have commit access I saw we give it to him 20:43:14 <nirik> any other votes? that reads as +4... 20:43:18 <cwickert> +1 20:43:26 <notting> i'd also be much more comfortable with denying kdudka access if cweyl was actually around to maintain 20:43:30 * notting is +1, i guess 20:43:49 <nirik> #agreed will allow kdudka to commit to libssh2 20:43:55 <nirik> #topic #474 Package Criteria 'upgradepath' not clear 20:43:55 <nirik> https://fedorahosted.org/fesco/ticket/474 20:44:16 * mclasen goes away for a while 20:44:18 <nirik> jlaska: you around? 20:44:39 <jlaska> nirik: not for much longer, but I can talk briefly about this 20:45:04 <jlaska> shall I proceed? 20:45:10 <jlaska> s/shall/should/ meh :) 20:45:14 <cwickert> go ahead pls 20:45:22 <nirik> please do 20:45:30 <jlaska> so ... Kamil does a great job outlining the problem space on the autoqa-devel@ list (see https://fedorahosted.org/pipermail/autoqa-devel/2010-September/001189.html) 20:45:33 <SMParrish> I have to run but will read logs and comment in ticket. 20:45:49 <jlaska> we are trying to decide what our 'upgradepath' test should be checking 20:46:05 <jlaska> it's pretty well understood how to handle this when it comes to the 'updates' repo 20:46:32 <jlaska> but we've encountered some wrinkles when it comes to how to upgradepath and 'updates-testing' 20:46:53 <ajax> i think 14-updates-testing -> 15-* isn't a case we're necessarily encouraging? 20:46:58 <ajax> in fact, almost certainly not. 20:47:07 <jlaska> so we could use some direction on this 20:47:24 <jlaska> we don't want to code up some policy in this test that doesn't match reality 20:47:35 <nirik> I would hope that people with updates-testing enabled would be able to fix any upgrade path issues they might run into... 20:48:48 <jlaska> I don't imagine we'll drill into the details in the meeting herre 20:48:49 <jlaska> here 20:49:11 <cwickert> the problem i see is that nextrelease is frozen and therefor updates are processed slower as in currentrelease. thus update-testing in current-release might very well contain newer versions 20:49:28 <ajax> i'm comfortable with "updates-testing isn't part of the upgrade path, so don't do upgrade testing on it" 20:50:00 <ajax> so that's slightly more strict than 1a, actually 20:50:12 <nirik> yeah, thats basically just 'don't test this case' right? 20:50:26 <ajax> and then for problem 2, disablerepo testing, yum reinstall any packages that you have from a testing repo 20:50:39 <ajax> and i think that even takes out problem 3 as well. 20:51:05 <nirik> a 'yum distro-sync' would help there. 20:51:24 <skvidal> (well and still disable testing repo, I think) 20:51:28 <nirik> yeah. 20:51:44 <jlaska> as maintainers, would you want to have automated upgradepath feedback on your proposed 'updates-testing' packages. This would be informative result, not a mandatory result obviously 20:52:13 <jlaska> or should we ignore that for now, and focus on just having the test respond to and reporting upgradepath issues for 'stable' + 'updates' 20:52:15 <nirik> jlaska: so there would be a mandatory one run when it promotes to updates? 20:52:21 <jlaska> nirik: yes 20:52:40 <nirik> so the drawback there is that you might not know until it's already had a bunch of testing, etc. 20:52:53 <ajax> sure, but by that point you can probably push it to rawhide too.. 20:52:58 <jlaska> (eventually mandatory ... there's going to be a burn-in period where we're all tests are informative --- as we test the process+workflow) 20:53:32 <nirik> I guess my thought would be to at least say 'don't bother with updates-testing' right now... we could revisit later. 20:53:56 <jlaska> definitely a valid option 20:54:26 <ajax> yeah. we can think about it more but i'm leaning towards not thinking of u-t as upgrade path 20:54:28 <notting> that would work for me for now 20:54:28 <cwickert> +1, i think we should not think about updates-testing at all. people who are testing updates should be aware of the problems this might cause during an upgrade 20:54:33 <mjg59> Right 20:54:34 <jlaska> do we want to vote here, or revisit and close this out next week? 20:54:48 * cwickert liks to vote 20:55:09 <ajax> clearly 20:55:28 <nirik> well, do we still have quorum? I guess so. 20:55:47 <nirik> I'm +1 to don't consider updates-testing for now. revisit down the road. 20:56:23 <nirik> mjg59: ajax ? you guys want to think on it some more and revist next week? 20:56:33 <ajax> i heard five: notting, mjg59, nirik, cwickert, ajax 20:56:49 <ajax> was confused by cwickert not having +v 20:56:58 <mjg59> Yeah, I'm +1 on that 20:56:59 <pjones> I'm +1 here 20:57:11 <cwickert> +1 to not consider updates-testing and not bring this topic up again for now 20:57:26 <cwickert> s/now/next week 20:57:34 <nirik> ok, sounds like thats a pass. 20:57:40 <ajax> woooo 20:57:51 <nirik> #agreed Don't consider updates-testing repo for now. 20:58:00 <nirik> thanks jlaska 20:58:06 <nirik> #topic Open Floor 20:58:08 <jlaska> thanks all! 20:58:11 <nirik> anyone have anything for open floor? 20:58:16 <cwickert> thanks jlaska 20:58:40 <notting> did we want to consider the kde thing? should be quick. 20:58:57 <ajax> there's a thing? 20:58:58 <nirik> we could, it landed after I sent the agenda out... 20:59:09 <nirik> https://fedorahosted.org/fesco/ticket/475 20:59:21 <nirik> would folks like to discuss it now? or wait a week? 20:59:41 <mjg59> Given that we've lost a couple, maybe better to leave it 20:59:44 <nirik> note that this could tie in with any feature repo ideas. 20:59:51 <pjones> mjg59: yeah. 20:59:57 <ajax> what he said 21:00:09 <pjones> also I think we should take a harder line about things coming in after the agenda is posted in general ;) 21:00:18 <nirik> thats fine. 21:00:24 <notting> ok 21:00:31 <nirik> if no one has anything further, will close out the meeting... 21:00:47 <cwickert> wait 21:01:13 <cwickert> ok, we leave the kde thing 21:01:28 <cwickert> but why not discuss it now? we still have a quorum 21:02:15 <pjones> because some of us like to actually prepare and think about things before discussing them. 21:02:54 <cwickert> pjones, i doubt there is much to prepare on this one 21:03:07 <cwickert> anyway, lets close 21:03:24 <nirik> ok, thanks for coming everyone! 21:03:31 <nirik> #endmeeting
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
