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

[Markus Ullmann (jokey)]

jokey       08/01/11 16:08:32

  Added:                20080110-summary.txt 20080110.txt
  Log:
  Add 20080110 meeting

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

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

Index: 20080110-summary.txt
===================================================================
Roll call
---------

(here, proxy [by whom] or slacker?)

amne        here
betelgeuse  here
dberkholz   proxy [musikc]
flameeyes   here
lu_zero     here 
vapier      here
jokey       here 

Agenda
------

GLEP 54: scm package version suffix
	http://www.gentoo.org/proj/en/glep/glep-0054.html

GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
	http://www.gentoo.org/proj/en/glep/glep-0055.html

Code of Conduct enforcement 
	http://thread.gmane.org/gmane.linux.gentoo.council/82
	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
	http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt

	- What needs to happen for us to make a decision?

	Last week, we agreed to just add moderators to #gentoo-dev and the
	gentoo-dev list. Other places with their own moderation should enforce the
	CoC themselves. We also agreed that moderation must be handed over to devrel
	or userrel after 2 days.

	Ferris asked some questions:
		1)  Do we have an implementation schedule? ;
		2)  Have we identified some warm bodies for it?;
		3)  Most devrel requests seem really to relate to CoC violations.  Would
		you like us to bounce those to the CoC people, process them using CoC
		rules, or keep doing what we are doing now (generally, close them with a
		note explaining why or mediate them)?  (I'm talking about the "He's
		being rude/sarcastic/disrespectful" sorts of things which really need to
		be processed immediately and merit a warning or brief suspension if
		anything.)

Slacker arches
	See Caleb's post on -dev and subsequent thread
	Calebs post:
	  http://article.gmane.org/gmane.linux.gentoo.devel/53933
	Kumba's comment on mips status:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54168
        Rich0's proposal:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54103


Document of being an active developer
        Araujo raised that he needs some kind of written document of being an
	active developer. Argument being that mentioning in CV in his
	environment is only accepted if there is some kind of proof.
	Our trustee grant deferred it back to council+infra as Foundation only
	handles IP, but suggested it could be some kind of generated document.


=======================================================================

GLEP 54 : Postponed to -dev ML
-------
        Comment from portage maintainer:
	- no statement about compatibility/implementation plans
	- more subjective:
	  - while a distinction between CPV and atom may not be technically
	    required, I might be useful to have
	  - (minor) if the version part is optionl there could be some
	    complications

	So is this something we'd like to have?

        Other ideas that came up during discussion:
        - -scm or _scm ?
	- handling as (-|_pre)9999) versions per definition
	- implement as dynamic package sets

        Related bugs:
	- bug #9202 - Better support for CVS Ebuilds...

	Pushed back to -dev ML as there are too many unresolved questions at
	the moment. peper is given the task to repost it and expand on
	usefulness / use cases as well as compatibility issues.

GLEP 55 : Postponed to -dev ML
-------
        - Agreement on eapi subdirectories are not feasible

	Ideas during discussion:
	- moving from EAPI= to eapi function and using repository bashrc for
	  compatibility

	Pushed back to -dev ML as there are too many unresolved questions at
	the moment.

Slacker arches
--------------
        vapier will work on rich0's suggestion and repost it for discussion on
	-dev ML

Code of Conduct enforcement : 
---------------------------
        Council members agreed on the direction, dberkholz will provide
	additional details on -council ML

Document of being an active developer
-------------------------------------
        Suggested options:
	 - Log in to dev.g.o and automatically generate there signed by
	   infra-maintained key, put userinfo.xml website in the doc as
	   reference.
	 
	 dberkholz and araujo will look into a scribus based template.
	 devrel will have to generate a signing key for these purposes.



1.1                  xml/htdocs/proj/en/council/meeting-logs/20080110.txt

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

Index: 20080110.txt
===================================================================
# Log started, 10.01.2008 21:00 CET

[21:01:22] jokey gives betelgeuse another 3 minutes
[21:02:08] <fmccor> He's active in !c#gentoo-devrel
[21:04:06] <@jokey> well ok, let's start, roll-call 
[21:04:12] <@lu_zero> ok
[21:04:25] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has joined !c#gentoo-council
[21:04:47] <@jokey> amne: ?
[21:05:28] Betelgeuse [n=betelgeu@!hgentoo/developer/Betelgeuse] has joined !c#gentoo-council
[21:05:28] ChanServ [ChanServ@!hservices.] has set mode +o Betelgeuse
[21:05:42] <@jokey> Hi Betelgeuse
[21:05:49] <@amne> oi
[21:05:49] <@jokey> we're just about to start ;)
[21:05:53] <@Betelgeuse> hmm a couple minutes late
[21:06:09] <+musikc> <----  dberkholz's proxy
[21:06:50] <@lu_zero> who's missing?
[21:07:00] <@jokey> all alive :)
[21:07:22] <@jokey> so, !c#1 is GLEP 54: scm package version suffix
[21:07:33] <@vapier> discussion, not voting
[21:07:51] <@lu_zero> who is going to start?
[21:07:58] ferdy [n=ferdy@!hgentoo/developer/ferdy] has joined !c#gentoo-council
[21:08:17] <@jokey> first of all, everyone read it, right?
[21:08:30] <@vapier> i dont think roll-call finished ;)
[21:08:49] <@vapier> FlameBook = ?
[21:09:02] <welp> Flameeyes
[21:09:07] <@FlameBook> vapier, I'm here, I'd just be lesser profile than usual (because of a cold0
[21:09:12] <welp> oh
[21:09:24] welp thought vapier didn't know who FlameBook was
[21:10:36] <@Betelgeuse> Well the GLEP is not in a hurry as it needss a new Portage version.
[21:10:40] <genone> if I may say somehing about it
[21:10:50] <@jokey> sure genone
[21:11:15] <@vapier> input from genone / zmedico / friends surely welcome
[21:12:44] <genone> I have three issues with it: 1) no statement about compability/implementation plans 2) while a distinction between CPV and atom may not be techincally required, I still think it's useful to have 3) (minor) if the version part is optionl there could be some complications
[21:13:26] <genone> 1) is somewhat related to glep55, but also an issue if that would be accepted
[21:14:09] <genone> 3) is mostly my dislike for special cases required by the glep
[21:14:41] <@lu_zero> hmm
[21:14:51] <genone> (haven't brought those up on the ML as they would just have resulted in other endless threads)
[21:16:46] <@jokey> I'm with genone on 1) at least
[21:17:00] <peper> genone: pkg-1a PN-PV or PN?
[21:17:21] <genone> peper: former
[21:17:50] <@vapier> anyone know the bug !c# for the original request for a "cvs" version string ?
[21:17:57] <@lu_zero> hmm btw in what it differs than the -cvs?
[21:18:11] <peper> genone: why?
[21:18:13] <@jokey> backwards compatibility is certainly important as people may start with 2007.0 stages and then face that problem as a sidenote
[21:18:20] <peper> genone: pkg-1a is a valid package name
[21:19:24] <@Betelgeuse> Well IMHO we should first decide whether we think the idea itself is something we want to have.
[21:19:42] <@Betelgeuse> If we are against the idea then there is no point in disgussing the technical details.
[21:19:42] <igli> it's also a valid PF
[21:20:02] <genone> vapier: http://bugs.gentoo.org/show_bug.cgi?id=9202
[21:20:16] <peper> igli: that's the point
[21:20:33] <@vapier> Betelgeuse: i think the concept has been long outstanding
[21:20:41] <@amne> Betelgeuse: also define what the idea is. i) having some support for SCM ebuilds (good idea imho) ii) doing it via changing the naming scheme
[21:21:00] <@vapier> i started using -9999 because Bug 9202 was outstanding
[21:21:05] <jeeves> vapier: https://bugs.gentoo.org/9202 enh, P2, x86, sbc28@×××××××.edu->dev-portage@g.o, RESOLVED, DUPLICATE, Better support for CVS Ebuilds...
[21:21:15] <@jokey> amne: idea behind is obvious imho
[21:21:21] <@lu_zero> vapier still I see some problems in the idea of usage
[21:21:34] <@vapier> i'm trying to see why "-scm" (which would require quite a bit of changes everywhere) is better than "_scm" (which would be trivial to drop in everywhere)
[21:22:02] <@lu_zero> since -9999 ebuild should stay p.masked
[21:22:02] <peper> b/c scm is different than other suffixes we have
[21:22:22] <igli> peper: so as a random string it matches PF regex; hence it's parsed as PF with no context. what's your point?
[21:22:36] <@amne> http://bugs.gentoo.org/show_bug.cgi?id=9202
[21:22:38] <@amne> oops
[21:22:46] <@amne> sorry, copy and paste error
[21:22:59] <@FlameBook> vapier, I sincerely find myself comfortable with -9999 and x.y.9999 versioning too, needing no extra support...
[21:23:06] <@jokey> peper: I don't agree that it's any different from CPV pov
[21:23:43] <@jokey> FlameBook: the idea is to follow _pre versions and just make it scm aware (so you get the next stable release without any major work)
[21:24:01] <genone> to make it clear: I don't have a problem with the idea itself (portage already has a similar, though unused extension), I'm just not completely comfortable with the details
[21:24:17] <@FlameBook> jokey, see amarok: 1.4.9999 will follow any 1.4.9_preXXXXX version
[21:24:27] <peper> igli: I think you are confused...
[21:24:53] <igli> *plunk* not any more
[21:24:57] <@FlameBook> 2.9999 will build the amarok-2 branch as soon as it's in a state that users might want to look at :P
[21:24:59] <genone> peper: just tested, foo-1a isn't a valid package name
[21:25:15] <@jokey> FlameBook: but when 2.0 comes out then, you won't notice it
[21:25:22] <peper> how did you test that?
[21:25:44] <@FlameBook> jokey, hm? if one is using live svn it shouldn't notice if a new version comes up, no?
[21:25:50] <genone> created a matching ebuild and called emerge with it as argument
[21:26:00] <@lu_zero> FlameBook another issue about usage
[21:26:08] <@lu_zero> something not covered by this glep
[21:26:11] <peper> well, portage accepts '*' as a pkgname, is it valid then?
[21:26:33] <genone> peper: huh?
[21:26:46] FlameBook just can't find any good reason at the moment for switching from -9999/.9999 to something different
[21:27:25] <peper> 9999 is a dirty hack, for one
[21:27:34] <genone> FlameBook: there are some _potential_ benefits outside ordering, like implicit masking
[21:27:43] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has joined !c#gentoo-council
[21:27:45] <genone> or grouping
[21:28:06] <@jokey> plus having scm functions available from pkg manager
[21:28:14] <@jokey> so the eclass hacks can disappear
[21:28:27] <@lu_zero> jokey eclass hacks got just moved
[21:28:29] <@lu_zero> at best
[21:28:34] <@vapier> genone: your opinion on -scm vs _scm ?
[21:28:55] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has joined !c#gentoo-council
[21:29:39] <@FlameBook> genone, I find explicit masking better, actually
[21:29:45] <genone> vapier: if it's used for more than ordering (likely), -scm seems better to me
[21:30:56] <genone> FlameBook: everyone has his preferences ;)
[21:31:29] <@FlameBook> jokey, so you'd have to have a package manager to support all kind of scm? cvs, svn, bzr, git, hg, darcs?
[21:31:30] <@lu_zero> I find implicit masking wrong
[21:31:47] <@lu_zero> you forgot monotone and perforce
[21:31:53] <@FlameBook> what about dependencies? would the ebuild have to depend on the correct client package?
[21:31:55] <@vapier> monotone is irrelevant
[21:32:03] <@lu_zero> vapier pidgin
[21:32:06] <genone> lu_zero: was just an idea what could be done with a special tag
[21:32:09] <@lu_zero> sadly
[21:32:18] <@jokey> FlameBook: yep, given that including layman is something feasible, it would be needed eitherway, you can avoid code duplication
[21:32:22] <@vapier> still irrelevant, mt is terrible
[21:32:34] <@FlameBook> because if the ebuild have to do that by hand... then it would be quite a mess imho
[21:32:35] <@lu_zero> vapier I know
[21:32:38] hydrogen [n=hydrogen@!hc-75-68-137-232.hsd1.nh.comcast.net] has joined !c#gentoo-council
[21:32:49] <@FlameBook> having part of the code laying on the package manager side and partly on the ebuild/eclasses
[21:33:08] <@vapier> can we envision any other possible uses ?  extending the version syntax isnt trivial, so doing it one off for scm's when it isnt usable by anything else ...
[21:34:08] <@jokey> I don't see something else than scm atm
[21:34:14] <igli> which these benefits are not available with existing -cvs[0-9]* ?
[21:34:17] <igli> of^
[21:34:34] <@Betelgeuse> periodic reinstall but that could probably be done with 9999 too
[21:35:06] <igli> ty
[21:35:27] <@vapier> except for the projects that actually use 9999 in their version ;)
[21:35:45] <@Betelgeuse> vapier: yeah
[21:35:48] <@FlameBook> Betelgeuse, as far as I can understand it, if you have package set you can easily take care of periodic reinstall without having to add extra support to the package manager
[21:35:59] <@jokey> well if we agree on using that version(part) for live ebuilds, even that can be done
[21:36:17] <+musikc> fwiw, this proxy's stance on the topic is neutral
[21:36:20] p-y [n=p-y@!hgentoo/developer/p-y] has joined !c#gentoo-council
[21:36:46] <genone> FlameBook: the nice thing would be that we could create a dyamic package set containing all -scm installs, rather than each user having to maintain a static list
[21:37:07] <@FlameBook> genone, and that can't be achieved in any other way?
[21:37:42] <peper> what's the scm version of pkg which currently has version '20060621' in your 999 syntax?
[21:37:43] <@FlameBook> what about a possible AUTO_PACKAGE_SETS variable in ebuilds? (so one could also have a "xorg-drivers" dynamic package set, or a "gstreamer-plugins" package set, ...)
[21:37:45] <genone> FlameBook: well, we'd somehow have to identify such installs, the version tag is an easy and reliable way, but not the only one
[21:38:40] <genone> well, package sets as implemented in portage are extremely flexible, just need the data
[21:38:47] <@lu_zero> <peper> what's the scm version of pkg which currently has version '20060621'
[21:38:47] <@lu_zero>           in your 999 syntax?
[21:38:59] <@lu_zero> what do you mean?
[21:39:03] <@vapier> FlameBook: pretty much everything could be done if we codified the meaning of "9999", but arbitrarily reserving a number is wrong and can lead to false positives
[21:39:09] <peper> I mean that 9999 is a hack
[21:39:14] <peper> which need to die
[21:39:16] <@vapier> sticking scm in there conversely leads to no false positives
[21:39:17] <@FlameBook> 99999999 probably, looks nasty, but works
[21:39:42] <@Betelgeuse> vapier: yeah
[21:39:43] <@FlameBook> peper, might be an hack, but I don't see any good reason to change the versioning spec just to kill off that hack
[21:39:43] <peper> so you match any number of nines as scm?
[21:39:54] <peper> or just between 4 and 8?
[21:40:14] windzor [n=windzor@!h84.238.69.216] has joined !c#gentoo-council
[21:40:20] <@FlameBook> vapier, I meant declaring inside the ebuild that the package has to be added to the scm dynamic set
[21:40:42] <@FlameBook> peper, I don't see any reason _why_ there should be a way to identify the scm packages from an automatic perspective at the moment
[21:41:01] <@FlameBook> ordering, I find 9999 still working decently, automatic package sets, there are other solutions
[21:41:25] <@FlameBook> as for different scm software, it would be _quite_ a mess to support every and all scm systems from a package manager..
[21:41:28] <@lu_zero> I still don't see why live ebuilds should be expanded since it has such limited usage
[21:41:36] <@lu_zero> and the usage should remain as is
[21:41:36] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has joined !c#gentoo-council
[21:42:48] jakub notes that -scm is much more likely to match something existant than -9999 and moves on...
[21:43:26] <peper> FlameBook: support every scm system? what?
[21:43:33] DrEeevil [i=dreeevil@!hgentoo/user/bonsaikitten] has joined !c#gentoo-council
[21:43:42] <jakub> IOW, foo-scm is $PN-$PV or $PN?
[21:43:49] <peper> there are eclasses for that
[21:43:52] <@FlameBook> maybe give a complete list of all the things you can have implemented by transitioning to -scm, indicating which ones can't be achieved in any other way.. then I might find something that makes me think that changing the versioning spec is worth the play
[21:44:00] <@FlameBook> peper, so okay not even eclasses cease to exists, as jokey hoped
[21:44:23] <@FlameBook> which comes back to my previous point: what can -scm do that we can't do already or in a different way that does not require changing the version spec?
[21:44:43] <peper> why are you so concerned about changing the version spec?
[21:44:50] <ferdy> false positives and not looking like a hack
[21:44:57] <TFKyle> jakub: think $PN-$PV is the intent
[21:44:58] <peper> we can clean up the mess
[21:44:59] <@FlameBook> ferdy, false positive doing what?
[21:45:04] <@FlameBook> which mess?
[21:45:04] <ferdy> 999999999
[21:45:16] <@FlameBook> ferdy, that's a false positive of what?
[21:45:42] <@vapier> peper: because it breaks everything, takes a while to adjust, and is not reversible
[21:45:49] <jakub> TFKyle: and, how are you going to ensure that? (well sorry for the noise here)
[21:45:54] <ferdy> fine, avoid POTENTIAL false positives
[21:46:05] <@vapier> changing the version spec is not trivial and should never be taken lightly
[21:46:07] <@FlameBook> ferdy, potential false positive doing _what_, that's what I'm asking for a while now
[21:46:30] <@lu_zero> avoid non existent, unlikely false positive, that could lead to unmentioned results
[21:46:31] <ferdy> making the package manager know it is dealing with a 'live' package
[21:46:39] <@lu_zero> ferdy undefined
[21:46:41] <@FlameBook> as vapier said, it's not something to take lightly, so if it's just for the sake to look "nicer", I wouldn't like that
[21:46:49] <ferdy> lu_zero: what's undefined?
[21:46:55] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
[21:46:55] <@FlameBook> ferdy, and why should the package know that?
[21:47:00] <@lu_zero> what is the suggested behaviour
[21:47:05] <@FlameBook> the best thing that came up till now is genone's dynamic package set
[21:47:19] <peper> actually, it's pretty easy together with GLEP 55
[21:47:21] <ferdy> FlameBook: to allow other stuff like 'only build if there are changes in the underlying repo'
[21:47:22] <@FlameBook> which as I said can be implemented in a different way, and become an even more interesting idea per-se
[21:47:42] <@lu_zero> ferdy how you plan to implement that?
[21:47:44] <@FlameBook> ferdy, how can the package manager know about changes in underlying repository if the fetching is done by an eclass?
[21:47:51] <jakub> ferdy: you can detect repo changes via SCM tools... not via p.manager
[21:47:53] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has joined !c#gentoo-council
[21:47:57] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[21:48:00] <@FlameBook> should it tar everything up and run an md5?
[21:48:15] <ferdy> no, you can ask eclasses to comply to some 'protocol' like "return blah from function bleh if there are no changes"
[21:48:26] <ferdy> that'd be the first hack that comes to mind
[21:48:26] <@lu_zero> ferdy the glep fails to deliver those details
[21:48:27] <eroyf> haha.
[21:48:34] <@FlameBook> what lu_zero just said
[21:48:41] <@FlameBook> ferdy, oh so we exchange an hack for an hack?
[21:48:45] <@lu_zero> and you stressed already that the main point is avoid hacks
[21:48:57] <ferdy> who said we should implement that hack ?
[21:49:12] <@lu_zero> ferdy what's written in the glep-54?
[21:49:14] <ferdy> and no, the GLEP shouldn't address this kind of stuff
[21:49:27] <@FlameBook> okay so the idea of just rebuilding stuff if repository has changed can't be implemented
[21:49:34] jakub finds using $scm native tool a _lot_ more reliable for detecting when something should be re-compiled than some -scm or whatnot suffix
[21:49:46] <@FlameBook> we're back to the only interesting thing being genone's dynamic package sets
[21:50:13] <@lu_zero> that can be implemented in quite a range of different ways
[21:50:38] <@FlameBook> lu_zero, I would like having that with a variable inside the ebuild
[21:50:49] <@FlameBook> so that we could have dynamic sets for plugin packages
[21:50:53] jensp [n=jens@!hunaffiliated/jensp] has joined !c#gentoo-council
[21:51:05] <@jokey> but even with dynamic sets, portage needs to have a safe skip package option then
[21:51:08] <@FlameBook> if we still had xmms in the tree, it would be nice to have a dynamic "xmms-plugins" package set )
[21:51:09] <@FlameBook> :)
[21:51:14] <@jokey> if there are no changes, go on
[21:51:36] <@FlameBook> jokey, which can't be implemented with the scm fetching implemented in eclass
[21:51:45] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
[21:51:46] <@lu_zero> still all those discussions are missing my original question
[21:51:48] <@FlameBook> and again brings us up to something different from what peper proposed till now
[21:52:04] rangerpb [n=baude@!hgentoo/developer/rangerpb] has joined !c#gentoo-council
[21:52:07] <@lu_zero> is it really worth the required effort?
[21:52:08] <ferdy> FlameBook: it certainly can, see functions can 'return' values to the PM
[21:52:12] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[21:52:19] <@FlameBook> ferdy, you said it was an hack though
[21:52:36] <ferdy> no, I didn't
[21:53:01] <@FlameBook> and it would mean accepting a change to versioning specs on the basis that it could be possible implementing a feature in the package manager which hasn't been specified at all up to now..
[21:53:12] <@FlameBook> I'd like to see that (maybe make it a different glep) before going on with accepting this glep as it is
[21:53:47] <ferdy> it would mean accepting a change that would make the package manager know that a certain ebuild is a live ebuild
[21:54:09] <@FlameBook> so it would be fine if we accepted a change that makes the package manager know that a certain ebuild is an xmms plugin, too?
[21:54:16] <@FlameBook> at the moment I find the same usefulness between the two
[21:54:22] <@jokey> let's abstract it a bit, it would mean there are special options the package manager can provide
[21:54:24] <@lu_zero> next to 0?
[21:54:25] <@FlameBook> as nothing specifies what the package manager has to do differently for an scm ebuild
[21:54:44] <ferdy> heh, trying to make those things look similar is like pretending the people here are idiots
[21:54:58] ulm [n=ulm@!hgentoo/developer/ulm] has joined !c#gentoo-council
[21:54:59] <@jokey> brings us back to the original question anme asked.. "do we want this"? or maybe even do we need it?
[21:54:59] <@lu_zero> they aren't?
[21:55:20] <@FlameBook> and without knowing what the package manager can do differently for a scm ebuild, I find that the current proposal would mean accepting a change that has no practical value
[21:55:48] <jakub> ferdy: on that note... mythtv-* ebuilds... are those 'live' or not?
[21:55:48] <@FlameBook> jokey, as it stands, no I don't, I'd be happy to think again about this if we can get more information on why should we need this
[21:55:50] <genone> maybe the discussions is a bit too limited by the "scm" part, could be extended to allow tags in general
[21:56:13] <@FlameBook> genone, couldn't the tag be expressed by variables inside the ebuild?
[21:56:19] <ferdy> jakub: don't know a tad about those... do I have to look at them or is it a rethoric question?
[21:56:29] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has joined !c#gentoo-council
[21:56:33] <@FlameBook> [without breaking versioning spec]
[21:56:34] <genone> FlameBook: yes, but those are quite a bit harder to access
[21:56:35] <jakub> ferdy: fetches a fixed rev from a repo
[21:56:41] <ferdy> jakub: no
[21:57:10] <@FlameBook> genone, but quite a bit simpler to implement, I guess?
[21:57:11] <@jokey> FlameBook: genone +1 here, having to acces the data is not helpful if you want to provide special functions like weekly or whatever rebuild
[21:57:25] <peper> breakage of verioning spec is not a problem if we do GLEP 55
[21:57:38] <@lu_zero> jokey that can be done with cron and custom sets
[21:57:54] <@FlameBook> jokey, if you create dynamic sets based on tags, you don't need to access the ebuilds by hand, no?
[21:57:58] <@lu_zero> peper that hasn't been discussed yet
[21:58:03] <peper> just saying
[21:58:08] <genone> FlameBook: depends
[21:58:14] <@FlameBook> just need to keep the dynamic sets' definitions consistent with the installed packages
[21:58:36] <ferdy> those dynamics sets being something that hasn't been specified, or has it?
[21:58:39] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
[21:59:00] ferringb [n=ferringb@!hc-24-4-204-103.hsd1.ca.comcast.net] has joined !c#gentoo-council
[21:59:14] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[21:59:18] <@lu_zero> wb genone
[21:59:33] <@FlameBook> it hasn't, which brings us again to the point that whatever we're going to accept, it should at least provide some useful use cases
[21:59:48] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Remote closed the connection
[22:00:20] <peper> emerge --reinstall-scm
[22:00:30] <ferdy> heh... so "it can be done with dynamic sets" is pure science fiction
[22:00:48] <jakub> peper: well, _if_ we agree on some convention, the same can be done with -9999
[22:00:49] <@FlameBook> ferdy, it's no more and no less than what you were saying up to now
[22:00:59] <@FlameBook> with the difference that I don't have to convince you to accept dynamic sets
[22:01:11] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[22:01:21] <@FlameBook> while, considering I'm not convinced by -scm at the moment, you're the ones that should be convincing me to accept those
[22:01:23] <ferdy> with the difference that the -scm stuff IS working in a different package manager, so it is not science fiction
[22:01:43] <@FlameBook> [or just decide that you don't want to convince me, and then stop the discussion right here, with my vote being "no"]
[22:02:13] <@lu_zero> ferdy -9999 is working fine with about 2 or 3
[22:02:15] <@FlameBook> ferdy, is working to do what? I asked that already, if you don't intend to answer that, then I suppose I can simply state my vote here to be "no" and move over
[22:02:17] <jakub> ferdy: well, passing qlist -CIv 9999 output works exactly the same w/ portage
[22:02:18] <@lu_zero> so it's pointless
[22:02:50] <peper> jakub: why not 99999?
[22:03:06] <ferdy> FlameBook: periodic reinstalling done right, I thought it had been said already
[22:03:31] <@jokey> peper: as stated in the glep, 9999 has become common sense
[22:03:31] <@lu_zero> ferdy cron and fixed sets works as should already
[22:03:35] <ferdy> also... you feel yourself very important... I'm not trying to convince *YOU*, I'm trying to get my facts straight, no need to convince anyone...
[22:03:44] <ferdy> lu_zero: no it doesnt, read up why
[22:04:11] <peper> jokey: there are packages with versions like YYYYMMDD, so rather a common hack
[22:04:12] <ferdy> that doesn't handle a package that has several different scm 'versions' as git does
[22:04:20] <jakub> peper: as said... just agree on some convention (plus, 9999 doesn't require extensive changes everywhere as already noted)
[22:04:32] <@vapier> would i venture to say this needs to move back to the mailing list
[22:04:52] <@vapier> well, i did venture
[22:04:56] <@vapier> would i be correct in ...
[22:05:03] <ferdy> jakub: doesn't work, read what I said
[22:05:21] <jakub> vapier++
[22:05:26] <peper> jakub: like 15 nines to be sure?
[22:05:44] <@jokey> vapier: indeed, as there seems to be too many unresolved ideas atm and undiscussed other options
[22:05:53] <jakub> peper: 9999 doesn't conflict w/ anything I have installed; -scm is much more likely to conflict
[22:06:05] <@vapier> so, peper, repost the glep, and anyone with issues, post them to the list for responses
[22:06:14] <@vapier> if you dont post them, then you cant bring them to the table next time :p
[22:06:15] <ferdy> jakub: again, the 9999 doesn't work, read up why... it is a legit case
[22:06:25] <peper> vapier: alright
[22:06:26] <+musikc> vapier: agreed. lots of discussion on this one still.
[22:06:28] <igli> with existing sol'n, the pm *has* to know it's cvs to order it correctly. iow this is already available as data
[22:06:33] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has quit IRC: Client Quit
[22:06:43] <@lu_zero> ferdy quote yourself I couldn't find the line in /lastlog
[22:06:45] <jakub> ferdy: it worked for me for ages :) well, doesn't belong here really
[22:06:52] <ferringb> peper: expanding the glep to contain the arg against the existing -cvs version would be useful also, please.
[22:07:06] jensp [n=jens@!hunaffiliated/jensp] has left !c#gentoo-council
[22:07:13] <ferdy> jakub: doesn't in the case of git where you need at least two different 'scm' versions
[22:07:17] <peper> ferringb: does it really need more args than nobody using it?
[22:07:27] <@lu_zero> ferdy 2?
[22:07:33] <ferdy> yes, two
[22:07:33] <@lu_zero> as in?
[22:07:41] <genone> peper: well, how many people actually know about it?
[22:07:55] <genone> (but I agree it sucks)
[22:07:56] <ferringb> peper: yes, imo, since the support ought to still be there (can't say for paludis, but pkgcore and portage still have it last I looked)
[22:08:05] <ferdy> lu_zero: also, your dynamic set thing doesn't work because those haven't been defined, so, as I said, it is pure science fiction
[22:08:22] <@lu_zero> ferdy never said dynamic
[22:08:26] <@lu_zero> CURRENT sets
[22:08:31] <ferringb> peper: either way, look at it from the angle of documenting the failing of it if you like- expanding the arg for why it must be finally killed off, and -scm replace it would help ;)
[22:08:39] <@lu_zero> as available in portage and pkgcore
[22:09:06] <ferdy> lu_zero: 2 as in 'master' and 'next' and every master and next from every release cycle
[22:09:21] <ferdy> also, vapier said to repost, so this should move to another topic
[22:09:41] <@jokey> indeed, pushing this back to -dev for discussion
[22:09:49] <@lu_zero> ferdy I still don't understand what you mean
[22:09:56] <@lu_zero> anyway next item
[22:10:04] <@FlameBook> lu_zero, he probably refers to multiple branching
[22:10:15] <@lu_zero> that isn't 2
[22:10:20] <jakub> ferdy: once again... -scm or -9999 is _not_ a reliable indication whether you need to recompile something or not..
[22:10:21] <@FlameBook> [which is what I said before about amarok's 1.4.9999 vs 2.9999]
[22:10:21] <@lu_zero> is $any
[22:10:34] <peper> vapier: do you except me to do any changes or just repost as is?
[22:10:35] <ferdy> jokey: did I say otherwise ?
[22:10:42] <peper> *expect
[22:11:07] <ferdy> lu_zero: I said GIT needs at least 2... really, it is much better if you read my sentences instead of skimming over them
[22:11:19] <@jokey> next topic on agenda would be GLEP 55, can we move on to that?
[22:11:34] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has joined !c#gentoo-council
[22:11:36] <ferdy> sorry not jokey, jakub.
[22:11:47] <+musikc> jokey, seems like we should
[22:12:04] <@jokey> or does anyone want to not push GLEP54 back to dev ML?
[22:12:13] <peper> do you expect me to do any changes or just repost as is?
[22:12:26] <@lu_zero> peper add a section about pm behaviour
[22:12:41] <@lu_zero> and anything else that states its usefulness
[22:13:14] <peper> ok, move on to 55, I want to see what you think about it first
[22:13:31] <TFKyle> jakub: that along with update checking would be, though interface-wise you'd probably have to specify something extra to the pm to check scm repos due to hitting the network
[22:14:25] <@jokey> okay, next topic then... GLEP 55 "This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1)."
[22:14:50] <armin76> poor jokey :)
[22:15:09] <genone> as said on the ML, I'm definitely against it silently expanding the scope of EAPI, also a note aboute compability would be nice IMHO. Other than that I don't really like it, but it's probably the best option if we want to avoid sourcing the ebuild to access EAPI
[22:15:31] <@lu_zero> why sourcing is a problem exactly?
[22:16:03] <peper> genone: hmm, where is scope of EAPI defined that you are talking about expanding?
[22:16:05] <ferringb> genone: unless I'm on crack, it still explicitly requires it due to the post source EAPI angle
[22:16:14] <ferringb> peper: can you confirm that?
[22:16:33] musikc thinks there should be some visible agreement among package manager developers (portage, pkgcore, and paludis) before we go further or even support it
[22:16:58] <peper> for backwards compatibility, yes. but pm doesn't source ebuilds with usupported pre-source eapi
[22:16:59] <@lu_zero> "Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps:"
[22:17:08] <@amne> musikc: good point
[22:17:16] <genone> peper: you very well know that it's not defined formally
[22:17:33] <ferringb> peper: one failing there is that it can miss ebuilds that (post-source) it's able to handle, thus inadvertantly masking stuff
[22:18:01] <ferdy> ferringb: hrm.. how so ?
[22:18:03] <ferringb> peper: that scenario, imo, is enough to raise the question of "why do post source then?"- pardon it wasn't on the ml, but I've been looking for an answer to that
[22:18:21] <peper> ferringb: for backwards compatibilty
[22:18:27] <peper> read the Application part of the glep
[22:18:48] <peper> specification is how pm is supposed to do it to get it right
[22:19:01] <ferringb> ferdy: portage-2.3.ebuild-3 w/ a pm that supports EAPI=(1,2), the portage ebuild has a post-source EAPI=2 w/in it, thus it *is* supported by the pm, but the pre-source serves as a mask
[22:19:26] <@lu_zero> genone, ferringb and peper : why sourcing is a problem?
[22:19:30] <peper> ferringb: and who would make such an ebuild?
[22:19:34] <ferringb> peper: pkg-4.ebuild-2, EAPI=1 is a given example in the glep of this, just assume the manager supports EAPI=1 only; thus it *would* be able to use .ebuild-2, just would miss it
[22:19:38] <@lu_zero> I'd like to have an answer about that first...
[22:19:44] <ferdy> ferringb: I seem to recall the GLEP explicitly prohibiting that
[22:19:52] <ferdy> lu_zero: have you read the discussion ?
[22:20:07] <peper> lu_zero: read Problem section
[22:20:12] <@lu_zero> done
[22:20:12] <ferdy> in the mailing list, I mean. I think it has been covered...
[22:20:14] <ferringb> ferdy: will recheck the glep to see if I was wrong, but the potential (even if it's stupid) was bugging me a fair bit.
[22:20:16] <@lu_zero> nothing said about it
[22:20:29] <@lu_zero> ferdy done, nobody explained that
[22:20:31] <genone> lu_zero: the (potential) problem is that the EAPI might affect how things are sourced, and we can't trap the setting of a variable
[22:20:48] <peper> ferringb: again, post-sourcing is just for backwards compat. devs are not supposed to use both
[22:20:51] <@vapier> considering EAPI is stilled allowed and required to be respected properly in the ebuild, i dont see how this solves anything
[22:21:04] <@vapier> you're still required to handle EAPI in the ebuild if no suffix, so why bother with suffix
[22:21:09] <@jokey> genone: well if per definition the first line sets EAPI, then it shouldn't be an issue in any case, right?
[22:21:26] <ferringb> genone: can trap the setting via adding an eapi function, which can be deployed via a bashrc hack as compatibility w/ managers growing the appropriate func however
[22:21:42] <@vapier> and if the EAPI placement is simply "must come first", then the sourcing problem isnt a big deal
[22:22:16] <genone> ferringb: yes, and I've mentioned that the motivation section is something that needs to be worked on as it currently has no real use cases short of glep54
[22:22:46] <ferringb> genone: 'k; that (admittedly) is something I should've done initially instead of the var approach, although at least the transition to the func wouldn't be that painful
[22:24:12] <ferringb> peper: aside from the addition of -scm to version component, can you add doc out any other complaints beyond what's there for the var approach?
[22:24:34] <@lu_zero> genone putting the eapi tag in a comment like vim/emacs modelines won't give the same effect w/out such change?
[22:24:41] <peper> ferringb: isn't it handled in the other ideas secion?
[22:25:00] <ferringb> (I exempt the -scm one, since that is a general repo versioning issue, same scenario can play out with manifest/digest changes, thus should be solved that way imo)
[22:25:08] <peper> it's neither backwards nor forwards compatible
[22:25:13] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has quit IRC: "Leaving"
[22:25:21] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
[22:25:48] <ferringb> peper: not really imo, I'm looking for specific complaints leveled towards EAPI beyond "functions have to check it in the global scope to see if they support it"- that one is addressable w/ a few tweaks to existing eapi mechanism
[22:26:53] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
[22:27:20] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[22:27:42] <peper> ferringb: and I am looking for technical objections to that GLEP, it solves all the problems nicely, in a backwards and forwards compatible way
[22:27:52] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has joined !c#gentoo-council
[22:27:54] <genone> lu_zero: well, lots of things are possible, I think the ML thread contains some drawbacks for the other solutions but I'd have to check (can't do that now)
[22:28:31] <jmbsvicetto> genone: One question I didn't see a clear answer about was the one about using xml files. Is it a no-no to have eapi set on metadata.xml?
[22:28:39] <ferringb> peper: the scenario of post-source being supported, but pre-source serving as a mask can play out via an eclass setting eapi however btw, so that one still is a valid scenario (it's considered a QA bug under the glep, 'cept I'm willing to bet it'll pop up in overlays)
[22:28:42] <Caster> I liked the idea of eapi string not going at the very end, keeping the suffix constant
[22:29:07] <@Betelgeuse> The sub directories approach would work for that.
[22:29:23] <@Betelgeuse> The performance issue shouldn't really matter as users are using the metadata cache any wya.
[22:29:35] <genone> jmbsvicetto: well, metadata.xml is ... complicated if you only want to target specific versions (and currently portage doesn't use metadata.xml in any way)
[22:29:37] <peper> ferringb: the idea of the GLEP is to get rid of post-source eapi. the specification is for the package managers to get the backwards compatibility right
[22:29:47] <@Betelgeuse> Also would need factual data if there is anything significant any way.
[22:29:52] <ferringb> peper: technical objection to the glep basically comes down to "why punt whats there, when whats there works and can be tweaked to keep working"- I don't claim EAPI will work if the ebuild format shifts away from bash, but EAPI was intended for bash ebuilds only, expected newer formats to do versioning their own way
[22:29:53] <peper> devs are supposed to use pre-source only
[22:30:17] <@FlameBook> Betelgeuse, I would like to hear from infra about that as iirc CVS isn't nice with loads of directories
[22:30:31] <@Betelgeuse> FlameBook: true
[22:30:37] <peper> Betelgeuse: you first look for ebuild, then look at the cache
[22:31:18] <@Betelgeuse> peper: to see if the cache is valid?
[22:31:50] <ferringb> peper: additional thing the glep should doc, exactly what the manager does when it encounters a post-source EAPI it doesn't support cache wise (including regeneration of that entry if the manager sees that entry, and now supports that EAPI)
[22:31:53] <peper> generally, you query cache for stuff, not traverse it
[22:32:02] <genone> the subdir approach is nasty besides the performance issues
[22:32:15] <ferringb> genone: agreed by all, I suspect
[22:32:35] hncaldwell [n=hncaldwe@!hgrey.iitsystems.csupomona.edu] has joined !c#gentoo-council
[22:33:04] <Cardoe> this is all starting to sound like over-design
[22:33:11] <Cardoe> designing for a situation that will never happen
[22:33:15] <Cardoe> KISS
[22:33:52] <jakub> Cardoe++
[22:34:00] <@Betelgeuse> well this hsould be useful for changing how inherit behaves etc
[22:34:03] <peper> you are just not thinking enough
[22:34:05] Ken69267 [n=Ken69267@!hgentoo/contributor/ken69267] has joined !c#gentoo-council
[22:34:15] <peper> yep
[22:34:30] <genone> as I said: the specification section is ok, but the motivation section needs a huge workover
[22:34:38] <@lu_zero> Betelgeuse must it be changed?
[22:34:55] <@Betelgeuse> lu_zero:  it was just an example of what this enables
[22:35:07] <ferringb> peper: question for you; did you look at converting EAPI=N to eapi N, ie, forcing a func so the manager sourcing can bail at that point if unsupported; either way, I'd suggest expanding the glep to counter-arg that one since it's a solution to the inherit problem
[22:35:59] <peper> for one, it's not backwards compatible
[22:36:18] <@Betelgeuse> peper: well we would just have agree on profile.bashrc
[22:36:18] <ferringb> peper: via bashrc stuck into the repo, it is
[22:36:26] <ferringb> interim compatibility func basically
[22:36:47] <genone> ferringb: paludis doesn't use profile.bashrc according to ciaranm
[22:36:58] <@Betelgeuse> genone: yeah I think so too
[22:37:14] <@Betelgeuse> There is lots of Portage specific hacks in profile.bashrc atm
[22:37:14] <genone> not that I care ...
[22:37:23] <ferringb> without the func, the ebuild gets sourced fully, and the manager sees the unsupported EAPI at the end of sourcing, does the usual thing (probably with a few errors spat during it); with the func, the manager bails at the first imperative sign of an unsupported eapi, thus bypassing any visibile errors.
[22:37:25] <@Betelgeuse> but they could be put under some conditional
[22:37:33] <Caster> we don't need back compatibility for paludis at this point
[22:38:13] <ferringb> peper: so... imo, it's backwards compatible- sorry to spring it on you during this meeting rather then ML prior also ;)
[22:39:15] <peper> it doesn't allow to change the versioning spec and I see it useful
[22:39:26] <Caster> can newer portage easily ignore the eapi in bashrc then?
[22:39:52] <@lu_zero> peper versioning spec changes aren't being approved
[22:39:57] <@lu_zero> don't be circular
[22:40:03] <ferringb> peper: versioning spec is a repo level compatibility issue imo, although you could argue other wise; again, I'd try to get that one doc'd out also, cause I know genone (and myself in this case) both via it as not the ebuild formats versioning responsibility
[22:40:16] <ferringb> s:via it:view it:, pardon
[22:40:34] <genone> peper: question: is glep54 the main (only?) motivation for glep55 for you?
[22:40:50] <peper> no, it's a coincidence
[22:41:55] <@jokey> can you give some real world examples, where this pre-source information is needed then?
[22:43:10] <@jokey> as inherit-behavior-change is possible without it
[22:43:33] <@vapier> so is there a reason we cant just force EAPI as the first line in an ebuild ?
[22:43:38] <@vapier> is there some limitation i'm not aware of ?
[22:43:52] <peper> vapier: backwards compatibility for one
[22:43:53] <Philantrop> jokey: The PM will never have to read *any* content that might potentially cause it to die horribly because of EAPI issues. It sees a pre-source EAPI spec that it isn't compatible with and thus simply won't touch it and consequently avoid any potential problems easily.
[22:44:06] <@vapier> peper: not really
[22:44:17] <@vapier> and certainly *a ton less so* than changing the naming spec
[22:44:25] <@jokey> Philantrop: still I want a real world example that breaks the sourcing that horrible
[22:45:00] <@lu_zero> Philantrop having all non ebuilds in a package dir would break in a more spectacular way
[22:45:44] <Philantrop> jokey: We don't have it yet so that's a bit hard. :-) It's something that opens the door for easier development in the future and improved transitions from one EAPI version to the next.
[22:45:48] <@lu_zero> and I'm not sure about how manifests should be generated
[22:45:58] <ferringb> Philantrop: that is achievable via the tweak adding an eapi func also; what we're talking about here re: "die horribly" is moreso "fail the sourcing, noting the EAPI and spitting noise at the user" also :)
[22:46:50] <@vapier> Philantrop: claiming it'll happen in the future, just not now, isnt really an example
[22:46:54] <Philantrop> ferringb: I'm not sure I understand you. You refer to users being confused by the output?
[22:46:59] windzor [n=windzor@!h84.238.69.216] has quit IRC: Remote closed the connection
[22:47:03] <@vapier> it's also a good argument for delaying the change until needed for real
[22:47:17] <@vapier> instead of engineering for something that may not occur
[22:47:52] <@jokey> vapier: exactly my point :)
[22:48:03] <ferringb> Philantrop: no, what I'm saying is that a sane manager checks EAPI on the way out, as part of the metadata generation process.  if the EAPI is unsupported, and the new eapi added some global functions, *worst* you see is some screwed up metadata and errors spat to the users term on sourcing
[22:48:18] <ferringb> Philantrop: it doesn't kill the manager (or shouldn't, if the manager is implemented sanely imo), it just is slightly ugly
[22:48:38] <Philantrop> vapier, jokey: Why should we always operate *reactively*?
[22:48:45] <ferringb> Philantrop: introducing an eapi func (which can be transitioned to via profile.bashrc) eliminates the inherit arg, and eliminates the potential for bash complaints to be spat during sourcing
[22:49:13] <Cardoe> vapier: exactly what I meant by my previous comments
[22:49:13] <@jokey> Philantrop: because acting proactive without a real value (you can't even come up with a potential example) doesn't make sense
[22:49:17] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
[22:49:35] <Cardoe> if we over-design and work on engineering something that MIGHT happen, but never happens
[22:50:04] <Cardoe> rather then engineering a logically extensible method (what EAPI itself provides), that can be in the future changed as things necessitate.
[22:50:09] <Philantrop> ferringb: I see what you mean now but I can't say much more than that what was said on the -dev ml already. And so I go back to lurking here.
[22:50:27] <@vapier> plus, this doesnt really address what started it all ... allowing eclasses to use a different EAPI from an ebuild
[22:50:31] p-y [n=p-y@!hgentoo/developer/p-y] has quit IRC: Read error: 110 (Connection timed out)
[22:50:45] <Cardoe> vapier: right. that was the whole point that spawned this whole thing.
[22:50:58] <genone> vapier: well, that's simply not possibly, no matter how you define EAPI
[22:51:00] <Cardoe> vapier: instead we've added about 12 steps of complexity and didn't even solve the original thing.
[22:51:07] <peper> eclasses can't define EAPI
[22:51:14] <@vapier> why not ?
[22:51:23] <@vapier> why cant we segment things logically
[22:51:39] <genone> vapier: which EAPI is effective: the calling env or the definition env?
[22:51:53] <@vapier> genone: segment things logically
[22:51:53] <ferringb> genone: could you rephrase the question please (didn't get the meaning there)
[22:52:02] <peper> vapier: what do you mean?
[22:52:08] <@vapier> eclasses are not affected by the ebuild at all
[22:52:18] <@FlameBook> considering we have two other points on today's list, do we want to take a decision on this, postpone it, or what?
[22:52:22] <@vapier> eclasses can use different EAPIs independently from the ebuild
[22:52:37] <ferringb> vapier: not true, imo
[22:52:49] <@vapier> might as well push it back to the list
[22:52:59] <ferringb> vapier: eapi is a definition of the env (vars, funcs), switching the env dependant on ebuild/eclass context isn't viable imo
[22:53:03] <genone> ferringb: see http://article.gmane.org/gmane.linux.gentoo.devel/53354
[22:53:21] <peper> I think you meant vapier
[22:53:23] <@vapier> ferringb: having one env force/imply restrictions on the other is bad
[22:53:51] <Cardoe> vapier: it also brings up the point that eclasses are abused and enibbles or elibs need to be available.
[22:53:55] <@vapier> it means all consumers of an eclass need to worry about the eclass which sort of defeats the purpose of the eclass -- not having to worry about its contents
[22:54:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has quit IRC: "Leaving"
[22:54:15] <genone> vapier: http://article.gmane.org/gmane.linux.gentoo.devel/53354 <- answer those questions please if you want different EAPIs
[22:54:37] <ferringb> vapier: agree with you in principle, disagree on implementing it however ;)
[22:54:51] <@vapier> i'm not trying to imply the implementation is trivial
[22:55:05] <genone> i's a conceptual problem
[22:55:08] <@vapier> regardless, back to the list and us on to the next item
[22:55:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has joined !c#gentoo-council
[22:55:50] <@jokey> with vapier here, should be postponed to next meeting
[22:56:00] <@vapier> no
[22:56:12] <@vapier> pushed to the list until resolved, and then back to the council
[22:56:24] <@FlameBook> so it's a "rejected in this state"?
[22:56:52] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has joined !c#gentoo-council
[22:56:53] rangerpb [n=baude@!hgentoo/developer/rangerpb] has quit IRC: "Leaving"
[22:57:11] aballier [n=alexis@!hgentoo/developer/aballier] has joined !c#gentoo-council
[22:57:30] <@vapier> FlameBook: there was no voting involved, thus no rejection
[22:57:43] <+musikc> needs further discussion
[22:57:44] <@vapier> we were merely discussing the GLEPs, no request for voting
[22:58:22] <@dberkholz> fwiw, i'm back but catching up on backlog
[22:58:24] <@FlameBook> okay, let's go to "need further discussion" as musikc said then
[22:58:48] <@FlameBook> dberkholz, that is perfect as we're moving to CoC :)
[22:58:54] <+musikc> hehe
[22:58:55] <@jokey> timing++ ;)
[22:58:56] <peper> I am going to repost the GLEPs as is and hope you guys ask your questions there
[22:59:33] <Caster> peper: as is? so no argument for why eapi() function can't help?
[22:59:36] <@SpanKY> ive lost the agenda URI from my scrollback
[22:59:44] <@jokey> SpanKY: see topic
[22:59:44] <@FlameBook> SpanKY, http://dev.gentoo.org/~dberkholz/20080110_summary.txt
[22:59:55] <@vapier> well that'd be too obvious
[23:00:01] <@dberkholz> vapier: /topic
[23:00:03] <@jokey> FlameBook: I grabbed it from dberkholz and completed it
[23:00:15] <@FlameBook> jokey, ah I didn't even see it in the topic
[23:00:48] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has quit IRC: Client Quit
[23:01:22] <peper> Caster: oh ok. I will add this one
[23:01:32] <@dberkholz> i'm caught up to the first hour, another hour of backlog to go
[23:01:43] <@lu_zero> ^^;
[23:02:22] <@jokey> so pushing back to -dev is agreed on ? then we can move over to CoC discussion
[23:03:04] <peper> jokey: the subjective part of the summary in GLEP 54 is wrong
[23:03:36] <ferringb> peper: if you want me to give the eapi() a read over (since I'll be commenting on it either way), email me and I'll try to get back to you w/in the day
[23:03:38] <@jokey> right, missing inherit breakage, adding that
[23:03:50] <@jokey> done
[23:03:58] <peper> as there is no way to distinguish between pkg_name and pkg_name-version on its own/, but it's not necessary anyway
[23:04:10] <peper> jokey: I meant GLEP 54
[23:04:33] <peper> the subjective part is just wrong, I thought it was established
[23:05:43] <@jokey> well as it will have a log attached either way, I'm removing that line altogether
[23:05:52] <@jokey> you're right, it's a bit subjective
[23:06:19] <peper> no, it's not true
[23:06:25] <peper> as there is no way to do it currently
[23:06:38] fmccor thought he knew how to run long meetings. :)
[23:07:00] <@jokey> anyway, pushed back to -dev ML
[23:07:07] <peper> right
[23:07:47] <@lu_zero> peper do what?
[23:07:58] <@jokey> so ladies and gentlemen, let's move over to CoC now
[23:08:03] <@lu_zero> ok
[23:08:24] <peper> lu_zero: tell whether a string is a pkg or pkg-ver
[23:08:42] FlameBook is probably going with "whatever donnie says" :P
[23:09:47] <@lu_zero> dberkholz are you ready?
[23:09:58] <@dberkholz> i'm at 20 minutes ago, so almost
[23:10:02] <genone> peper: it is possible, your example didn't work out, also see bug !c#174536
[23:10:05] <jeeves> genone: https://bugs.gentoo.org/174536 min, P2, All, degrenier@×××××××××××.fr->pms-bugs@g.o, NEW, pending, "Package names" spec not restrictive enough
[23:10:26] <@vapier> done people, moving on
[23:10:38] <@vapier> dont make us go +m on j00
[23:10:52] <@dberkholz> feel free to skip to slacker arches and come back to CoC in a bit
[23:11:07] genone just dislikes misinformation
[23:11:15] <@dberkholz> not really sure there's anything to discuss on the slacker point, though.
[23:11:24] <@vapier> how so ?
[23:11:35] <@vapier> or rather, we jumping to slacker first ?
[23:12:26] <@dberkholz> that's my suggestion, yeah.
[23:12:45] <@dberkholz> hopefully it will go faster, and then people uninterested in the CoC can leave
[23:12:52] <@FlameBook> kumba's mail was quite reasonable, so I don't think there's much to discuss, I suppose it could work out by just leaving the options of devs asking de-keywording on ebuild basis
[23:13:20] <@Betelgeuse> as long as there is someone to ask
[23:13:20] <@vapier> except that didnt really work out
[23:13:29] <@vapier> there was no response
[23:13:34] <jakub> FlameBook: is there someone going to respond to those mails? wasn't my experience so far....
[23:13:51] <jakub> even when remove keyword was explicitely and repeatedly requested
[23:14:08] <@vapier> i think what Richard posted is a pretty reasonable
[23:14:12] <@vapier> http://article.gmane.org/gmane.linux.gentoo.devel/54103
[23:14:13] <@FlameBook> jakub, well, kumba answered to gentoo-dev... I don't think we should _force_ it now
[23:14:41] <@vapier> perhaps extend the dates to give more leeway to arches, but there has to be a cut off point
[23:14:44] <jakub> FlameBook: I'm totally fine w/ that if you are going to create a working way to do it :)
[23:14:52] <@vapier> otherwise maintainers who get tired of waiting will eventually do it
[23:14:55] <@vapier> and then the arches get pissed
[23:15:00] <@vapier> yell and point at policy
[23:15:05] <@vapier> and it's the maintainer getting screwed
[23:15:09] <jakub> nod
[23:15:09] <@vapier> when in reality that isnt right
[23:15:36] <ferdy> I'd like you to consider what I posted to that same thread: http://mid.gmane.org/20080109121309.GA14454@××××××.org
[23:15:57] <jakub> vapier: maybe more flexible, but still needs some hard deadlines so that it doesn't become useless
[23:16:00] <@vapier> the only responses i saw from you were "no"
[23:16:57] <jakub> ferdy: wrt the maintainer question you've posted there... it is different, you can retire a maitainer, noone ever retired an arch yet
[23:17:05] <@jokey> what about we do some "% packages stabled, % packages behind requests for time X -> transition to ~arch"
[23:17:19] <ferdy> jakub: retiring a maintainer doesn't solve the issue...
[23:17:34] <jakub> ferdy: sure it doesn't, but it
[23:17:43] <jakub> 's still lot better than ignoring inactive people
[23:17:43] <@FlameBook> vapier, well, I actually like Richard's proposal
[23:18:08] <@vapier> ferdy: with arches, you're forcing maintainers to sit on things indefinitely with no reaction, which quickly chains to large !c# of affected packages
[23:18:09] <jakub> ferdy: someone can take over the package once the slacking maintainer has retired...
[23:18:16] <@vapier> with a maintainer slacking, the issue is isolated to one package
[23:18:31] <jakub> and what vapier said, yeah
[23:18:31] <@vapier> you can trivially cull a package, you cant trivially cull an arch
[23:18:34] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has quit IRC: Read error: 110 (Connection timed out)
[23:18:39] <jakub> ain't the same situation
[23:18:50] <@vapier> and you can transition arches to a state that keeps maintainers happy
[23:19:14] <ferdy> vapier: in that particular bug I posted. I would suffer from the same 'maintenance burden'.... should I, for instance, add blockers
[23:19:18] <@amne> just a quick thought before this gets more into detail, do we want to address just this one situation or come up with a general policy for all possible times an issue like this comes up?
[23:19:26] <jakub> seriously, why's mips so much objecting to becoming ~arch/indev? would shut up the maintainers mostly
[23:19:43] <@vapier> no one who matters is objecting
[23:19:43] <ferdy> please note that I personally deny that maintenance burden existing, but I think it is the very same situation
[23:19:57] <@dberkholz> jakub: no active mips developer (kumba or redhatter) has objected to that
[23:20:00] <@vapier> take that thread, cull the irrelevant, and you have a few e-mails to read
[23:20:07] <@vapier> ferdy: how would you suffer ?
[23:20:12] <@vapier> i honestly dont see it
[23:20:18] <@vapier> please 2 elaborate
[23:20:21] <jakub> dberkholz: well sorry then, that's what I've always heard from the folks until now :)
[23:20:36] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has quit IRC: Read error: 110 (Connection timed out)
[23:20:39] <ferdy> I don't see it either.... but leaving versions in the tree forever is said to cause maintenance burden
[23:20:54] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
[23:20:55] <ferdy> which is one of the arguments in favour of "killing the mips team altogether!!!!one"
[23:20:56] <@vapier> ferdy: i'm talking about why you think 181275 is relevant
[23:20:59] <Cardoe> jakub: just ignore non-Gentoo developers e-mails and read official Gentoo dev e-mails and you'll see that the Gentoo devs agree with it
[23:21:16] <jakub> ferdy: sure it is... repoman commit breaks when you want to punt obsolete broken junk... etc. etc.
[23:21:16] <@vapier> ferdy: there will be no killing of mips
[23:21:42] <@vapier> there will most likely be ~arching of mips which is very different from killing
[23:21:43] <ferdy> vapier: I have to leave older versions around until that issue is solved
[23:22:09] <@vapier> ferdy: you need to leave old versions of git in the tree until uClibc is fixed ?
[23:22:14] <@vapier> i dont think so, remove the old versions
[23:22:28] <jakub> ferdy: you are wasting time on investigating which broken cruft can't be removed just b/c noone responded on a bug for years... now imagine major package redesigns, becomes a huge PIT
[23:22:28] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[23:22:38] <@vapier> jakub: please shush
[23:22:48] <jakub> sure ;)
[23:23:33] <ferdy> vapier: imagine it'd hold stabilization of newer versions.... it is not ONLY arch teams that can cause that 'problem', which is why I wanted the discussion to be more general
[23:24:03] <@vapier> ferdy: ive been telling people not to cater specifically to uClibc when it is a burden on them and the problem lies in uClibc
[23:24:17] <ferdy> yeah, forget uClibc for now
[23:24:21] <@vapier> sure
[23:24:33] <@vapier> can you propose other examples ?
[23:24:50] <@vapier> the only ones i can come up with are keeping old things around to support broken things
[23:24:56] <@vapier> and the answer is to fix or cull the broken things
[23:25:35] <@vapier> the only thing that has come up on the mailing list is arches holding it back
[23:25:49] <@vapier> so if you can show other general issues, i'd be happy to extend the proposal
[23:26:15] <@vapier> as it is, i'd be looking for probably 2x the time frames Richard put forth
[23:26:20] <@vapier> [ http://article.gmane.org/gmane.linux.gentoo.devel/54103 ]
[23:26:48] <@vapier> as you say, this is a volunteer basis, and people can easily get tied up
[23:27:15] <@dberkholz> 2 and 4 months, instead?
[23:27:26] <@dberkholz> 4 months is an awfully long time to wait
[23:27:57] <ferdy> vapier: I can't really give you more *examples* now (I think the reasoning is still valid), feel free to ignore it.
[23:28:09] <@vapier> ferdy: i dont intend for us to decide today on the issue
[23:28:32] <@vapier> i want us to put forth the recommendation to the list and the understanding is we'd decide next meeting
[23:28:36] <@vapier> i think that's reasonable ?
[23:28:47] <@Betelgeuse> sure
[23:29:13] <@dberkholz> i don't think i'd quite go 2x, but i could see a sort of 1.5-ish
[23:29:24] <@vapier> dberkholz: it is and it isnt ... maybe it's me, but i see a month shoot by in Gentoo world and not even realize it
[23:29:26] <@dberkholz> 3 months doesn't feel quite as forever
[23:29:27] <@Betelgeuse> The proposal should probably say something about reserve deps
[23:29:47] <@dberkholz> vapier: guess that depends on whether it's a month waiting for someone else to do something you care about. =)
[23:29:59] <ferdy> vapier: sure, it is reasonable
[23:30:08] <@vapier> i would make it dependent on the profile
[23:30:22] <@vapier> if the profile is set to "stable", then the reserve deps would need to be fixed
[23:30:35] <@vapier> but if it's set to "dev"+, then let it break
[23:31:00] <@dberkholz> it shouldn't be difficult to come up with some sort of scripts/tools to deal with that
[23:31:02] <@vapier> the burden is on the arch guys to resolve it, and it wouldnt break systems anymore than if you went through the revdeps
[23:31:12] <@dberkholz> if they don't already exist
[23:31:26] <jakub> vapier: does this 2+4 months suggestion include security issues, or should that be a separate policy?
[23:31:30] <@vapier> and it would actually be better for the arch guys -- fix the failing package and dont have to re-keyword the revdeps
[23:32:06] <@vapier> people groan when the word security pops up, but i dont think it's relevant
[23:32:30] <jakub> just asking ;)
[23:32:36] <@vapier> removing a security affected package wont force any additional upgrades on any systems
[23:32:47] <@vapier> world -Dup would give same result
[23:33:12] <@vapier> i'm doing a lot of talking here
[23:33:22] <@dberkholz> it's great.
[23:33:37] <@dberkholz> i'm used to doing all the talking. maybe i should start coming an hour late every time.
[23:34:11] FlameBook proposes that next meeting starts only once dberkholz is settled down :P
[23:34:25] <@FlameBook> dberkholz, I'm also used to _you_ doing all the talking ;)
[23:34:33] <Philantrop> vapier: KDE would prefer the 1.5x suggestion of dberkholz'.
[23:34:50] <@jokey> with dberkolz, writing up tools if needed shouldn't be much of an issue if really needed
[23:35:02] <jakub> vapier: mkay.... more precisely... should security be allowed to punt stuff if some arch is totally non-responsive for lets say over a year?
[23:35:13] <@vapier> ferdy: if you had a choice of timelines, does the 2x vs 1.5x really make a difference for you ?
[23:35:40] <@vapier> jakub: what we're talking about already allows culling at half that time
[23:35:57] <@vapier> ferdy: i know you're one of our over burdened arch guys ;)
[23:35:57] <jakub> vapier: thanks, answers my question :)
[23:36:17] <@vapier> but we need to balance things here, and i'm afraid it's fallen too far towards the arch currently
[23:37:33] xjrn [n=chatzill@!hc-24-4-108-16.hsd1.ca.comcast.net] has joined !c#gentoo-council
[23:38:11] <@vapier> perhaps an additional bugzilla keyword would help as well for arch teams to really eck out the way past due
[23:38:15] <@jokey> well there has been a lot of noise on -dev also which seems to have made it kind of hard to discuss just the topic and not the arch as such
[23:38:17] <jmbsvicetto> vapier: This discussion is beyond the current mips issue, right? Having mips move to only ~mips is on the table, right?
[23:38:17] <@vapier> CULLREQ
[23:38:43] <@vapier> jmbsvicetto: i'm not picking on mips here, this applies to everyone
[23:38:55] <@vapier> i imagine ive slacked more than other devs would like with some arch keywording
[23:39:11] <@vapier> i know ive lost arch on somethings, but i dont blame the maintainers for doing it
[23:39:15] <jakub> vapier: damn remove yourself from CC when done </rant> :P
[23:39:24] <@Betelgeuse> vapier: and use echangelog
[23:39:38] <ferdy> "Ebuild Stabilization Time" what happens when that period finishes ?
[23:39:41] <@Betelgeuse> vapier: But arm/sh/whatever don't have the coverage of mips I think
[23:39:50] <@vapier> jmbsvicetto: i imagine as a consequence of this agreement, maintainers will start the mips=>~mips
[23:39:59] <@FlameBook> Betelgeuse, better than mips for what I maintain at least
[23:40:01] <@dberkholz> should be easy enough to add all that to your keywording script with pybugz
[23:40:21] <@Betelgeuse> dberkholz: Is that working nowadays?
[23:40:22] <@vapier> but this would have applied to other arches in the past
[23:40:28] <@Betelgeuse> dberkholz: Last time I tried it didn't work.
[23:40:30] <beandog> Betelgeuse, http://spaceparanoids.org/gentoo/gpnl/stats.php?q=arch
[23:40:34] <@vapier> we just dont have vocal peeps for other teams like mips
[23:40:35] <@dberkholz> Betelgeuse: yep. wanna talk more about it, let's do that in !c#-dev
[23:40:37] <ferdy> the first paragraph of "Removing Stable Ebuilds." is what really really makes me nervous
[23:41:14] <@dberkholz> does that really mean removing so there's no stable version, or does it mean forcibly stabling a newer version?
[23:41:16] <@vapier> oh, i also forgot ... there needs to be a fallback for arches to explicitly pin a version indefinitely ... with the understanding that they'd be responsible for its up keep
[23:41:44] <@vapier> i do not think force stabilization by a non-arch maintainer makes any sense
[23:42:02] <@FlameBook> vapier, metadata.xml allows restricted maintainership, that would work, I suppose
[23:42:20] <@vapier> i know there's a few packages where s390 explicitly requires old versions of packages
[23:42:24] <@dberkholz> ok, so instead of giving something marked stable that might be broken, we give them no ebuild at all.
[23:42:26] <@vapier> dictated by ibm
[23:42:34] <@vapier> dberkholz: they get ~arch
[23:42:42] <jakub> vapier: well... similar fallback is feasible with single packages... not stuff like KDE I'd say... yeah, toolchain and similar for sure
[23:43:01] <@dberkholz> they get no ebuild at all without changing their configuration, which is exactly the same situation they'd be in if we force-stabled
[23:43:02] <jmbsvicetto> ferdy: In the case of kde, 3.5.5 is the only version with any mips keywords. So if that gets removed, mips will lose kde
[23:43:32] <@vapier> dberkholz: i think it sort of violates the guarantee that stable brings
[23:43:53] <@vapier> a package marked stable is an implicit guarantee from the arch maintainer that the version is known/supposed to work
[23:44:00] <@dberkholz> that was my possible "con" too, wasn't sure whether others would share it
[23:44:13] <@FlameBook> I agree with mike on this
[23:44:34] <@dberkholz> as not an arch person or a stable user, it's not exactly my best area
[23:45:14] <jakub> well... /me notes that, while talking about mips, tons of their 'stable' packages cannot compile on stable system at all
[23:45:15] <@vapier> presumably arches that get enough noise that their stable is going away should be able to muster some workflow to get newer versions stabilized
[23:45:27] <@vapier> we're not talking about mips
[23:45:31] <@vapier> stop mentioning mips
[23:45:52] <jakub> vapier: mkay... abstractly then :p should the maintainer be allowed to stabilize newer version in this case, or drop to ~arch
[23:46:07] <@vapier> in the case where a package would lose all stable keywords, if there are users affected, they'd convey to a maintainer that version FOO works, so the maintainer would have something to go on
[23:46:20] <@vapier> (arch maintainer there)
[23:46:29] <@vapier> which is a hell of a lot better than a package maintainer picking random versions and moving it
[23:46:51] <ferdy> in an ideal world, non-arch maintainers won't touch arch keywords (aside of ~all for bumps and that kind of stuff, of course)
[23:47:06] <jakub> vapier: not talking about arch testers/maintainers... simply stuff that fails to compile w/ current toolchain/base system stuff or similar
[23:47:16] <@Betelgeuse> ferdy: would be doable on the server side.
[23:47:20] <jakub> what's the value of 'stable' keyword there, it's useless
[23:47:41] <@vapier> ferdy: in an ideal world, the arch maintainers would be able to keep up
[23:47:45] <ferdy> jakub: 'worked with a stable system when it was tested'
[23:47:47] <@vapier> but that isnt always the case
[23:47:54] <ferdy> vapier: that was the second part of my sentence, sorry....
[23:48:00] <@vapier> np
[23:48:09] <jmbsvicetto> vapier: There's another issue in here, whether a maintainer should be forced to have a keyword added for an arch that has failed to keep up.
[23:48:17] <@FlameBook> well, I'm sorry to bail out before time, but fever is getting its way through my mind at the moment
[23:48:21] <jakub> ferdy: well... yeah it worked once upon a time, does not any more... no mre stable
[23:48:25] <ferdy> so we have to find a way for maintainers won't be affected when arch teams aren't able to keep up without messing anyones work
[23:48:38] <@FlameBook> I'm fine with whatever vapier thinks is fine, he knows the problem and I trust he'll do the right thing.
[23:49:00] <@vapier> jmbsvicetto: i dont follow ... pkg maintainers are not allowed to move ~arch to arch
[23:49:10] <@FlameBook> as for CoC I already said I'm okay with whatever dberkholz decides, as he's way more experienced than me in that regard, and I also trust him on that issue
[23:49:11] <@vapier> the proposal is to allow pkg maintainers to drop arch after a timeout
[23:49:33] <jakub> good, finally an answer... :)
[23:49:38] <@FlameBook> night 'rybody
[23:49:41] FlameBook [n=intrepid@!hamarok/helper/flameeyes] has quit IRC: "Leaving"
[23:50:01] <ferdy> jmbsvicetto: well... I think there shouldn't be a discussion about that. Arch teams' opinion is final, IMHO
[23:50:11] <@vapier> i'll take Richard's proposal, tweak it according to input here, and send it out, and we can decide on it next meeting
[23:50:18] <@vapier> aye ?
[23:50:21] <@lu_zero> fine
[23:50:25] <@dberkholz> sounds reasonable
[23:50:49] <@jokey> +1
[23:50:49] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
[23:50:55] <jakub> well, one more thing... should a maintainer be allowed to ban $arch from keywording his package?
[23:50:57] <jmbsvicetto> vapier: No. Let me give an example. Maintainer of package xyz has had problems with 1 or more arches being able to mark stable or even keyword said package. Things get to a point where the package has one last, old version marked stable / keyworded on said arches. Should arch teams have the power to keep the keyword for that package when the maintainer doesn't want to depend on said arches any more?
[23:51:10] <jmbsvicetto> vapier: Assuming those timelines have been broken by the arch teams
[23:51:37] <@vapier> jmbsvicetto: it's a case by case basis which the maintainers/arches should agree on
[23:52:07] <jmbsvicetto> vapier: Well, what about cases where maintainers don't want to have that overhead anymore and the arch team won't cooperate?
[23:52:08] <@vapier> if the arch truly needs the older version, then they can keep it and they're responsible for maintaining it
[23:52:24] <@vapier> if they simply dont have the time to test a newer version, then the arch team loses
[23:53:05] <@vapier> we cant account for maintainers and arches being asshats
[23:53:19] <@vapier> if the two truly cannot come to a decision, they can ask a higher power (probably us) to decide
[23:53:23] <@jokey> vapier: as you'll post a revisited version, can we move to CoC?
[23:53:29] <@vapier> yeah
[23:53:30] <@Betelgeuse> yeah two council members can make a decision
[23:53:30] jokey looks at the clock
[23:53:41] <jmbsvicetto> vapier: We have a rule that prevents maintainers from dropping arches. Shouldn't we give them the option to not support an arch (on extreme cases)?
[23:53:48] <jakub> jokey: pffft, go open a beer ;P
[23:54:00] <Philantrop> vapier: Agreed. But let's assume a maintainer would consider actively dropping even ~arch should a team keyword the package *he/she* has to maintain.
[23:54:17] <@vapier> assume on the list
[23:54:20] <@vapier> moving on
[23:54:22] <@jokey> indeed
[23:54:27] <Philantrop> vapier: ok
[23:54:42] <@jokey> so CoC then and dberkholz' part :)
[23:55:09] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has left !c#gentoo-council
[23:55:47] <@dberkholz> jokey: are those one and the same, or do i have another mystery part?
[23:55:52] <@vapier> personally, i'd think more about simply abolishing devrel resolution/etc... as well as CoC and take a more simple approach: if you're an asshat, you get tossed
[23:56:01] <@vapier> no drama
[23:56:10] <@jokey> dberkholz: it's the same ;)
[23:56:18] <@Betelgeuse> vapier: and who decides that?
[23:56:22] <@vapier> if you cant play nice, we have a size 15 boot here for you
[23:56:46] <@vapier> it should be pretty self evident
[23:56:52] <@vapier> every issue that's come up so far has been
[23:56:53] <fmccor> Betelgeuse, That's the quiestion, isn't it?
[23:57:00] <@vapier> but i digress
[23:57:08] <@vapier> go on with the CoC discussion
[23:57:31] <@dberkholz> the concept's in the agenda, but i'll briefly summarize
[23:58:06] <@dberkholz> where there are existing moderators, they will enforce the CoC themselves. other than that, the proposal would add mods to the -dev list and !c#-dev.
[23:58:44] <@lu_zero> who exactly?
[23:58:59] <@dberkholz> To Be Determined
[23:59:16] <@dberkholz> personally, i think that we could use some mod action on the list far more than !c#-dev
[23:59:31] <fmccor> Yes.
[23:59:36] <@jokey> maybe I'm mistaken but if someone goes insane on !c#-dev, it's a default devrel case, isn't it? and for immediate action, you can always give people a nice and warm kick
[0:00:23] <@dberkholz> jokey: that depends. do you want to wait 2 months for a trial?
[0:00:53] <TFKyle> vapier: would that be permanent or? (I assume by "tossed" you mean banned by atleast the medium that you acted up on in some way - or is that just for devs and getting your devship revoked?)
[0:01:10] <@jokey> we're all ops on !c#-dev so (theoretically) any dev can kick
[0:01:10] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has quit IRC: "Leaving"
[0:01:28] <@dberkholz> kicking an op doesn't get you very far.
[0:02:38] <@jokey> ubuntu people solve it by sharing a management account for the chan among 4-5 people who can immediately modify the lists if really needed
[0:02:42] <@dberkholz> the idea on irc would be to drop someone's level below autovoice for a day or whatever, then restore it.
[0:03:02] <@amne> imho just because everyone has ops doesn't mean there cannot be that there are some people that go after people who are abusive
[0:03:16] <@dberkholz> if said person is still nuts, kick 'em out as vapier said
[0:03:20] <@amne> e.g. what jokey and dberkholz just said
[0:03:24] <@amne> yeah
[0:04:21] <@dberkholz> the kicking part, at this point, would be handed off to devrel
[0:04:47] <@vapier> take some personal responsibility
[0:04:48] <@dberkholz> we could argue over whether it should instead be decided by the council
[0:04:51] <@vapier> if you cant, you will be warned
[0:04:52] bheekling [n=bheeklin@!h202.3.77.38] has joined !c#gentoo-council
[0:04:56] <@vapier> if you still cant, you get tossed
[0:05:02] <@vapier> get your act together, come back later
[0:05:10] <@vapier> dont get your act together, stop wasting our time
[0:05:15] <@jokey> indeed, vapier, fully with you :)
[0:05:39] <@vapier> but my dissertation on the subject is off-topic for this CoC stuff
[0:06:07] <@jokey> main reason is the -dev ML anyway so we should really focus on that
[0:06:19] <@dberkholz> vapier: nah, it's on topic
[0:06:24] <@vapier> there should be no body here ... developers should be able to call out on any other developer instead of idling accepting it
[0:06:40] <@vapier> err, "there should be no body here making the decision"
[0:06:47] <@dberkholz> what, have a duel?
[0:07:14] <@vapier> there is plenty of bad karma that goes down everywhere that onlookers just accept
[0:07:30] <@jokey> welcome to the real world ;=)
[0:07:33] <@vapier> i'm saying any moderation solution doesnt address the root of the problem
[0:08:10] <@dberkholz> how do you propose to change the root of the problem?
[0:08:36] <NeddySeagoon> vapier, Well, thats too many immature alpha males ... how do you fix that ?
[0:08:53] <@vapier> we steal g2boojum's seed, combine it with the good traits from developers, and kill off the originals
[0:09:48] <@dberkholz> i agree that we need to create a positive atmosphere. i think that moderators can be the first step in building a culture of intolerance toward assholes
[0:10:08] <@dberkholz> once that culture exists, we won't need mods anymore
[0:10:24] <@vapier> i'm looking long term
[0:10:34] <@vapier> what needs to be decided today needs to be decided today
[0:10:40] <@vapier> my thoughts dont really have bearing on it
[0:10:46] fmccor suspects that no matter where you start with vapier's approach, you will end up with something like devrel.
[0:11:09] <@vapier> no centralized body ... if you dont like the culture, fork your own
[0:11:11] <@vapier> go write a blog
[0:11:16] <@vapier> we dont care
[0:12:44] <@vapier> but seriously, dberkholz wants a resolution here, so focus on that
[0:13:20] <@amne> i think dberkholz' approach is good
[0:14:19] <@jokey> if it doesn't work out, we can/have to try something else anyway but I'm all for trying it
[0:14:25] <@amne> heh
[0:15:13] <@dberkholz> how many people are for the idea, as it stands now?
[0:15:51] <@amne> me
[0:15:58] <@jokey> as in do we want to vote?;)
[0:16:23] <@dberkholz> well, we don't really have enough details to finalize on, unless you'd just like to delegate further details to someone
[0:16:47] <NeddySeagoon> I don't see the difference between the current proposal and the Proctors
[0:17:37] <jmbsvicetto> NeddySeagoon: From previous discussions, it seems it will be an even smaller group and very close to the council
[0:17:47] <@dberkholz> there are no pointless warnings, only actions.
[0:18:15] <@dberkholz> there isn't going to be discussion about moderation on -dev, so people will have to actually make a little effort to whine about it.
[0:18:15] <NeddySeagoon> dberkholz, Hmm ok
[0:18:26] <@dberkholz> since -dev is now purely technical
[0:20:07] <@dberkholz> i think getting bogged down into -dev threads with attempted warnings, responses, and so on was an approach the mods should never take
[0:21:13] <@dberkholz> we're starting to rehash discussions we've already had
[0:22:04] <@dberkholz> so, what i would like from council members is: do you like the idea, do you think it needs significant changes, or do you dislik eit
[0:22:18] hkBst [n=hkBst@!hgentoo/developer/hkbst] has quit IRC: "Konversation terminated!"
[0:22:46] <@dberkholz> if we can agree that the idea is the way to go, we can start focusing on the details instead of returning to the original idea all the time
[0:23:06] <@lu_zero> I like the idea
[0:24:40] jokey too
[0:24:50] <@vapier> i'm with dberkholz
[0:25:40] <@dberkholz> Betelgeuse, around?
[0:25:50] <@Betelgeuse> dberkholz: yeah
[0:26:04] <@Betelgeuse> dberkholz: you rule
[0:26:22] <@dberkholz> good to hear. =)
[0:26:47] <@dberkholz> alright. we're going to proceed with this idea. i'll try to get some concrete ideas out to the -council list this week
[0:27:39] pchrist_ [n=tester@!h84.38.8.37] has joined !c#gentoo-council
[0:28:03] <@dberkholz> anyone else got additional CoC points now?
[0:29:10] <@dberkholz> ok, let's open the floor for any new topics
[0:31:03] <@jokey> well we have one missing
[0:31:12] <@jokey> Document of being an active developer
[0:31:16] Sweetshark [n=bjoern@!hd018195.adsl.hansenet.de] has joined !c#gentoo-council
[0:31:21] <@jokey> s/missing/left/
[0:31:43] <@vapier> i think that's something we could do with infra
[0:31:53] <@vapier> have it be something you need to log into dev.g.o
[0:31:57] <@vapier> run a command
[0:32:08] <@vapier> it generates a digitally signed document
[0:32:18] <@vapier> the digital key is maintained by infra
[0:32:41] <@vapier> therefore random devs cant generate documents and just change the names
[0:33:06] <@vapier> have it auto-include information like date of joining
[0:33:07] <@jokey> we could add that our userlist.xml can be used for reference if it is still accurate
[0:33:12] <xjrn> is gentoo in a  position to broker liveId's?
[0:33:42] <@vapier> jokey: right, now that the ldap and crap is integrated
[0:33:45] <@vapier> use that as the backend
[0:34:04] <@Betelgeuse> jokey: userinfo.xml is generated from LDAP
[0:34:06] <@dberkholz> xjrn: is that different from openid?
[0:34:55] <@jokey> Betelgeuse: that's my point, once you set it to retired, it's killed at max 60 minutes later on the website
[0:35:02] <@dberkholz> araujo: could you just print off an "official" gentoo business card with your name on it, that perhaps only gentoo devs have access to
[0:35:06] ferdy [n=ferdy@!hgentoo/developer/ferdy] has quit IRC: "[IRSSI] Tiger Woods uses Irssi. FORE!"
[0:36:18] <@vapier> eh, no one accepts business cards as proof of anything
[0:36:25] <@vapier> ive tried
[0:36:43] araujo looks around
[0:36:52] <xjrn> dberkholz: sorry openId
[0:37:00] <araujo> dberkholz, you mean, to send it to every developer?
[0:37:10] <@amne> sorry guys, i'm already falling asleep here, so i'll idle out
[0:37:12] <@dberkholz> araujo: just have a template of some sort sitting on woodpecker
[0:37:25] <@dberkholz> devs can grab it and do whatever they need
[0:37:35] <@dberkholz> if not a business card, some other document
[0:38:05] <araujo> dberkholz, ok , so we won't need a script for this?
[0:38:29] <@dberkholz> araujo: that depends how provable your proof has to be. i haven't seen digitally signed things from any job i've ever had
[0:39:02] <@dberkholz> what are the requirements?
[0:39:42] <araujo> dberkholz, it doesn't need to be something that complex, only a document specifying for how long you have been a Gentoo devel, and if you are still active
[0:40:11] <araujo> something that can 'officially' prove you are a developer
[0:40:11] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has quit IRC: "what, what, what, what, what, what, what, what, what, what.  Only 10 Watts Neddy ?  Thats not very bright!"
[0:40:39] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has left !c#gentoo-council
[0:40:39] <araujo> it'd be nice if it is digital signed too
[0:40:46] <araujo> digitally*
[0:40:48] <@dberkholz> if we just had a pretty little scribus document that looked pretty and called itself a certificate of some sort, that might be enough?
[0:40:59] <araujo> dberkholz, yeah, pretty much
[0:41:32] <@jokey> maybe stuff like you can get from SETI
[0:41:40] <@jokey> "You have solved X workunits" ;)
[0:42:33] <araujo> this is just a way so you can prove 'on paper' you are cooperating with the project
[0:43:37] musikc [n=musikc@!hgentoo/developer/musikc] has quit IRC: Read error: 110 (Connection timed out)
[0:43:48] <tsunam> I had created 2 forms of letterhead when seemant needed to do a thing for another developer
[0:43:51] pchrist [n=tester@!hunaffiliated/pchrist] has quit IRC: Read error: 110 (Connection timed out)
[0:43:55] <tsunam> recommendation
[0:44:09] musikc [n=musikc@!hgentoo/developer/musikc] has joined !c#gentoo-council
[0:44:14] <tsunam> not exactly what you're talking about but
[0:44:50] <tsunam> A standard form letter would work
[0:44:56] <tsunam> (well should)
[0:45:15] <araujo> or the dberkholz's certificate idea too , both would make it
[0:45:15] <@jokey> indeed
[0:45:25] <@dberkholz> except someone would have to actually sign a standard form letter, requiring effort from other people
[0:46:07] <tsunam> I hereby certify that under perjury of $court of law that Mr berkholz is a developer for the Gentoo Linux Foundation. Undersigned by Joshua Jackson Gentoo developer etc
[0:46:17] <araujo> dberkholz, sign once and scan then? :-P
[0:46:23] <tsunam> dberkholz: would it be hard to get someone to do that?
[0:46:33] <@dberkholz> tsunam: depends whether 1 person or 300 request them
[0:46:34] <tsunam> araujo: no one would want their signature scanned like that
[0:46:56] <araujo> tsunam, well, if it is hand-written per letter, *much better*
[0:46:57] <@dberkholz> you'd have to deal with other annoying stuff like postage etc
[0:47:32] <@jokey> well we could make all council members capable of signing such letters
[0:47:49] <@jokey> and you pick the closest on then
[0:47:52] <araujo> indeed
[0:47:55] <@dberkholz> we could email out signed emails
[0:47:57] <@dberkholz> would that work?
[0:48:08] <araujo> dberkholz, it would work from my point of view
[0:48:14] <@jokey> not really, corporate stuff hardly works with gpg
[0:48:31] <araujo> what if we have both options available?
[0:48:39] <tsunam> I'm not sure how willing an email would be as proof even if its from an @gentoo account for proof...
[0:48:40] <@dberkholz> it does in the US, there's the e-sign act that's legally replacing an ink signature. not sure about other places
[0:49:03] <@jokey> dberkholz: in germany you have to acquire some X509 at least
[0:49:12] <@jokey> plus it's not equal in all cases
[0:49:53] <@dberkholz> i don't think we need something that will hold up to a court of law
[0:50:25] <Philantrop> dberkholz: No, but an email doesn't look very professional which would be a problem over here, at least. :) Much more than the legal stuff.
[0:51:15] <@dberkholz> Philantrop: <html><img src="fancygentoologo" /></html>
[0:51:31] <araujo> if you can agree on sending this letter to the actual developer (costs paid by devel of course) would be way much better, it'd be valid in a wider range of situations
[0:52:14] <@dberkholz> araujo: the costs would basically be a pint, if you ever happened to meet. nobody's going to ask you to send them that kind of money.
[0:52:25] <araujo> dberkholz, ok
[0:52:48] <@dberkholz> it just gets to be a problem if certain people end up sending out huge numbers to foreign countries
[0:52:54] <@Betelgeuse> The post expenses are probably smaller thatn the international money transfer expenses
[0:53:21] <@dberkholz> i would much rather have something where the person who wants it can do all the work
[0:53:40] <@dberkholz> either manually filling stuff into scribus, or some autogenerated doc like vapier said
[0:53:45] <araujo> dberkholz, that'd be ideal ...
[0:53:56] <@vapier> i wonder if you can combine the two
[0:54:03] <@dberkholz> probably, it's just xml
[0:54:17] <@vapier> ah, was not aware
[0:54:36] <@vapier> do we have any scribus to start with ?  or does someone need to start from scratch ?
[0:54:57] <@dberkholz> find . -name '*.sla*'
[0:56:09] <@vapier> araujo: you any good at scribus ? ;)
[0:56:11] <Philantrop> dberkholz: I totally agree with that. The Scribus variant would be my personal favourite but an automated doc is fine, too. Just email is not ideal. :)
[0:56:18] <@dberkholz> think there's some stuff floating around
[0:56:23] <@dberkholz> i can do scribus
[0:56:40] <@jokey> ack, scribus would look even nicer :)
[0:56:46] <araujo> vapier, haha, not really, but i can help
[0:57:00] <@vapier> so we'll follow up to the dev list
[0:57:08] <@vapier> see if there are any quick takers
[0:57:13] dberkholz notes his above comment
[0:57:16] <@vapier> ive toyed with scribus and it doesnt seem terribly difficult
[0:57:22] <@jokey> still at least I'm willing to offer hand-signed if developer who requests it pays shipping
[0:57:24] araujo can help dberkholz 
[0:57:37] <@vapier> dberkholz: well i was just trying to get the guy who wanted it to do it :)
[0:57:38] <@dberkholz> aha, gentoo-projects/pr/ has some scribus stuff
[0:57:49] <@vapier> scribus base + automated fill in + digital signing
[0:57:52] <araujo> jokey, yes, I think it's good idea to offer 'both' ways
[0:57:54] <@vapier> see if we cant get infra to do somethin
[0:58:00] <@dberkholz> i can come up with a scribus template, araujo can deal with the rest
[0:58:04] <tsunam> I'd probably say that quite a few developers wouldn't mind having something official that says "I worked on the project" to be honest
[0:58:20] <@dberkholz> tsunam: perhaps we should start handing out little pins for years of service too =)
[0:58:25] <xjrn> wow, seems like nukes and htmldoc could do the whole thing to validate an account has a status into a pdf mime/download ...
[0:58:25] <tsunam> dberkholz: lol
[0:58:38] <tsunam> dberkholz: now you're getting the idea ;)
[0:58:45] <tsunam> dberkholz: gold watch after 25 years? :-P
[0:58:51] <araujo> dberkholz, ok
[0:58:56] <@dberkholz> something along those lines wouldn't be a bad idea, actually. i'll look into it.
[0:59:06] <@dberkholz> not with actual expensive stuff, but at least personal emails
[0:59:11] <araujo> so, any council member will be able to sign it?
[0:59:27] jokey is for that
[0:59:30] <@dberkholz> araujo: we'd probably just come up with a signing key that would autorun somewhere
[0:59:31] <tsunam> I would say that the council would be the body that would be the best choice
[0:59:59] <araujo> dberkholz, ok
[1:00:00] <@dberkholz> perhaps get it signed by the releng key, unless there's a more master key around
[1:00:24] <@jokey> could even generate a council key if needed
[1:00:41] <@vapier> tsunam: you think we're made out of money ?
[1:00:45] <@vapier> how about a pen
[1:00:51] <@vapier> that's all i get at a real job
[1:00:52] <tsunam> vapier: heh
[1:00:55] <@vapier> a goddamn pen
[1:01:03] <@vapier> oh and a pin
[1:01:03] <tsunam> vapier: at least you get a pen...
[1:01:17] <@jokey> "I've been with gentoo for 3 years and all I got is this damn T-Shirt" ;)
[1:01:23] <araujo> hah
[1:01:23] <@vapier> tsunam: you can have mine
[1:01:26] <@dberkholz> how about fake glass jewels on your nametag. (nametag purchased separately)
[1:01:38] lu_zero heads to bed
[1:01:44] <@lu_zero> nite
[1:01:48] <araujo> later lu_zero
[1:01:55] <@dberkholz> jokey: yeah, it might not be a bad idea to come up with a master gentoo key if we end up having more than 1 purpose for it
[1:02:11] <@dberkholz> one we could hide in a fireproof vault somewhere and only remove once a year
[1:03:14] <@jokey> don't even need that... make it "Gentoo Council Signing Key 2007-2008" and invalidate when new council is approved
[1:03:36] <@vapier> it sounds like a key for recruiters to maintain
[1:03:43] <@vapier> they are the in/out gateway after all, not the council
[1:04:10] <@Betelgeuse> vapier: in only
[1:04:16] <@Betelgeuse> vapier: different team doing retirement
[1:04:22] <@dberkholz> there's "undertakers" now
[1:04:37] <@dberkholz> doesn't that cool name make you want to join?
[1:04:58] <@jokey> want just one point agreed on explicitely: will council members be allowed to sign such documents on behalf of gentoo?
[1:05:22] <@dberkholz> perhaps so, but they should somehow log their actions like that
[1:05:25] <@vapier> infra then i guess since they are the real care takers of this information
[1:05:36] <@vapier> recruiters/undertakers update the same db
[1:05:51] <@vapier> it's a key signing fest
[1:06:01] <tsunam> ultimately it needs to reside with someone...and as it appears there's not one group its perfect for...
[1:06:06] <tsunam> who would actually accept the duty?
[1:06:07] <@jokey> dberkholz: as in send a notification to council@?
[1:06:13] <araujo> I guess you (the council) will have to track the signing of these documents?
[1:06:35] <@dberkholz> jokey: or something else that people don't see unless they go looking for it, like a file in cvs
[1:06:48] igli [n=igli@!hunaffiliated/igli] has left !c#gentoo-council: "Have a good one ;-)"
[1:07:05] <@dberkholz> tsunam: it sounds like devrel in some way to me, wherever it falls in there
[1:07:22] <@vapier> yeah
[1:07:49] <tsunam> well that's 4 groups now, recruiters,hatchetmen (aka undertakers),council,devrel
[1:08:12] <@dberkholz> recruiters+undertakers all fall into devrel. we could just hand it off to devrel lead to take from there
[1:08:47] <@dberkholz> imagining devrel as a sort of HR dept, and council as executives, this seems like something that's clearly HR
[1:08:48] <@vapier> yes
[1:08:59] <tsunam> very valid point dberkholz
[1:10:27] <@dberkholz> so, where to proceed from here
[1:11:02] <@jokey> dberkholz: you and araujo looking into a scribus'ed template, devrel generating a signing key for these purposes?
[1:11:44] <@dberkholz> musikc: around again?
[1:13:28] <@jokey> could we agree on that plan and then close the meeting if there's nothing else? 1 a.m. here already ;)
[1:13:54] <araujo> fine with me :-)
[1:13:59] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has quit IRC: Read error: 110 (Connection timed out)
[1:14:22] <@dberkholz> jokey: sounds good
[1:14:50] <@jokey> k' then
[1:15:05] <@dberkholz> let's close up shop for this month
[1:15:12] <@jokey> indeed
[1:15:20] <@dberkholz> jokey: you're on summary/log committing and mailing duties
[1:15:42] <@jokey> dberkholz: yup, written it already, can you quickly glance over it to spot potential typos? ;)
[1:16:19] <araujo> dberkholz, brb in a few minutes, then I can look into this
[1:16:43] <@dberkholz> jokey: could you try to add a one-line summary for each topic, right whether the topic name is. like GLEP 54: Postponed to -dev. etc..
[1:17:10] <@dberkholz> s/compability/compatibility/
[1:17:21] <@dberkholz> s/techincally/technically/
[1:17:28] <@dberkholz> s/optionl/option/
[1:17:46] <@dberkholz> s/compatibiliy/compatibility/
[1:17:58] <@jokey> wondering if there are dicts installed on dev.g.o
[1:18:17] <@dberkholz> could you note in CoC that i'll provide them on the -council mailing list
[1:19:00] ulm [n=ulm@!hgentoo/developer/ulm] has left !c#gentoo-council: "ERC Version 5.2 (IRC client for Emacs)"
[1:25:40] <@jokey> we're closed then. thanks for the discussion to everyone involved :)



-- 
gentoo-commits@l.g.o mailing list