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