path: root/meeting-logs/20130917.txt

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