[gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20130312.txt

[gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20130312.txt

[Ulrich Mueller (ulm)]

ulm         13/03/12 21:14:45

  Added:                20130312.txt
  Log:
  Log for 20130312 meeting.

Revision  Changes    Path
1.1                  xml/htdocs/proj/en/council/meeting-logs/20130312.txt

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20130312.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20130312.txt?rev=1.1&content-type=text/plain

Index: 20130312.txt
===================================================================
<ulm> hi all							        [21:00]
<dberkholz|mob> Hi
<ulm> agenda of the meeting is here:
      http://dev.gentoo.org/~ulm/council-20130312-agenda.txt
<ulm> so, roll call						        [21:01]
<grobian> here
<WilliamH> here
<ulm> betelgeuse, chainsaw, scarabeus?				        [21:02]
<ulm> *sigh* it shouldn't become a habit that we must call several council
      members by phone for every meeting			        [21:04]
<Zero_Chaos> *cough* slacker marks *cough*			        [21:05]
<Zero_Chaos> actually to be fair, the time change in the US may have messed
	     some people up
<WilliamH> Zero_Chaos: if they do get here they don't get slacker marks. ;-)
<Betelgeuse> hello everyone
<dberkholz|mob> None of those are American			        [21:06]
<Betelgeuse> I am in US though
<WilliamH> Zero_Chaos: That happens if you don't attend or your proxy doesn't
	   attend a meeting.
<Zero_Chaos> WilliamH: I'm familiar, it was a jest
<WilliamH> But, yes, I agree.
<ulm> o.k., I've texted chainsaw and scarabeus, too
*** Chainsaw (~chainsaw@gentoo/developer/chainsaw) has joined channel
    #gentoo-council
*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +o
    Chainsaw
<ulm> welcome :)						        [21:07]
<Chainsaw> Thank you ulm.
<Betelgeuse> ulm: thanks!					        [21:08]
<ulm> let's wait until 20:10 for scarabeus
<ulm> I expect the meeting to be short
<ulm> online summary: http://dev.gentoo.org/~ulm/council-20130312-summary.txt
								        [21:09]
<ulm> let's start then						        [21:10]
<ulm> Open bugs with council involvement
<ulm> Bug 457000 "Missing log and summary for 20090122 and 20090625 council
      meetings"
<ulm> I've found and uploaded logs for both			        [21:11]
<grobian> ok
<ulm> anyone wants to comment on the accuracy of these logs?
<grobian> robbat2 acked them, right?				        [21:12]
<ulm> I've double checked them with the willikins logs
<grobian> I'm fine with them
<ulm> the question is what we should do about the summaries	        [21:13]
<Betelgeuse> Sounds good. If someone disputes I have logs too.
*** AndChat-9081 (~dberkholz@gentoo/developer/dberkholz) has joined channel
    #gentoo-council
*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +v
    AndChat-9081
<ulm> should we still add them, as far as they're available?
<Betelgeuse> Summaries have previously been drafted long after the fact too.
* grobian points at http://dev.gentoo.org/~grobian/agenda-20130212.txt  [21:14]
<ulm> for the 20090625 meeting, there's a summary at
      http://archives.gentoo.org/gentoo-council/msg_6523793dd018ea42b4d28e97f8d1b731.xml
<ulm> which we could approve
<Betelgeuse> ok for me						        [21:15]
*** AndChat-9081 (~dberkholz@gentoo/developer/dberkholz) has quit: Client Quit
<Betelgeuse> There are no texts for which exact words would matter
<ulm> yeah, so shall we just vote on it?
*** dberkholz|mob (~dberkholz@gentoo/developer/dberkholz) has quit: Ping
    timeout: 252 seconds					        [21:16]
<grobian> ok for me too
<WilliamH> ok for me too
<ulm> also ok for me						        [21:17]
<ulm> we're in perfect position to approve these old meetings
<Chainsaw> Approved.
* ulm has looked it up in Robert's Rules of Order
<ssuominen> dberkholz dropped? his other client is 2hrs idle
<ulm> s/meetings/minutes/
<dberkholz> ssuominen: i'm here.				        [21:18]
<dberkholz> the AndChat* was me					        [21:19]
<ssuominen> k
<ulm> dberkholz: we're voting on approval of the 20090625 meeting summary
<dberkholz> i'm just terribly apathetic about this
<dberkholz> sure, add it, not sure why we even care enough to vote on
	    something that stale at this point
* Zero_Chaos hands dberkholz some red tape			        [21:20]
<ulm> dberkholz: you have a point, let's simply finishh this topic quickly
<ulm> anyway, I count 5 yes votes, so it's approved		        [21:21]
<ulm> dberkholz: should I count you as abstention?
<dberkholz> fine with me					        [21:22]
<dberkholz> since i didn't actually read the whole log to verify it's an
	    accurate summary of the meeting
<ulm> for 20090122 there's no complete summary			        [21:23]
<ulm> I suggest that we just leave it open
<ulm> unless someone would volunteer to write one ;)		        [21:24]
<Betelgeuse> Since I was present I could also look into writing one
<ulm> Betelgeuse: thanks
<ulm> there are some notes from donnie already:
      http://dev.gentoo.org/~dberkholz/20090122_summary.txt	        [21:25]
<ulm> so let's postpone it till next meeting
<ulm> move on?
<Betelgeuse> yes
<ulm> Bug 447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19} fails
      to build with kernel {3.7,3.8}"
<grobian> interesting bug
<ulm> meanwhile, it's been closed as wontfix
<ulm> and council removed from cc				        [21:26]
<WilliamH> It sounds to me like those kernel versions were released after the
	   nvidia drivers.
<Zero_Chaos> I still respectfully request discussion of this matter
<Zero_Chaos> WilliamH: they were
<Zero_Chaos> That bug is long, and tedieous, but the pain from the users is
	     very very obvious
<WilliamH> Zero_Chaos: comment #70 sums it up pretty well then since this is a
	   closed source driver.				        [21:27]
<ssuominen> I'd like to point out back in 2011 we were in same situation,
	    vapier patched it and there were no issues
<ssuominen> Then 2012 I patched it in same situation and talked with Cardoe
	    and I patched it
<ssuominen> Now in 2013 we are in same situation, and we no longer can patch
	    nvidia-drivers trivially? What changed? Nothing.
<Chainsaw> Main concern I have with the council CC is that we are supposed to
	   be the appeals process for devrel.
<Chainsaw> Has devrel been involved?				        [21:28]
<dberkholz> is this an HR issue?
<Zero_Chaos> It would seem to me that if we are going to mark a package as
	     stable, we should at least attempt to keep things buildable.  The
	     current maintainer feels that if it's not buildable it's nvidia's
	     problem and he refused to accept (in my opinion) trivial patches
<Zero_Chaos> Chainsaw: with respect, I'm looking for a guideline not a
	     moderation session or for the council to order anyone to do
	     anything.
<dberkholz> my understanding is that we were copied for a technical issue
<ssuominen> Cardoe mailed me about nvidia-drivers, I reminded him of our
	    discussion from 2012, and I never got reply after that, no devrel
	    far as I know
<dberkholz> so devrel would not be pertinent
<Chainsaw> It still seems to be a condemnation of rej's maintainership of the
	   package.						        [21:29]
<ulm> right, I see it as a technical issue too
<WilliamH> nvidia doesn't support that version of the driver with the newer
	   kernels.
<dberkholz> in actuality it should be going to whoever the X lead is
<ssuominen> The patches that went in this time for nvidia-drivers were only
	    related to the build
<Chainsaw> If rej is unwilling to budge, and it is felt that this is unjust,
	   devrel is where you should go. Not the council.
*** Arfrever (~Arfrever@apache/committer/Arfrever) has joined channel
    #gentoo-council
<ssuominen> No code changes
<Zero_Chaos> I would like for the council to provide their guidance on the
	     fact that if it is marked stable, we should make reasonable
	     effort to make it buildable. If we are not going to make any
	     effort to keep something buildable, it shouldn't be marked
	     stable.
* dberkholz coughs
<dberkholz> http://www.gentoo.org/proj/en/desktop/x/
<ssuominen> kernel stabilization have lately been a bit off, it's not only
	    nvidia-drivers that weren't ready, also udev got broken with
	    path-by-id ATA symlinks				        [21:30]
<WilliamH> Zero_Chaos: it is buildable with the version of the kernel it is
	   supposed to be buildable with.
<WilliamH> kernel stabilizations should not be affected by external drivers.
								        [21:31]
<Zero_Chaos> WilliamH: yes, but that means that stable users aren't buildable
	     right now and that rather defeats the point of having stable at
	     all in my eyes.
<Betelgeuse> As a general point I agree that other bodies are more suited to
	     handle technical issues than devrel.
<ulm> scarabeus just texted back
<ulm> he forgot and he's giving a talk about gentoo		        [21:32]
<ssuominen> WilliamH: we used to block kernel stabilizations with the
	    nvidia-drivers stablereq, not this time, but I still agree, it
	    shouldn't be a blocker but like Zero_Chaos pointed out, reasonable
	    effort should be made
<Zero_Chaos> I'm completely fine with nvidia-drivers NOT blocking kernel
	     stablization.					        [21:33]
<WilliamH> ssuominen: The problem is that we could get our users into an
	   unsupported situation.
<Zero_Chaos> WilliamH: a "vanilla" use flag was introduced to avoid that
<Zero_Chaos> WilliamH: it was refused by the maintainer. he is happy to have a
	     stable ebuild that doesn't work on stable systems
<Betelgeuse> devrel was cced to the bug at one point as you can see in
	     https://bugs.gentoo.org/show_activity.cgi?id=447566        [21:34]
<Zero_Chaos> that is the part I find unacceptable. things that can't build on
	     stable shouldn't be marked stable
<Betelgeuse> search for hwoarang or devrel
<ssuominen> WilliamH: nothing unsupported by adding missing -I flag when
	    kernel moves a header and the header stays same, and nothing
	    unsupported about fixing trivial script to parse the kernel
	    version correctly
<grobian> so this pretty much sounds like maintainer isn't reasonably
	  cooperating
<dberkholz> what's unsupported is whether upstream will laugh in your face if
	    you encounter a bug
<ssuominen> WilliamH: in fact, it's propably why nvidia took it's time this
	    time to release new drivers, the solutions were all around in
	    their forums
<Zero_Chaos> dberkholz: again, a USE=vanilla solution was offered to
	     accomodate that situation				        [21:35]
<ulm> to get this back on track: are we at the point where we should decide on
      the issue?
<WilliamH> ssuominen: ok, so the solutions were known to nvidia then.   [21:36]
<ulm> or should projects try to resolve it first?
<dberkholz> Zero_Chaos: that will be immensely confusing to users in the case
	    where they can upgrade a kernel, attempt to go vanilla, and it
	    doesn't build.
<Chainsaw> ulm: Developer, herd/project, devrel, council.
<Zero_Chaos> dberkholz: it was properly explained in the ebuild based on if
	     the use flag was set and the current kernel versions, etc. it was
	     actually quite nice
<ulm> Chainsaw: yes, that's the usual way			        [21:37]
<ssuominen> dberkholz: vanilla causing build failures is a resolved, invalid,
	    it's what the user asked and the normal policy of
	    toolchain/base-system
<Zero_Chaos> Chainsaw: imho this isn't a relations issue, this is a technical
	     issue.
<Chainsaw> ulm: It's the only way.
<Chainsaw> Zero_Chaos: You've tried step 1, why are you now at step 4?
<WilliamH> So should we send this to the project lead for a ruling then?
<Chainsaw> WilliamH: He's in the channel. Yes. *That* is step 2.
<Zero_Chaos> Chainsaw: forgive me, I'm new here, I thought policy decisions
	     came from council.					        [21:38]
<ulm> I'm all for sending this to the project(s) first
<Betelgeuse> the ebuild is not part of any herds
<Betelgeuse> So what project(s) would that be?
<Chainsaw> Betelgeuse: herd/project; I think dberkholz has a stake here.
<grobian> ulm: +1
<Chainsaw> Betelgeuse: The "X11" project.
<WilliamH> Zero_Chaos: they do, but the project gets a say first.
<dberkholz> here's the thing
<Zero_Chaos> WilliamH: that's fair
<dberkholz> if you're looking for a policy specific to X drivers, then i'm
	    your guy
<dberkholz> but if you want something global regarding what kinds of things
	    are and are not supported, then council is the right place
								        [21:39]
<Chainsaw> Still trying to skip a step.
<Zero_Chaos> dberkholz: that is what I'm looking for, although if the correct
	     channel is going through the project leader first I am fine with
	     that
<Zero_Chaos> Chainsaw: I really don't understand how devrel has any stake at
	     all in a technical issue.
<Chainsaw> Zero_Chaos: It is a disagreement over packaging style, with a
	   maintainer.						        [21:40]
<WilliamH> Zero_Chaos: they really don't.
<Chainsaw> Zero_Chaos: That's developer relations for an inter-developer
	   conflict.
<Zero_Chaos> Chainsaw: no sir, it isn't. it's a disagreement over what gentoo
	     thinks "stable" should mean.
<WilliamH> Chainsaw: True, it is, but it is a technical disagreement as
	   opposed to a personnel disagreement.
<Chainsaw> This is a disagreement between people.		        [21:41]
<WilliamH> Chainsaw: My understanding of devrel is it is for inter-personal
	   conflicts.
<dberkholz> Chainsaw: devrel explicitly says "conflicts of a non technical
	    nature" (http://www.gentoo.org/proj/en/devrel/policy.xml)
<ulm> I suggest that we send the issue back to projects		        [21:42]
<ulm> we can come back to it in the next meeting if necessary
<WilliamH> This is a technical conflict about an x driver, so it should go to
	   dberkholz
<dberkholz> while there were some personal issues entering the discussion, the
	    core issue here is what the support policy should be for stable,
	    proprietary drivers
<Chainsaw> "Any conflicts that are purely technical should be addressed to QA
	   and they will be handled according to GLEP 48."
<Chainsaw> Very well. Ask Flameeyes.
<Zero_Chaos> with the councils permission, may I confer with the head of the X
	     project for 5 minutes to see if this is quick enough to not
	     postpone?
<Chainsaw> At *no* point does one go directly to the council with a matter
	   like this.
<ulm> Zero_Chaos: go ahead
<Chainsaw> Please do.
<Betelgeuse> ok
<Zero_Chaos> Chainsaw: as there is no herd to address I did not know where to
	     go, I apologize					        [21:43]
* Chainsaw remains of the firm opinion that this goes to developer relations,
  but if you wish to pursue this "technical" avenue, you get Flameeyes from QA
<Zero_Chaos> dberkholz: I feel it is hurting our users to allow nvidia-drivers
	     to have stable keywords and not patch it with (again, imho)
	     trivial patches to keep it buildable. If we are going to make no
	     effort at all (as the maintainer suggests) then we really
	     shouldn't allow it to be stable.
<dberkholz> i would concur re escalation to QA if needed to determine how it
	    might fit in w/ existing policy			        [21:44]
<Zero_Chaos> dberkholz: I am open to any solution that you want to provide but
	     the current "it's stable but I don't care if it builds" is
	     embarassing.
<WilliamH> may I ask a question?				        [21:45]
<ssuominen> flameeyes is running tinderbox with stable packages too, and he
	    WILL reopen any bugs closed prematurely, as experienced
<ssuominen> when package is not yet stable
<dberkholz> our approach to proprietary drivers has generally been one that we
	    can't be held back by them and will continue to stabilize OSS
	    stuff even if it breaks closed things
<Chainsaw> WilliamH: Always.
<WilliamH> We have stable kernels the nvidia drivers build with right?  [21:46]
<Zero_Chaos> dberkholz: Just for reference, the most common suggestion for
	     solving this has been to have an nvidia-drivers-unsupported (or
	     some such) ebuild added to the tree that will get patches and
	     remain functional
<Zero_Chaos> WilliamH: yeah just not any of the recent ones
<Chainsaw> Zero_Chaos: That seems like a rather elaborate way to sidestep the
	   current maintainer.
<Zero_Chaos> Chainsaw: it was not my suggestion and I have been fighting it as
	     I don't wish to fork it. This was simply the suggested solution
	     provided to me by no less than 4 devs.
<dberkholz> hasn't the current maintainer expressed a desire to step down?
								        [21:47]
<Zero_Chaos> Chainsaw: and yes, it is a rather elaborate way to sidestep the
	     current maintainer.
<dberkholz> if so, there's room for a new one to do whatever he or she wants.
<Chainsaw> dberkholz: Cardoe has, rej hasn't.
<Zero_Chaos> dberkholz: the previous maintainer did step down, the current
	     maintainer is also unwilling to patch
<Chainsaw> dberkholz: That's what all this boils down to. A disagreement with
	   rej.
<Zero_Chaos> *sigh*
<Zero_Chaos> Chainsaw: this isn't personal			        [21:48]
<grobian> so, someone needs to talk to him and see if we can resolve the
	  problem?
<ssuominen> How can any developer change the meaning of stable on his own?
<Zero_Chaos> ssuominen seems to have my point.
<grobian> as in, take over in a friendly way
* WilliamH would suggest that dberkholz talk with rej about it...
<Chainsaw> Zero_Chaos: I honestly don't care if it is personal or not. You
	   have a problem with rej's maintainership of nvidia-driver. If
	   devrel is a bridge too far, then yes, have someone mediate.
<ssuominen> grobian: undoable, got called "Moron." and other not worth
	    replying
<ulm> ok folks, I don't see us decide on the issue during this meeting  [21:49]
<Chainsaw> Zero_Chaos: But if devrel is a bridge too far, the council is even
	   further away.
<Zero_Chaos> ulm: agreed, and fair.
<ulm> let's postpone it
<Chainsaw> ulm: Okay.
<ssuominen> I don't want to file revrel bug for rej for calling me an moron
	    for not agreeing, and escalating this.
<scarabeus> hello guys do you have som e required votes from me? i have non
	    working droid irc but i just sshed from the beamer and can give
	    some votes really fast :-)
<dberkholz> i think this is a question of what stable really means, and it
	    can't be the opinion of any single maintainer.
<dberkholz> nor a project lead.					        [21:50]
<ulm> Zero_Chaos: we can come back to it next month
<dberkholz> should go to QA
<ulm> but I'd hope that it'll be resolved by then
<Betelgeuse> Sounds like something that in the end should be GLEPped
<Chainsaw> dberkholz: Sure. QA or devrel. Pick one, and let's move on. Out of
	   our jurisdiction.
<Zero_Chaos> dberkholz: that is why I had asked for council involvement
	     originally, but if QA is the right place you can I can discuss
	     after the meeting officially closes if you still have a few
	     minutes.
<dberkholz> however much i'd like to just go put the smack down on people =)
<grobian> I'd just like this not to end up at people doing a lot for gentoo,
	  leaving the project
<ssuominen> this issue will likely be moot in ~2-3 weeks when new drivers go
	    stable and everyone will forget, until next time
<Zero_Chaos> ssuominen: those drivers have already been released, and I'm not
	     letting this go.					        [21:51]
<Zero_Chaos> so let's all let the council meeting move on and address this
	     after.
<ulm> scarabeus: only approval of the summary for the 20090625 meeting
<scarabeus> ulm: that seems fine :-) and again sorry for the lag, i completely
	    forgot
<ulm> ok, open floor then					        [21:52]
<dberkholz> on a maintainer level, seems like this should just be an issue of
	    fiddling with blockers
<dberkholz> so at least stuff doesn't break, even if incompatible upgrades
	    aren't offered.
<WilliamH> dberkholz: that's a good point too.
<Chainsaw> dberkholz: There was the global condemnation of < deps a while
	   back, which may have kept strict dependencies from being applied.
<ulm> any topic for open floor?					        [21:53]
<Chainsaw> dberkholz: But yes, that needs to happen. Portage needs a decent
	   chance to present a working combination.
* Chainsaw makes sure the microphone is on
<Zero_Chaos> Chainsaw: it is
* ulm doesn't see any request to speak				        [21:54]
<dberkholz> it is always the wrong choice to present users with a broken
	    build, so that should be avoided.			        [21:55]
<ulm> next meeting will be at 2013-04-09
<WilliamH> ulm: sounds good to me.
<Chainsaw> ulm: I shall aim to appear unprompted.		        [21:56]
<ulm> should we move to 19:00 UTC because of daylight saving time?
<ssuominen> dberkholz: not always, for ~arch setting unnecessary < deps or
	    blockers will only hinder the effort of fixing the newer package,
	    in worst case, downgrade a library with changed soname that other
	    packages use too
<ssuominen> dberkholz: for stable, true
<ssuominen> dberkholz: even worse, no soname changed and api changed and
	    downgrade breaks even worse				        [21:57]
<ssuominen> (typoes)
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "next meeting 2013-04-09 |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
    http://www.gentoo.org/proj/en/council/"
<grobian> ulm: I opt for 21:00 western-europe time
<ulm> grobian: western-europe as in britain?			        [21:58]
<Chainsaw> ulm: No, as in CEST. Your time.
<ulm> or central europe as in germany, france?
<grobian> ulm: as in Europe/Amsterdam
<grobian> :)
<dberkholz> ssuominen: sorry? must be missing something. if i'm maintainer and
	    already know something is broken, how is masking/changing deps
	    going to change that?
<ulm> grobian: that's 19:00 UTC then				        [21:59]
<grobian> fine with me
<WilliamH> fine with me.
<ulm> the meeting is closed then
<ulm> thanks to everyone for participating			        [22:00]
<grobian> thanks for chairing ulm
<dberkholz> nice short meeting as promised =P
<Zero_Chaos> ulm: thanks