good afternoon/evening :) Agenda is here: http://article.gmane.org/gmane.linux.gentoo.devel.announce/1980 rich0: but it's stable! :D roll call of course here here here hi [21:01] here dberkholz? let's start [21:02] does anyone have his number and can call donnie? nope [21:03] I have it and you should all have it too, but maybe someone not roaming should try :D someone in the u.s. preferably [21:04] PM me and I can sms it err, /msg blueness is doing it already [21:05] no answer k let's start then 2. Minor architectures stabilisation policy [21:06] (episode 2) "The council strikes back"? No one on the arch teams has stepped up, so some last minute answers on the ml I think we can drop stable keywords on those archs WilliamH: not fully true, comments by jmorgan and matt how? ago has posted a bug count for alpha, ia64, sparc ok [21:07] ulm: he can't keep up forever honestly I hear objections on the ml, but no plan to actually address the problems. I'm in favor of either droping entirely, or the compromise I suggested which would let maintainers drop package-by-package after 90 days rich0: Yes, I agree regarding your 2c; we can't have users wanting to use a stabilized minor arch without enough users (incl. Gentoo Devs) able to keep that particular arch stable tested, after all users can become arch testers so we're not the ones to blame it. If it can't be done, it's not our fault that it is being dropped; but rather the lack of interest and perhaps even the lack of need. Step-by-step as well as releasing news could be nice efforts to find people whom are interested; as perhaps interested users currently might not notice the lack of interest, and not everyone actively visits the arch tester staffing needs Wiki page. http://article.gmane.org/gmane.linux.gentoo.project/3034 [21:08] The package-by-package approach has the virtue of putting pressure on the team to take action, but at the same time lowering their burden over time. They could just bunker down and focus on @system and at least have someplace to move forward from if they get more help it doesn't look so bad for these three arches rich0: objections without a plan aren't much. WilliamH: I said as much in my email - the plan is what matters. I suggest at least implementing the package-by-package approach. [21:09] rich0: I could go for dropping stable keywords package-by-package. ok now how do we proceed... one thing is clear, decisions now are per-arch always [21:10] Maybe s390/m68k could be dropped entirely - I'm neutral on that I think a general policy that allows maintainers to drop packages after 90 days is a good approach. That could apply across all archs, even the major ones. rich0: I could go for decisions per arch Again, assuming no legitimate effort to resolve issues/etc. why can't we just grep the tree, find all packages with stable keywords for, say m68k, and just drop them all to ~ in one commit [21:11] too much work? let's discuss it arch by arch rich0: just to be clear, 90 days after stablereq for the package or the first dependency that was stablereqed? blueness: for something like m68k that might be worthwile. For something like alpha, maybe not quite necessary. kk begin with alpha *** toralf (~toralf@f054055169.adsl.alicedsl.de) has joined channel #gentoo-council ulm: how about begin with m68k? [21:12] mgorny: 90 days after the arch was added to the stablereq. (start with the most problematic case and work our way to the easy ones) Honestly, I think the 90-day thing should apply universally. Even to x86/amd64. dilfridge: yeah, we can do that m68k then rich0: I could go for that. [21:13] * dilfridge proposes dropping to ~m68k rich0: I could go for a smaller window actually -- 60 days maybe? yes drop everything to ~m68k in one shot * WilliamH seconds dilfridge's proposal can we just vote on m68k then [21:14] * scarabeus agrees with dilfridge WilliamH: nah that they are small is no excuse for delays, they can get more people (now amd64 is factically just ago :P) drop everything to ~m68k? yes/no * dilfridge yes yes * blueness yes * scarabeus yes yes * ulm yes unanimous next: s390 drop it to ~s390 [21:15] smae same * WilliamH yes * blueness yes * ulm yes * rich0 yes * dilfridge yes blueness: that's a yes? yes unanimous next: sh [21:16] drop to ~sh proposal, wait and folrmulate a proposal that maintinaers can drop * WilliamH yes * ulm yes * blueness yes yes to what? dilfridge: ++ [21:17] Honestly, for all the other archs I'd probably go package-by-package, at least for now. dilfridge: drop everything to ~sh dilfridge: dropping sh to ~ ok, let's repeat then, * dilfridge no vote for "drop everything to ~sh" * blueness yes * dilfridge no * WilliamH yes [21:18] * rich0 yes (lots of bugs, no reply on list) * ulm yes [21:19] ok drop too checked the queue and state so it took a lag :) 5 yes votes, 1 no vote motion passes next: ia64 package-by-package, at least for now 17 open stable bugs, not so bad [21:20] or no action, wait and see so not sure why we should drop it ulm: because it is onlyu compile tested ulm: only ago doing it, honestly that is not long term and he only compile-test we can always later talk about a "maintainer drop policy" and because only ago does it so if he goes MIA end of story I wouldn't drop ia64 yet [21:21] i have mixed feelings about ia64 *** _AxS_ (~axs@gentoo/developer/axs) has joined channel #gentoo-council * WilliamH wants a maintainer drop policy for all archs I think that there is more hope going package-by-package there. WilliamH: ++ WilliamH: ++ i am sorry to repeat myself, but this arch is only compile tested. does it really qualify as a stable arch? let's do a two step vote, first vote if any action is required for ia64, and second vote if it'll be global or package by package hwoarang: I think that is up to the needs of the arch - let them worry about what stable means for them [21:22] oook ulm: how would you do "p by p"? or what exactly do you mean by that? dilfridge: as outlined above [21:23] dilfridge: for any package with a stable request that has been assigned to the arch for 90 days, the maintainer can drop stable keywords for the package on that arch ok dilfridge: see rich0's e-mail tbh that should be allowed for any arch... dilfridge: ++ ulm: can we paste that for the log? is it the same if stablereq was filed for obligatory dep? dilfridge: the problem is that it isn't currently so we are forced to keep old versions around rich0: can you paste you p-to-p proposal? [21:24] *p-by-p mgorny: good point... maybe if the chain is pointed out in the stable req? anyway, first vote: is any action required for ia64 [21:25] * ulm no * dilfridge no * blueness abstains any action? yes [21:26] * WilliamH votes yes The action will be covered if we approve the p-by-p policy for all archs * scarabeus yes 3 yes votes, 2 no votes, 1 abstention [21:27] passes My proposal: If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a pending STABLEREQ, for 90 days with archs CCed and otherwise ready to be stabilized, the maintainer can remove older stable versions of the package at their discretion. A package is considered ready to be stabilized if it has been in the tree for 30 days, and has no known major flaws on arches that upstream considers supported. basically i still agree with the compile-only-tested we used to have this page that said that stable is actually stable and you could trust it, we honestly can't ensure it if it is just some buildbot runnin' [21:28] We don't need a separate vote for package-by-package for ia64 if we adopt it for all arch's. That would also cover the ia64 "action". rich0: who cleans up the rdeps? rich0: one detail, I would add to the text: second vote then, drop everything to ~ia64, or package-by-package rich0: you should at least include a note about the package not having any known issues on the arch * ulm package-by-package [21:29] jmbsvicetto: That last bit covers no major flaws that upstream considers supported. rich0: ... and the arch team is not responding or no reason is given why it cannot be stabilized rich0: in the past some packages had new versions that didn't work on a specific arch for months exactly blueness sent me a msg that he abstains on ia64 jmbsvicetto: and upstream didn't care at all :-) rich0: except when upstream doesn't care a bit about non amd64/x86 I think we need to distinguish between doesn't work and is a work in progress, and doesn't work and probably won't ever work. come on maintainers are not assholes [21:30] i think you over-engineer this If upstream doesn't care about non-amd64/x86, then the arch team gets to patch every release in 90 days or lose it. if arch guy says i am working on it they wont drop It shouldn't be on the maintainer to do that. jmbsvicetto: in that case, shouldn't keywords be "-* amd64 x86" but mostly it is nothing for 6 months until some other distro (debian) fix it rich0: I'm fine if an arch team responds "sorry we cannot do this version, we'll try to do a future one where bugs for us are fixed" rich0: I'm not fine with an arch team just not responding at all [21:31] My issue is that it isn't enough to say that they're working on it. They really need to make progress in a reasonable period of time. The maintainer always has discretion to wait longer. rich0: ++ rich0: again up to maintianer discretion back (sorry) WilliamH: in some cases it might work - unless upstream purposely tries to break it on other arches I see all of this as a balance between maintainers and arch teams. If they can work out their own compromise more power to them. if you won't get the fix or replies about the progress just kill it * WilliamH agrees with scarabeus [21:32] All we are doing at this level is saying that maintainers have permission to demote packages to ~ when arch teams do not respond after 90 days on a stable request. [21:33] It is nice that I want a stable KDE on GNU/hurd, but do maintainers need to keep KDE-0.5 around for me to finish up on that? rich0: any modifications on your p-by-p proposal, or can we vote on the version posted above? link please? I missed the link to the proposal WilliamH: it's posted inline WilliamH: he pasted it here; the full text :) backlog rich0: you're ignoring option 4 rich0: with option 4, maintainer stop having any responsability for the old versions [21:34] jmbsvicetto: I thought about that a bit - if an arch team member wants to co-maintain they should of course be willing to do so, and then they're the maintainer Yes, it would just be someone stepping up and taking a co-maintainer role. rich0: that case won't happen option 4 is not really sensible, also it messes up our definitions in metadata.xml I agree. I don't think it is very practical. But, nothing really needs adjustment. If they actually step up and co-maintain, well, they're the maintainer and can work out a compromise with themselves. [21:35] rich0: if all you the council wants is to address maintainers complains that they need to keep old versions around for some "slow arch", why not tell them that when they're ready to drop that version, they can just leave the keywords for the "slow arches" and "pass the baby" to the arch teams? rich0: one more question though since nobody seem to have understood my problem with deps rich0: let's assume foo-1 didn't have a dep on bar, foo-2 has on >=bar-2 A problem is though that metadata.xml doesn't really cover this - they're going to get pestered over bugs [21:36] rich0: i filed stablereq for bar-2 and had no answer, so i didn't even bother filing one of foo-2 rich0: would that quality for dropping foo-1 from stable (it had no dep on bar) i woudl think so mgorny mgorny: good point - I had a discussion with pacho2 about that I would think so yes, but it definitely would help to post in the stablerequ "this is urgently needed for ..." [21:37] mgorny: are you the maintainer of both foo and bar? no, and it's just theoretical mgorny: I'd say that you should file a stablereq for bar, just to make things clear mgorny: Doesn't that depend on whether there is a reason to be dropping keywords on foo-1? eg. Security, ... supposedly foo-2 may happen even long after bar it is somehow related to python-exec which is a dep of all python packages if nobody bothered stabilizing it, every new python package in the tree can't go stable [21:38] *sigh* can we proceed please? (it's not a case anymore) still ia64 are we ready for the vote? * scarabeus is how about voting aout the general rich0 proposal? [21:39] arch independent? dilfridge: ++ dilfridge: no lets keep it arch by arch and then conver it *convert it um, not for amd64 and the other major arches, we were not mandated to do that if desired we started arch by arch, and we don't change procedure in the middle ok blueness: honestly, I'd just make the policy generic and apply it to everybody rich0, maybe but we didn't announce that Then we don't have to argue about who are and aren't keeping up/etc. blueness: fair enough [21:40] vote for ia64: drop to ~ia64 globally, or package-by-package proposal of rich0 * scarabeus p-b-p * ulm p-by-p * dilfridge p-b-p * rich0 p-b-p * blueness p-b-p * WilliamH p-by-p unanimously package-by-package next: sparc [21:41] please vote: action required? * ulm no * scarabeus aye * dilfridge no * blueness no * rich0 yes * scarabeus hopes he won't say yes :P [21:42] tie sucks WilliamH? * WilliamH votes yes 3 yes votes, 3 no votes tie, so motion doesn't pass finally, alpha [21:43] please vote: action required? * ulm no yes * dilfridge abstains * rich0 yes * scarabeus yes [21:44] * WilliamH yes 4 yes votes, 1 no vote, 1 abstention passes vote for alpha: drop to ~alpha globally, or package-by-package? * rich0 p-b-p * ulm p-by-p [21:45] * dilfridge p-b-p * scarabeus p-b-p * WilliamH p-b-p * blueness p-b-p unanimous so to summarise: m68k, s390, sh will be dropped to testing globally alpha and ia64 package-by-package proposal [21:46] no action for sparc ok nice are we done with the topic? * dilfridge likes * dilfridge thinks so [21:47] for now. :) next topic 3. GLEP draft "Prefix with libc" this has two parts, actually get the GLEP team working again, and the GLEP draft let's start with the draft [21:48] Wouldn't the glep team handle the glep draft? ;-) WilliamH: heroxbd didn't get any answer from them for several weeks I think the issue is that there is no GLEP team. :) effectively... * dilfridge is wondering where that alias ends up [21:49] I think it needs a little work - in particular the rationale which seems redundant with the motivation and not a defense of the specification which was the intent of the GLEP process do we need people to step up for the GLEP team? we should email -dev creffett: probably [21:50] but we come to this in a minute let's discuss the draft first in general I like the idea very much me too, but I'd like to see a comment from the prefix team [21:51] Agree with the concept. Would love to try it out - the docs need a bit of work. Anybody involved in this besides heroxbd? whatever makes a prefix easier to build and closer to a "vanilla gentoo" is good dilfridge, ++ [21:52] Yup - ancient glibc is a big problem with prefix - when I tried it out on Solaries it caused tons of issues. well heroxbd is in the prefix team I think right, he is [21:53] Perhaps we should endorse without necessarily approving to allow it to be further developed. I see no reason to keep it out of the main tree though. I think the only question I'd have is if it is final enough to be worth writing in stone yet. rich0: sounds good [21:54] rich0: that sounds reasonable to me do we need a formal vote on this? * scarabeus would leave this to prefix team to play honestly, and lets finalise it when glep team is alive and we have something to write properly that it is working so what rich0 said... :-) I think a formal endorsement would be good scarabeus: right. We aren't being asked to approve this as final... This is good work. yeah let's vote on this so please vote [21:55] How about: rich0: go ahead on what? "The council endorses the GLEP draft for RAP and encourages its further refinement (including inside the portage tree if helpful). The council looks forward to the final draft for eventual approval." [21:56] good k * WilliamH yes * dilfridge yes please vote on this ^^ * blueness yes * rich0 yes * ulm yes * scarabeus yes unanimous second request from heroxbd was: "I'd like to ask the council to reinitiate a GLEP team and recover our GLEP process" [21:57] * dilfridge pulls a glep team out of the magic hat Suggest putting out a call for volunteers there. any suggestions what the council can do about this? just put out a call for volunteers... [21:58] no idea what we can do That's really the most we can do I think. I might send him some suggestions if nothing else. ie i can't volunteer, we need somebody to lead it and recruit more people Let's see what a call does. I wouldn't call that "done" but it is a first step. right now glep@g.o forwards to dev-zero ... We should find out what his status is... [21:59] dilfridge: antarus is on the glep team, too The GLEP team makes our job easier, so we should try to make it robust if we can. that may be the case but he doesn't get the mail is there anyone on the glep team now? gleps seem to be fading blueness: antarus and dev-zero nobody really bothers with GLEPs - they just do stuff. :) [22:00] dev-zero is usually too busy *** mrueg (~mrueg@gentoo/developer/mrueg) has joined channel #gentoo-council technical savy guys should go there; mgorny, ssuominen, somebody like that if they have time... Or just make specific proposals in non-GLEP format. PMS has superseded it to a degree. so, I note as action that we put out a call for volunteers? yes who will take care of it? rich0, well i'm thinking of writing a glep for the vdb stuff We need to see if the people on the team still want to be there too. [22:01] That would be antarus and dev-zero from the project page ulm: fyi - we're at 1hr and unfortunately I need to leave fairly soon. This might be a record-setting meeting :) [22:02] me too well, we still need soneone to take care of the call for volunteers ulm: I'll volunteer to seek volunteers : [22:03] rich0: k so, should we stop here again? I hope you're not proposing to continue next week? :D [22:04] WilliamH's topic would suffer from it ulm, yes please WilliamH: sorry for making your life hell heh WilliamH, sorry but i really have to go in about 5 mins I think my topic will be pretty quick... same bat-time, same bat-channel? WilliamH: likely anything but. :) [22:05] next week is fine for me. WilliamH, this will not be quick so next week? * blueness yes * rich0 yes * dilfridge yes, pending Alitalia behaviour WilliamH: suggest you feel free to put out feelers via email or list if you want to prepare the ground *** Hello71 (Hello71@wikipedia/Hello71) has joined channel #gentoo-council [22:06] ok *** redlizard (~redlizard@168-9-ftth.onsnetstudenten.nl) has joined channel #gentoo-council next meeting: 2013-09-24 19:00 UTC i'm out of here guys, sorry to run we're earning our pay this month. *** dilfridge (~quassel@gentoo/developer/dilfridge) has set the topic for #gentoo-council: "Next weekly meeting: 24 Sep 2013 at 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | Agenda: http://article.gmane.org/gmane.linux.gentoo.devel.announce/1980 | http://www.gentoo.org/proj/en/council/" can we vote on a 20% raise? [22:07] rich0: heh someone thinks that he'll be quicker with chairing then me? ;) won't help you much, 20% of zero is still zero :D i demand fosdem beer! :D ulm: I can do it seriously though - this is all good stuff and we're making progress dilfridge: pending alitalia? not much fluff on the agenda flying from italy to muc next tuesday [22:08] if all goes well I should arrive in time dilfridge: ok, you take the chair then will do with me as a backup dilfridge: who sends the agenda? will do [22:09] thanks meeting is closed then