Summary/Minutes from today's FESCo meeting (2010-10-12)

Tue Oct 12 21:05:04 UTC 2010

===================================
#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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101012/23d7f1c4/attachment-0001.bin 