path: root/meeting-logs/20130409.txt

<ulm> 19 UTC
<grobian> bash-42
<dberkholz> looks like your patchset policy thing didn't make it into the
	    agenda yet
<ulm> let's start
<ulm> roll call
* scarabeus aroundy
<ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2381
<grobian> here
<ulm> Chainsaw: still here? :)					        [21:01]
<Chainsaw> ulm: Yes :)
<ulm> Betelgeuse, WilliamH?					        [21:02]
<ulm> can someone phone/text them?
<ulm> and not always me, I've done this for the last four meetings      [21:06]
<grobian> sorry							        [21:07]
<grobian> did anyone already take action?			        [21:08]
<jmbsvicetto> Do you need me to call Petteri?
<jmbsvicetto> I don't have William's number
<ulm> jmbsvicetto: yes, please
<ulm> I'll text WilliamH then					        [21:09]
<jmbsvicetto> hmm, I got some automated reply as soon as I called Petteri
<jmbsvicetto> and as you can imagine, finish == chinese to me :P
* WilliamH is here						        [21:10]
<ulm> welcome :)
<WilliamH> I was just working on an email I'm about to send out, sorry folks.
<ulm> 10 minutes passed, so let's move on			        [21:11]
<scarabeus> ook
<ulm> Change to newer Bash version in ebuilds
<ulm> see references in the agenda
<grobian> what exactly do you want to do on the subject?	        [21:12]
<grobian> vote?
<ulm> too early to vote, I think				        [21:13]
<Chainsaw> Last time this came up, it was a problem for prefix.
<scarabeus> nothing to vote there
<scarabeus> it can be nominated for the eapi and voted then
<grobian> ok, well, I think EAPI6 could have bash-4.2, but that we need to
	  have a portage that reads EAPI line (as opposed to sourcing the
	  ebuild) for at least a year stable
<Chainsaw> Because they had older bash versions on their "main" OS.
<ulm> the main problem is with the upgrade path			        [21:14]
<grobian> that sums up basically what you wrote in the email thread, ulm
<dberkholz> i'd defer to grobian on that one.
<grobian> Chainsaw: can't imagine that was prefix
<ulm> there's two dates, EAPI parsing was in stable portage in June 2012
<grobian> Chainsaw: only can be a problem if we go for deprecation of EAPI0
	  and stuff
<ulm> and bash 4.2 went stable in March 2012 already
<dberkholz> i would suggest we put a bash update into its own EAPI, or if
	    there's anything else ready to go then we add that, so we can have
	    it stabilized on or shortly after july 1 (1 yr since stable
	    EAPI=5)						        [21:15]
<Chainsaw> grobian: The OS X one, from what I remember.
<scarabeus> grobian: eapi 0 is too big, everything in between can start to die
<ulm> we'll come to eapi deprecation later
<grobian> Chainsaw: yeah, that's a bootstrapping problem
<grobian> e.g. on solaris					        [21:16]
<ulm> let's stay with bash version
<grobian> scarabeus: agreeed
<grobian> scarabeus: I didn't want to jump ahead to the next agenda item
<dberkholz> don't want to delay this another 6 months or longer in convoluted
	    EAPI discussions
<Chainsaw> grobian: Would it still be a problem, or can it be managed?
<Chainsaw> grobian: That's really the only argument against that I remember
	   from last round.
<grobian> well, I don't think it's much of a problem, as we manually compile
	  bash prior to the bootstrap				        [21:17]
<grobian> unless I forgot something myself
<ulm> dberkholz: I'd rather go for longer time than one year here
<ulm> not shorter
<dberkholz> who said shorter?
<ulm> <dberkholz> i would suggest we put a bash update into its own EAPI
								        [21:18]
<ulm> or was the intention to delay bash update until after EAPI 6?
<dberkholz> i'm assuming you also read that to the end, where i said 1 year
	    since stable EAPI=5
<WilliamH> when was eapi=5 stable?				        [21:19]
<dberkholz> not shorter than 1 year
<ulm> WilliamH: July 2012
<ulm> sorry, that was EAPI parsing
<WilliamH> ok so we are almost at a year then.
<WilliamH> ulm: ok...						        [21:20]
<ulm> WilliamH: 2012-12-11 for EAPI 5
<WilliamH> ulm: ok						        [21:21]
<dberkholz> bah, what i meant was 1 yr since EAPI parsing.
<ulm> so, we see how preparation for EAPI 6 goes, and then come back to bash
      version depending how long it takes?			        [21:22]
<WilliamH> Why not put the bash update in eapi 6?
<grobian> hmmm, you want to apply it outside of eapi?
<dberkholz> personally i'd prefer the other way around
<ulm> grobian: not outside of EAPI
<grobian> I'd go for EAPI6
<ulm> EAPI 6 makes perfect sense
<grobian> put it on the list
<ulm> and we could always fall back to mgorny's suggestion, namely forbid bash
      4.2 features in global scope for some transition time	        [21:23]
<grobian> if it delays, we can always scratch it
<dberkholz> delays till when?
<dberkholz> let's do something real here
<grobian> because next month we want to approve EAPI6
<grobian> not really likely of course
<grobian> so, seems like it should be just an EAPI6 item	        [21:24]
<ulm> grobian: +1
<grobian> nothing transition or something, because portage will barf more
	  errors if you don't have EAPI-parsing
<ulm> ok, no action for the time being				        [21:25]
<ulm> move on?
<grobian> yes please
<ulm> oops, I forgot one point					        [21:26]
<ulm> additional agenda point for patch policy
<ulm> should we add it to today's agenda?
<grobian> I'm against
<grobian> didn't prepare					        [21:27]
<WilliamH> grobian: +1
<ulm> doesn't look so urgent to me, and the agenda is already packed
<grobian> did we discuss eapi deprecation yet?
<dberkholz> i do have an opinion on the policy, but don't mind delaying for
	    others
* scarabeus can talk about it, but basically i can recommend looking on
  fedora/suse patching, more restrictive the better
<ulm> so, just vote: agenda item to be added?			        [21:28]
* ulm votes no
<grobian> no
* WilliamH votes no
* scarabeus indiferent
<ulm> ok, 3 times no and one indifferent means that it's not approved   [21:29]
<ulm> next point, EAPI deprecation
<ulm> we can come back to patch policy next month		        [21:30]
<grobian> ok, where do you want to start :)
<ulm> I'm a bit worried that we have 6 different EAPIs in active use
<scarabeus> we should look on the qa-reports page where is the eapi listing
	    and hard-deprecate those with low numbers
<ulm> soon it will be 7						        [21:31]
<WilliamH> Me too.
<scarabeus> 0 is out of question for now but others should be phased out
<ulm> http://qa-reports.gentoo.org/output/eapi_usage.txt
<ulm> scarabeus: it makes no sense to start with anything but 0
<grobian> why?							        [21:32]
<ulm> because largest difference in features is from newest EAPI to EAPI 0
<WilliamH> We could have repoman start complaining if you try to commit
	   something with an old eapi setting.
<grobian> frankly, I've built a toolchain, and I don't want to mess with it
<ulm> e.g. src_prepare and src_configure
<grobian> imo, it's legacy that we need to accept		        [21:33]
<grobian> moving away from it as much as possible
<grobian> I like deprecation, four years, or four sensical EAPIs
<ulm> I'd suggest that we start differently: there's still the myth that EAPI
      0 needs to be kept for system packages for upgrade path
<WilliamH> grobian: the thing is that some people won't move  ebuilds away
	   from it if we don't start at least complaining about it.
<grobian> WilliamH: yeah, but I'm not against that		        [21:34]
<dberkholz> i'd just start with a repoman warning on anything but latest
	    stable
<ulm> so the first step would be that we make a statement like "EAPI 0 and 1
      are not required for upgrade path, you can move everything to 2."
<dberkholz> encourage people to move by bugging them
<ulm> or 3 even
<scarabeus> ulm: i would go for 3
<grobian> ulm: yeah, probably could say that
<scarabeus> actually we are bugging them			        [21:35]
* WilliamH agrees with dberkholz 
<scarabeus> the rule is use new eapi no?
<scarabeus> but they happily ignore it
<WilliamH>  We always encourage the latest eapi so we should start complaining
	   when people aren't using it.
<grobian> scarabeus: if the new eapi doesn't add anything?
<Chainsaw> grobian: Then the EAPI bump should be uneventful.	        [21:36]
<WilliamH> grobian: then just bump the eapi= setting and be done with it.
<Chainsaw> grobian: That argument works both ways :)
<scarabeus> grobian: that is moot now, as eapi5 has the subslots which should
	    be used almost everywhere
<grobian> no no
<Chainsaw> I think a case can be made for EAPI 1 to 4 to emit a
	   EAPI.discouraged warning.
<grobian> you can't just bump eapi without looking
<Chainsaw> IT should not be fatal.
<Chainsaw> s/IT/It/
<ulm> Chainsaw: why no for 0?					        [21:37]
<Chainsaw> EAPI 0 is a toolchain requirement.
<ulm> *not
<WilliamH> grobian: no, but it is up to you to test before you commit. :p
<dberkholz> in case anyone else wants to see EAPI use visually ...
	    http://www.chartgo.com/create.do?chart=bar&dimension=2d&width=500&height=400&orientation=vertical&title=EAPI+usage&subtitle=&xtitle=EAPI&ytitle=Ebuilds&source=&fonttypetitle=bold&fonttypelabel=normal&labelorientation=horizontal&chrtbkgndcolor=gradientblue&max_yaxis=&transparency=1&labels=1&min_yaxis=&roundedge=1&shadow=1&border=1&xaxis1=0%0D%0A1%0D%0A2%0D%0A3%0D%0A4%0D%0A5&yaxis
<Chainsaw> The Y data field is empty. Y data cannot be empty.
<dberkholz> or http://monk.ly/10PKS76
<WilliamH> Chainsaw: ?						        [21:38]
<grobian> the discussion always revolves around who is doing the work and why
<ulm> dberkholz: heh, can you plot this against time? ;)
<grobian> I still don't see problems, other than maintenance and cosmetics
<dberkholz> sure i could. obviously everything is easier in git but can always
	    update my conversion
<grobian> yet people suggest maintainers should forcefully upgrade their
	  packages
<grobian> we can't make them do thay
<grobian> and it makes little to no sense to me either		        [21:39]
<grobian> hence, deprecating eapis, warning about 1,2,3 seems ok to me
<Chainsaw> dberkholz: Based on your graph, EAPI 1 to 3 is the soft spot that's
	   easy to hit.
<grobian> 4 seems rather new
<WilliamH> grobian: why not? it would just be part of a revbump or version
	   bump.
<grobian> WilliamH: hehe, src_unpack is not supposed to have epatch in it in
	  EAPI 1+
<ulm> it makes no sense to warn about EAPI 3
<ulm> EAPI 3 still is needed for the upgrade path		        [21:40]
<WilliamH> grobian: right, but you fix that as part of the eapi migration.
<WilliamH> ulm: why is that?
<grobian> WilliamH: yeah, which is a lot of work, which is not giving ANY
	  benefit
<grobian> especially when using PATCHES array becomes mandatory for some EAPI
<grobian> because someone thinks that's "cleaner"
<grobian> and it changes NOTHING from the user's point of view	        [21:41]
<grobian> so why waste scarce developer time?
<WilliamH> grobian: eapis are not relevant to the user anyway.
<grobian> what problem are we solving?
<grobian> yes
<Chainsaw> ulm: In the interest of building consensus...	        [21:42]
<ulm> guys, it looks like this discussion is going nowhere
<Chainsaw> ulm: EAPI.discouraged for 1 & 2.
<WilliamH> grobian: moving away from legacy eapis that we do not need. like
	   was pointed out, we have 6 now, soon to be 7.
<grobian> I'm all for encouraging people (including myself) to get fluent with
	  latest EAPIs
<Chainsaw> ulm: To at least make progress and reduce the total count.
<WilliamH> grobian: but if repoman doesn't complain people will not do it.
<Chainsaw> ulm: I'd rather make weak progress than a strong stand-still.
<grobian> WilliamH: yeah, and I believe the solution is more in folding, like
	  2 can be removed, as 3 is a drop-in replacement	        [21:43]
<grobian> and perhaps we can do 4-5 at some point
<grobian> and deprecate 1 as a whole
<ulm> I'd start with a statement "EAPIs 0 to 2 are no longer required for
      upgrade path"
<grobian> ^^^^ agreed
<dberkholz> ulm: which upgrade path are you referring to?	        [21:44]
<dberkholz> we only support 1 year back, as i recall
<ulm> dberkholz: upgrade path for outdated users' systems
<ulm> dberkholz: minimum of 1 year
<WilliamH> ulm: but we only support one year back.
<ulm> with longer support to be discussed, but that discussion never took
      place							        [21:45]
<dberkholz> therefore it does not exist
* ulm has looked it up in the old meetings' summaries
* WilliamH agrees with dberkholz 
<Chainsaw> Anyhow. EAPI 0 is a toolchain requirement. 1 & 2 seem a valid
	   "EAPI.discouraged" target. 3 and above remain untouched for now.
								        [21:46]
<Chainsaw> Can we vote on that?
<WilliamH> How is eapi0 a requirement?
<Chainsaw> WilliamH: Because toolchain has reported that they need it.
<ulm> Chainsaw: I'd rather grant an exception for toolchain packages
<dberkholz> it's a requirement until someone talks the toolchain team into
	    updating its eclass or does it for them
<Chainsaw> WilliamH: The matter did not seem negotiable.
<WilliamH> dberkholz: what would it take to do that?		        [21:47]
<Chainsaw> ulm: I'd prefer a simpler rule and simpler code in repoman.
<dberkholz> lots of beer?
<grobian> well, I'm not sure we'd want someone to replace it for them
<grobian> we'd need lots of years to confirm that the new stuff is
	  stable/correct
<ulm> ok, let's do two votes					        [21:48]
<WilliamH> wrt repoman,
<ulm> first vote: "EAPIs 0 to 2 are no longer required for the upgrade path of
      old systems"
<WilliamH> I wasn't saying it should be a fatal error in there, just a
	   warning.
* WilliamH votes yes
<ulm> and second vote "EAPIs 1 and 2 are discouraged, repoman check to be
      added"
<ulm> first vote, please					        [21:49]
<dberkholz> can you define old please
<grobian> ulm: first vote: yes
<dberkholz> i think that's important to our discussion/vote
<grobian> ulm second vote: yes
<ulm> dberkholz: strike the word "old"
<dberkholz> if you defined it at our current support window of 1 year, EAPI=3
	    would also be true
<ulm> dberkholz: in principle, yes				        [21:50]
<ulm> but I see no reason to deliberately kill off old systems
* WilliamH votes that eapi 3 should also be added
<Chainsaw> ulm: Sadly, yes. EAPI0, EAPI1 & EAPI2 are unusable due to python.
	   (First vote)
* ulm votes yes on first vote					        [21:51]
<WilliamH> Are we adding eapi 3 to the statement for the first vote?
<ulm> WilliamH: let's decide on that afterwards			        [21:52]
<ulm> otherwise it gets too confusing
<WilliamH> ok
<ulm> dberkholz: scarabeus: WilliamH: your first vote please
<WilliamH> http://article.gmane.org/gmane.linux.gentoo.project/2381/me votes
	   yes
<Arfrever> Chainsaw: Other system packages use higher EAPI than is used in
	   Python.
* WilliamH votes yes						        [21:53]
<WilliamH> sorry about the paste.
<scarabeus> ok sound sane, yes
<ulm> dberkholz?
<dberkholz> yes on both.
<dberkholz> also, my head hurts from banging it into the table.	        [21:54]
<ulm> unanimous then
<ulm> second vote
<ulm> I already have a yes from grobian and dberkholz
* ulm votes yes							        [21:55]
* WilliamH votes yes
<ulm> vote is: "EAPIs 1 and 2 are discouraged, repoman check to be added"
<scarabeus> yes							        [21:56]
<dberkholz> i would like to propose the same for for EAPI 3.
<ulm> Chainsaw: I guess it's yes from you too? since you suggested it?  [21:57]
<ulm> anyway, it's 5 yes votes out of 6, so it's accepted	        [21:58]
<ulm> so WilliamH's suggestion, third vote: "EAPIs 0 to 3 are no longer
      required for the upgrade path of systems"
<ulm> i.e. "0 to 3" instead of "0 to 2"
<grobian> ulm third vote: no					        [21:59]
* ulm votes no
<scarabeus> 3 is too new i think
<ulm> scarabeus: this is a "no"?
<WilliamH> scarabeus: ok no problem there...
*** mpagano (~mpagano@gentoo/developer/mpagano) has quit: Read error:
    Connection reset by peer
<WilliamH> what about adding the discouraged warning to eapi 3?
<dberkholz> too new? it's 3 years old				        [22:00]
<Chainsaw> ulm: Yes.
<Chainsaw> ulm: My apologies for the delayed response.
<ulm> Chainsaw: that's for the second vote?
<dberkholz> on the vote, yes
<Chainsaw> ulm: That is for the second vote: "EAPIs 1 and 2 are discouraged,
	   repoman check to be added"
<ulm> second vote unanomously accepted then			        [22:01]
<ulm> *unanimously
<dberkholz> EAPI 4 is 2 years old. that's still double our existing support
	    window
<scarabeus> dberkholz: you are maybe right, even from the graphs t is second
	    least used eapi...
<ulm> dberkholz: it doesn't hurt to be a little conservative there      [22:02]
<dberkholz> a "discouragement" and repoman warning is pretty conservative
* WilliamH agrees with dberkholz 
<WilliamH> I understand that code has to be kept around, but we should
	   encourage forward movement otherwise it doesn't happen.
								        [22:03]
<ulm> Chainsaw: scarabeus: WilliamH: your vote on 3, please
<scarabeus> vote: extend to eapi 3				        [22:04]
<ulm> scarabeus: that's a "yes"?
<scarabeus> thats a yes						        [22:05]
<ulm> ok :)
* WilliamH votes yes and extend to eapi 4... given what dberkholz  just said
  about the age of eapi 4
<ulm> WilliamH: that would mean that everyone must move to 5	        [22:06]
<Chainsaw> That's a no. EAPI3 can be upgraded to a current system.
<ulm> I count 3 yes and 3 no votes
<scarabeus> awesome1
<scarabeus> !
* WilliamH is ok with extending to eapi 3.
<ulm> that's a tie, so it doesn't pass
* WilliamH votes yes						        [22:07]
<dberkholz> guess we'll have to get Betelgeuse's input later.
<grobian> can we wrap this up, please?
<ulm> we can come back to it in a few months, deprecating 1 2 is already a
      start
<Chainsaw> Agreed, make a start with a simple unambiguous proposal.     [22:08]
<Chainsaw> And build on that later.
<ulm> grobian: will be in the summary and you can comment on it ;)
<ulm> move on?
<grobian> move on yes						        [22:09]
<dberkholz> i'm getting short on laptop battery
<ulm> Open bugs with council involvement
<ulm> bug 457000
<willikins> https://bugs.gentoo.org/457000 "Missing log and summary for
	    20090122 and 20090625 council meetings"; Doc Other,
	    Project-specific documentation; IN_P; ulm:council
<ulm> betelgeuse had volunteered to look into writing the missing summary for
      20090122, but he isn't here				        [22:10]
<ulm> so I think we should skip this bug
<grobian> ok
<ulm> bug 464250						        [22:11]
<willikins> https://bugs.gentoo.org/464250 "Encourage developers to use the
	    latest EAPI"; Doc Other, Devmanual; CONF; ulm:devmanual
<ulm> that was decided in 2011
<dberkholz> and yet we seem to have just voted against that
<grobian> huh?
<dberkholz> assuming encouragement also includes things like discouraging
	    other options
<ulm> not yet implemented in the devamnual
<ulm> dberkholz: encourage != repoman forcing it		        [22:12]
<grobian> who is responsible for devmanual these days?
<dberkholz> i am wildly confused how a warning is a forcing
<WilliamH> ulm: no one said anything about repoman forcing it.
<ulm> grobian: hwoarang is taking care of it
<scarabeus> grobian: i think markos
<grobian> prod him?
<ulm> well, someone should prepare a patch			        [22:13]
<ulm> any volunteers?
<ulm> should be easy, just insert these two sentences
<grobian> are they in the bug?					        [22:14]
<ulm> grobian: yes :)
<WilliamH> ulm: how is a repoman warning forcing an issue?
<grobian> I'll give it a try then
<ulm> grobian: thanks						        [22:15]
<grobian> and I'd like to wrap up
<ulm> grobian: ok
<grobian> I have to go
<jmbsvicetto> ulm: open floor?
<ulm> jmbsvicetto: status update form Zero_Chaos
<jmbsvicetto> ok						        [22:16]
<dberkholz> i'm totally blocking on that
<scarabeus> just a note new nvidia drivers are released with the support few
	    hours back
<dberkholz> so i'll give Zero_Chaos a whip to flog me with
<Zero_Chaos> I am here as well.
<Zero_Chaos> short version of the update, blocked on dberkholz, he is going to
	     become magically responsive :-)			        [22:17]
<Zero_Chaos> and/or I'll involved QA and revisit next month
<ulm> we discussed bug 447566 last month, and there should be  status update
      in the nect meeting
<ulm> *next
<dberkholz> i just got your 2nd email, totally forgot about the first.
<willikins> ulm: https://bugs.gentoo.org/447566
	    "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19,313.18} fails
	    to build with kernel {3.7,3.8}"; Gentoo Linux, Applications; VERI,
	    WONT; vaeth:jer
<Zero_Chaos> as of yet, the bug is still an issue.
<dberkholz> ping me like you're playing pinball
<Zero_Chaos> at least 6 duplicates tagged since last
<ulm> Zero_Chaos: so, go ahead please, but make it short
<scarabeus> actually best would be to block the darn kernels? (eg state in
	    ebuild what kernels are supported?)			        [22:18]
<Zero_Chaos> other than that I know people are short on time, I wanted to give
	     an update that's it. "Still an issue, not being dropped, I am
	     pushing this till there is a resolution" you may all move on or
	     engage me after the meeting close.
<scarabeus> btw iirc nvidia ignores bugs where the kernel patches are applied
	    (if you are lucky enough and they even care)
<jmbsvicetto> About the fork, I just want to remind that there are more
	      packages going into (already went into) the tree. So if the
	      issue of having multiple ebuilds to provide the same package
	      interests you (council), you should start paying close attention
	      to this topic
<ulm> we're already over time, so I suggest that we move any discussion on
      this to e-mail						        [22:19]
<ulm> considering how long and how heated the discussion was last month
<Zero_Chaos> I will be here after meeting closes if people want to discuss.
	     I'm defering till after the official meeting for anything more
	     than the status I already provided. thanks, please move on.
								        [22:20]
<ulm> k
<ulm> open floor
<ssuominen> was the dodocs/edocs/... voted?
<dberkholz> Zero_Chaos: sorry about the delay, been kinda swamped in gsoc
	    stuff w/ deadlines etc. keep pinging and i will make something
	    happen
<ulm> ssuominen: nope
<ssuominen> why is that? time ran out?				        [22:21]
<dberkholz> Zero_Chaos: be the squeaky wheel
<dberkholz> oh, btw. now that it's open floor, if you haven't heard, we are in
	    the google summer of code again
<dberkholz> for our 8th straight year
<ulm> ssuominen: hm, there was no voting on any eapi 6 features yet     [22:22]
<jmbsvicetto> About the "warning" or repoman checks, I think reality has
	      proven that developers won't change EAPI because of that
<dberkholz> i'm admin with the help of calchan, antarus, g2boojum. so let
	    one/all of us know if you want to help
<ssuominen> oh... I thought that was supposed to happen in next meeting... I
	    guess not then. my bad
<jmbsvicetto> either people have time and will to change the EAPI of package
	      or they don't - warnings aren't likely to increase the
	      conversion rate - imho				        [22:23]
<dberkholz> you'd be amazed how OCD people are. especially gentoo users.
<Chainsaw> Must... fix... repoman... warning.
<jmbsvicetto> dberkholz: users might annoy a developer about it, but I think
	      most developers aren't likely to react to that - or at least to
	      react in a "positive manner"			        [22:24]
<dberkholz> why would users be running repoman?			        [22:25]
<Chainsaw> dberkholz: For ebuild submissions? I tell them that's how I'd grade
	   their work.
<dberkholz> i'm talking about the developer as a gentoo user, of whom many
	    tend to be very picky about having things absolutely perfect
<dberkholz> anyway i'm at 3% battery so i need to power down	        [22:26]
<Chainsaw> jmbsvicetto: For new repoman warnings my initial response tends to
	   be "son of a..." followed by an immediate fix. I can't stand
	   committing builds that warn. It's sloppy.
<Chainsaw> dberkholz: Talk later.
<dberkholz> somehow managed to discharge rather than charge last night for my
	    day at a conference
<jmbsvicetto> dberkholz: even though we might like perfect, many of us are
	      getting too little free time to deal with EAPI bumps
<jmbsvicetto> dberkholz: or we rather prefer to spend our time on other issues
								        [22:27]
<Chainsaw> jmbsvicetto: But you have a life now. It's different :)
<ulm> jmbsvicetto: it's a time scale of several years, so eapi bumps don't
      have to happen very often					        [22:29]
<ulm> if version bumps are always to the newest eapi, then it's very little
      additional work
<ulm> because the old ebuilds just go away			        [22:30]
<jmbsvicetto> ulm: sure, but I think in reality most bumps are only done when
	      their benefit outweights their cost
<jmbsvicetto> ulm: so a developer needs an incentive on the newer EAPI
	      (required feature, ease of use, etc), before considering bumping
	      the EAPI when doing a simple package bump
<ulm> let's see if EAPI 5 will change that			        [22:31]
<ulm> with killer feature of subslots				        [22:32]
<jmbsvicetto> btw, about the "subslot" argument, I think that is starting to
	      backfire
<jmbsvicetto> We're getting too many packages using that in the wrong way and
	      causing everyone to do tons of unnecessary rebuilds
<scarabeus> jmbsvicetto: it is not backfiring, it is problem of people not
	    reading how it works :/
<scarabeus> and what should we do there, we expect the devs to study how it
	    works, it is described quite well			        [22:33]
<ssuominen> deja vu. happens everytime new feature comes along, people overuse
	    them
<ulm> jmbsvicetto: I sure that people will learn how to use it correctly
<ulm> scarabeus: it's one of the best documented features we have
<ulm> at least in devmanual, portage man pages, eapi cheat sheet        [22:34]
<jmbsvicetto> Oh and as someone that looks at a few logs of stage building,
	      lately we seem to be going in the wrong direction - the amount
	      of failures, blocks and scary output in portage has increased
	      exponentially!!
<ulm> and quite extensive in each
<ssuominen> just dropped libpng16 to ~arch, we'll see how subslotting helps ;)
<ulm> folks, we're 35 minutes over time				        [22:35]
<Chainsaw> We've already run one laptop down, yes.
<ulm> anything very important for the open floor?
<ulm> otherwise, I'd like to close the meeting
<Chainsaw> I'm ready to move on, yes.
* Chainsaw plans to turn the laptop off and just read a (paper!) book   [22:36]
<ulm> next meeting 14 May, 19:00 UTC
<ulm> betelgeuse will be your chair
<ulm> meeting is closed, thanks everybody
<Chainsaw> Thanks ulm.
* Chainsaw waves						        [22:37]
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "next meeting 2013-05-14 |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
    http://www.gentoo.org/proj/en/council/"