[15:00:23] Ok, I have 19:00 on my watch. [15:00:27] Roll call... [15:00:32] -*- ulm here [15:00:36] -*- WilliamH here [15:01:20] blueness, dilfridge, radhermit? [15:01:20] here [15:02:45] I just sent a text to dberkholz [15:02:59] here [15:03:07] Ok, just blueness [15:03:44] here! [15:03:55] shit i got busy in another channel [15:03:58] but i'm ready :) [15:04:06] Ok, let's get started - no word from dberkholz but I did text him. [15:04:09] and there's the text :) [15:04:15] at least this time i wasn't asleep [15:04:43] Ok, same agenda, but we're up to Deprecating and killing the concept of herds [15:04:55] Looks like mgorny is at the center of every agenda item today. :) [15:04:57] kill them with fire and nukes [15:05:11] WilliamH, no kill them with loooove [15:05:17] Nah, nukes are reserved for cvs keywords. [15:05:26] ah yes [15:05:29] not kill but correct the definition (people not packages) [15:05:37] I'm o.k. with killing herds, as long as we keep a distinction in metadata if the maintaining entity is a person or a team [15:05:38] okay i'm all for killing herds, but two things [15:06:00] 1) we keep the mail aliases somehow so that we can track packages [15:06:04] ulm: you can tell that in the tags [15:06:14] so maybe change to just [15:06:24] kde@gentoo.orgGentoo KDE team [15:06:31] compare this ^ to [15:06:36] kde [15:06:38] i like that [15:06:48] Would we require all packages to have a maintainer or project listed to be considered maintained? [15:06:54] dilfridge: nuke the tag [15:06:57] dilfridge: that's not what the DTD defines as name [15:07:00] That is, just an alias isn't good enough unless it is a real project? [15:07:01] 2) we need to really figure out what the relationship between herds and projects are [15:07:02] dilfridge: it is unnecessary [15:07:05] name is for a person [15:07:27] i don't even know what teams i'm on anymore because i've just been working with herds aka mail aliases [15:07:35] blueness: herds are groups of packages, maintained by devs who are members of projects. [15:07:36] if we can come up with a similarly concise metadata fomulation then I am for nuking something. I'm not happy to blow up all metadata files to infinity. [15:07:46] so this doesn't kill herds, just changes metadata? I'm fine with that, never liked the 2nd layer of redirection [15:08:13] radhermit, that's my understanding [15:08:14] dilfridge: +1 [15:08:15] blueness: for example, the accessibility project maintains the accessibility and gnome-accessibility herds. [15:08:19] so we're really not loosing any data [15:08:21] I think we're all for simplifying things here. I'm not quite sure we are solid on what we want to change TO. [15:08:40] a) keep metadata.xml somehow short and concise. [15:08:55] just use straight email addresses in metadata only [15:09:01] WilliamH: same for emacs team, it maintains emacs and xemacs herds [15:09:08] b) kill the concept "herds=sets of packages" (because noone uses it like that) [15:09:19] on point b correct [15:09:42] The tag should go [15:10:11] WilliamH: replace it by or ? [15:10:13] which leads us to - what else is needed after a) and b) is done? redefine former herds as teams? [15:10:23] Should metadata have a way to distinguish between personal and alias emails? Can alias emails be "maintainers" unless they're projects? Where do non-maintaining aliases go? [15:11:00] dilfridge: I think we should define where we want to be. Getting there is a simpler problem. [15:11:14] we could introduce a tag that goes to a xxx@gentoo.org alias [15:11:23] dilfridge, that would be better [15:11:26] same usage as herd today [15:11:33] why extra tags? [15:11:41] mgorny: ++ [15:11:44] That was my thought. [15:11:47] -*- WilliamH agrees with mgorny here, why keep tags? [15:11:51] i've got this gut feeling that we need to define the existing and members so we know who is taking care of what packages [15:11:54] because it's an extra 20 characters that I have to type. [15:11:54] [15:12:02] But what about aliases that aren't maintainers? Do we want to ban them? Only true projects can have aliases? [15:12:17] we want aliases that are not maintaiers [15:12:25] sure [15:12:27] dilfridge: here specifically does *not* go to an email@g.o I don't think, you have to look it up in herds.xml [15:12:34] s/here/herd/ [15:12:38] Maybe the tag should be [15:12:42] WilliamH: yes, but that's an abomination [15:12:56] rich0, interesting idea [15:12:59] one level of indirection beyond sanity [15:14:16] So, some principles. Get rid of herds. Have email in metadata, and have a way to tell if the email is personal, proejct, or just non-maintaining alias. [15:14:21] just rename to [15:14:26] Ok, a maintainer tag contains a name and an email... that email could be an alias, just like we do now... [15:14:35] no attributes or other such xml abominations [15:14:36] rich0, ulm: ++ [15:15:00] ulm: that's extra work for no benefit [15:15:02] rich0, yeah that sounds okay [15:15:03] ulm: what is a "team"? :) Just an email address, that may or may not be a project, and which may or may not maintain a package? [15:15:15] with the distinction that x directly maps to x@gentoo.org without exceptions [15:15:22] mgorny: we'll have to update the dtd in any case [15:15:31] Ok, is our goal to fully spec this out today, or do we want to punt on the details and resolve next meeting? [15:15:43] -*- WilliamH is against a team tag [15:15:46] Maybe we just vote on the direction, and then let the DTD be fixed on the lists or something. [15:15:49] rich0: a team is the group of devs maintaining what is currently called a herd [15:15:50] rich0, this is too complex for me to think on the fly [15:16:03] just use a maintainer tag... [15:16:08] blueness: that is my concern - I don't just want to bikeshed the solution in 10mins. [15:16:12] maintainers can be aliases... [15:16:33] We can vote on the general direction and requirements, but then let the implementation be worked out on the lists with a final vote. [15:16:38] We can also propose a migration plan on the lists. [15:16:51] Until today we didn't really know where everybody stood on it. [15:17:05] please migrate after git, it will make it so much more sane [15:17:08] That would be my proposal. [15:17:28] That's reasonable because it could all be done in one commit. [15:17:42] ++ - Git will be done next Tuesday anyway. :) [15:17:49] -*- rich0 ducks [15:17:50] heh [15:17:52] heh ok [15:18:13] while we're at it, we could also make the maintainer tag for individual devs more concise [15:18:24] nick should be enough for gentoo devs [15:18:39] true [15:18:40] ulm: what about proxies? [15:18:45] Shoudl they get a different tag? [15:18:50] (or attribute) [15:18:59] do we need to bikeshed this all now? [15:18:59] I'm thinking about software that has to parse this stuff. [15:18:59] rich0: they would keep full e-mail addresses of course [15:19:05] seems like something for lists [15:19:11] rich0: I'm not sure that's necessary, because you can list multiple maintainers [15:19:14] no @ -> dev [15:19:16] radhermit: ++ [15:19:20] ++ [15:19:21] yeah, let's discuss it on lists [15:19:21] http://dpaste.com/1J2YMFS [15:19:29] Ok, then how about this for a quick summary: [15:19:32] ^^ this seems to be what we are all saying [15:19:42] also note that metadata.xml is not only for gx86 but also for other repos [15:19:45] including non-gentoo [15:20:07] mgorny: all we have to be concerned about is gentoo-x86 [15:20:24] "The council is in favor of retiring herds, allowing non-maintainer aliases to exist, and having a way to distinguish between individuals, projects, and non-maintainer aliases in metadata.xml. The details of how to implement this will be worked out in the lists before the next meeting." [15:20:43] yes! [15:20:47] perfect [15:20:47] +1 [15:20:51] -*- WilliamH yes [15:20:54] yes [15:20:57] -*- rich0 yes [15:20:57] -*- ulm yes [15:20:57] yes [15:21:19] Ok, I think that is all six of us [15:21:44] Ok, recorded. [15:21:46] Next topic. [15:21:51] Status of Games Team [15:22:05] Looking at the past summary, I believe radhermit was going to try to coordinate an election. [15:22:06] I sent one email, probably should have sent a followup one at some point [15:22:13] but that didn't happen [15:22:35] and no election happened because no new members stepped forward afaik [15:23:03] So should we disband the team and assign everything to m-n then? [15:23:12] I guess my question is whether the urgency to do something is the same? [15:23:15] there's no real way of asking "who's on such and such a team" is there? [15:23:17] WilliamH: would that help? [15:23:38] We did give the go-ahead for people to avoid the team if they felt the need. [15:23:48] So, it should be less of a barrier to progress. [15:23:50] I'll probably be in the same room as the current team leader sometime later today if that helps anything :P [15:23:55] blueness: the project page should list the members [15:24:05] if you want me to force him to relinquish his crown ;) [15:24:20] radhermit, how is that? [15:24:29] i'm not even sure who's who on that team [15:24:33] We're both located near Boston [15:24:36] https://wiki.gentoo.org/wiki/Project:Games [15:24:49] oh mike [15:25:05] afaik, vapier probably doesn't care about being lead in games anymore [15:25:05] heh, they moved the project page to the wiki? [15:25:10] I can ask him though [15:25:21] btw that page is incorrect as per council decision [15:25:30] "The Gentoo Games Project manages all games that are added into the Portage tree." [15:26:04] radhermit: I definitely think you should talk to him if you have the opportunity. [15:26:10] I'd be interested in how he feels about things. [15:26:23] it was migrated by creffett|irssi by the way, most likely together with a bunch of others [15:26:30] I don't want to block somebody from contributing - really most of this issue is about making sure games doesn't block others from contributing. [15:27:07] mgorny, is my understanding correct that games is blocking the removal of emul-* stuff which is blocking multilib stuff from progressing? [15:27:22] not anymore [15:27:23] uh, I don't think so [15:27:27] multilib team did all the work for them [15:27:30] multilib should just fix stuff [15:27:33] since they want it done [15:27:39] though most of the dependencies are still insane [15:27:42] like how most stuff works in the tree [15:28:05] okay so isn't that the original issue with that team? i mean if the original problem is gone, can we just leave it alone? [15:28:10] or are there other issues? [15:28:26] did they solve the 10-year security issue? [15:28:27] blueness: that is what I'm thinking. I don't want to just outright disband the team if they're doing something and they aren't really a problem. [15:28:29] people mentioned wanting to rework how games were installed/policies/etc [15:28:32] about nethack? [15:28:53] mgorny: I guess I'd ask whether anybody else wants to solve that issue. If games is standing in the way that is one thing. [15:28:54] hey! leave nethack alone ... its legendary! [15:28:58] j/k [15:29:12] There are a number of games that are hard masked in the tree because of security issues. these are closed-source binaries so will probably not be fixed. [15:29:18] imo, if people are serious about changing stuff just join and start discussing more [15:29:22] it's not nethack being broken, it's games.eclass install of it [15:29:32] WilliamH: If they're hard-masked, then it isn't a problem, right? [15:29:48] If something is truly broken and isn't maintained, then that is a treecleaning issue. [15:29:50] mgorny, okay thanks for that clarification [15:29:58] rich0: what's the point of them being in the tree if they are hard masked for security and have been for years? [15:30:07] WilliamH: do they still work? [15:30:14] Maybe people still want to use it? [15:30:26] mgorny, can we have a clear list of what's wrong with games team and then we can decide whether or not to leave lying dogs alone [15:30:55] I'll buy that nethack is doing something wrong. The question is, is somebody gong to fix it, or are we talking about treecleaning nethack/ [15:30:56] if the problems are big, we already get the picture that there's no movement there, we'll just disband and treeclean [15:31:00] rich0: I'm not saying people shouldn't use it if they want to, I'm just questioning why it is still in the main tree instead of an overlay? [15:31:18] WilliamH, that's a good idea, move it to an overlay [15:31:20] blueness: it's all in mgorny's e-mail message, requiring an agenda item for a previous meeting [15:31:35] mgorny: do you have a pointer to it? [15:31:37] WilliamH: I get that, but why not allow it in the main tree? Does it hurt anything? [15:31:42] ulm: a minute [15:31:49] ulm, mgorny i read it but i need a reminder [15:31:49] i think it's still in qa agenda [15:32:23] rich0: we should unmask if it is going to stay in the main tree; p.mask should not be permanent. [15:32:28] Making all of games m-n won't make the bugs disappear. [15:32:35] mgorny: this on, I think: http://thread.gmane.org/gmane.linux.gentoo.project/3919 [15:32:35] http://article.gmane.org/gmane.linux.gentoo.project/3919 [15:32:36] rich0, if there's a real problem(s) here, then let's act by saying we're give QA the power to move that stuff to an overlay and disband the game team [15:32:38] *one [15:32:39] WilliamH: I don't see why not, but we can take that offline. [15:32:44] heh :) [15:33:07] I'm not sure that there is a policy against having masked security problems in the tree permanently. [15:33:14] As long as they build/etc. [15:33:19] but QA's dead! [15:33:24] we need to disband it too :P [15:33:29] mgorny: not completely. [15:33:30] ... [15:33:32] how about we state "everyone is free to join games team" instead? [15:33:45] didn't I sort of state that already? [15:33:50] but seriously, since last failed meeting i don't know if qa can work [15:34:04] hmm? what did I miss this time? [15:34:08] never mind, later [15:34:14] i also mailed the -qa@ list about games team, and never got any response [15:34:24] mgorny, two problems i see: 1) political. demanding exclusivity. 2) the games.eclass breaking things like LFH [15:34:36] 1) is solved [15:34:52] 2) is solved by solving 1), noone is forced to use games.eclass [15:35:00] what's the problem? [15:35:27] dilfridge, well there's only one problem remaining and that is a treecleaning of bad packages [15:35:41] blueness: I suggest we let QA/treecleaners do that per-package. [15:35:43] if we remove that cruft from the tree than i'd be happy with the state of things [15:35:46] dilfridge: lack of consistency throughout the tree is an issue [15:35:48] well, the problem is that even if not everyone is forced to use it, we end up being inconsistent [15:35:50] ok, but that applies to all packages, not just games [15:35:55] it would be nice to do things in a uniform fashion [15:35:57] right [15:36:07] -*- WilliamH agrees with dilfridge [15:36:09] recently gnome team rewrote their packages to use games.eclass [15:36:15] seriously? [15:36:15] huh? [15:36:15] because someone told them to [15:36:26] that is kinda stupid. [15:36:29] mgorny: who told them to? [15:36:34] hasufell, i think [15:36:39] Still, I don't buy that we can NEVER have a package with a potential security issue in the tree if it is masked. But, I think we can let QA/tree-cleaners do their job first. [15:36:40] LOL [15:36:49] gees [15:36:49] now if i tell them to switch back, we end up in kinda stupid way [15:36:57] mgorny: go for it. [15:37:08] mgorny: they don't need to use games.eclass [15:37:35] I don't have a problem with people using the eclass. It just shouldn't be mandatory, and of course that makes it kind of useless. [15:37:35] this is getting slightly bizarr [15:37:39] rich0, this looks messier than i thought. how about as a first line of action the council asks treecleaners to focus on games that are abondoned or seroius disrepair [15:38:03] Well, first line of action is that radhermit chats with vapier, but yes, agree blueness [15:38:11] rich0, yeah true [15:38:15] I think we should separate org vs package issues. [15:38:18] blueness: basically we just need to do the work in qa; [15:38:21] don't treecleaners scan for all pkgs with tons of open bugs anyway? [15:38:26] blueness: following up on p.mask. [15:38:32] blueness: not just games [15:38:34] i.e. they should already be catching things [15:38:46] open bugs that are ancient at least [15:38:47] blueness: so I don't think there is any need for the council to do anything on that. [15:39:14] -*- WilliamH really isn't part of treecleaners [15:39:22] I can't really speak for how they do things [15:39:47] So, how about something like this: [15:39:47] should we make any statement about policy? like games group, or non-FHS directory layout in games.eclass? [15:39:50] or do we leave this to qa? [15:40:07] -*- WilliamH votes leave p.mask to qa [15:40:28] leave it to qa for now, since the question of exclusivity has been decided [15:40:30] right, if people have serious issues with certain pkgs, contact qa [15:40:34] we don't micromanage [15:40:49] right [15:41:03] if QA is unresponsive... well then [15:41:11] find some new QA members? :) [15:41:20] i'm the new QA member :P [15:41:21] "Council deferrs to radhermit to continue working with the games team on the organization issues for another month. Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes." [15:41:38] but i don't feel like stating 'i decide this because nobody else responded and qa was unable to meet properly' [15:41:49] heh that is always fun [15:42:06] we've had QA dictators in the past... ;) [15:42:08] is creffett still the QA lead? [15:42:17] rich0: yes [15:42:51] Is there another election due soon? [15:42:58] I'd think that would be coming up soon. [15:43:00] december according to schedule, I think [15:43:12] let me look it up [15:43:16] Maybe we should just ping them and figure out where things stand. [15:43:25] Thankless job I'm sure. :) [15:43:45] In any case, I suggest we defer on games to radhermit and QA/treecleaners for another month. [15:43:50] Maybe continue to monitor. [15:43:56] dilfridge: 2013-12-16 was last election [15:44:00] I don't think anybody wants to take any kind of direct action right now. [15:44:02] yes [15:44:19] Ok, was my proposal above worth voting on? We don't necessarily need to vote. [15:44:20] bug 494454 [15:44:22] https://bugs.gentoo.org/494454 "Vote of confirmation QA lead creffett"; Community Relations, Developer Relations; RESO, FIXE; dilfridge:council [15:44:23] We can just ping them. [15:45:05] rich0: you get a yes from me [15:45:07] Ok, any objections to moving on in the agenda. [15:45:10] rich0: voting is ok for me [15:45:19] moving on, too :) [15:45:23] ok, then let's vote: "Council deferrs to radhermit to continue working with the games team on the organization issues for another month. Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes." [15:45:27] -*- rich0 yes [15:45:30] -*- ulm yes [15:45:31] -*- dilfridge yes [15:45:35] sure [15:45:36] yes [15:45:36] -*- WilliamH yes [15:45:43] ok [15:45:48] next item. [15:45:53] Status of projects:\ [15:45:59] the multilib porting and subsequent disposal of emul-... packages [15:46:12] i replide to the mail [15:46:19] Anybody want anything further? [15:46:21] replied* [15:46:26] I don't need to see mgorny dance... [15:46:37] mgorny: any eta for stable unmasking? [15:46:43] i'm currently working on finishing qt work for qt folks [15:47:00] i think all issues are being worked out, so it's a matter of review + moving to the tree [15:47:02] then stabilizations [15:47:05] do qt5 work too while you're at it ;) [15:47:11] ugh I see dev-lang/perl in the list :( [15:47:12] with arch teams... i'd say 1-2 months :P [15:47:33] ok let's summarize, things are moving ahead. [15:47:34] ok? [15:47:39] oh I see we finally have it in the tree masked, nevermind... [15:48:13] https://wiki.gentoo.org/wiki/Multilib_porting_status < the ultimate list [15:48:20] qt4 is probably ~1 month too [15:48:38] libperl? [15:48:43] yes [15:48:45] isn't that dead? [15:49:00] the libperl package is dead, but that's just a library in dev-lang/perl [15:49:01] or merged with perl itself [15:49:04] right [15:49:10] but that list has the actual pkg [15:49:14] the emul- list is not 100% necessary [15:49:21] alright [15:49:22] we only port the packages that are actually necessary [15:49:28] sys-devel/libperl is gone soon. [15:49:43] perl won't need to be multilib most likely [15:49:47] phew [15:49:47] python may be necessary for samba-5 [15:49:51] unless we find way around it [15:50:07] next up... multilib PMS ;) [15:50:27] -*- dilfridge feels like kicking someone :o) [15:50:57] ok about the migration of packages to the wiki [15:51:07] s/packages/project pages/ [15:51:19] dilfridge: go ahead [15:51:36] the silly thing is, being in the metastructure project I'm probably the right person to talk to myself [15:52:02] https://wiki.gentoo.org/wiki/Project:Wiki/Project_Page_Migration_Status [15:52:08] this is the definitive list here [15:52:29] just translating a page is in most cases (imho) trivial [15:52:41] maybe we should propose a deadline? [15:53:07] dilfridge: after that we disband x86 and amd64? :) [15:53:18] :P [15:54:00] I do think a deadline does make sense all the same. [15:54:07] but seriously, it is not too much work per page. of course for one person doing all is a lot of work. [15:54:23] For obviously-critical projects we may just have to do something, but some of those projects may be defunct. [15:55:45] Ok, anything else on that? [15:55:55] Do we want to actually take action? The agenda is just for status. [15:56:09] status is "stalled in the middle" right now [15:56:22] maybe send a reminder to the mailing list? [15:56:28] yes, good idea. [15:56:38] yeah, talk is cheap at least :) [15:56:59] Ok, next agenda item is bug 503382 [15:57:01] rich0: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council [15:57:10] -*- rich0 looks around the room [15:57:14] -*- blueness smacks head [15:57:34] i say disband previous council [15:58:10] ok, moment of silence observed... [15:58:20] that was dberkholz [15:58:22] hd=eh [15:58:24] yup [15:58:27] erre heh [15:58:30] Ok, we'll prod him. [15:58:40] I don't see him on the list of chairs for this term [15:58:48] :) [15:58:53] Ok... [15:59:00] Open floor [15:59:06] Anybody want to take a shot? [16:00:00] Ok, I have a question about a procedure... [16:00:02] i can say that bashcomp2 is progressing fast too :P [16:00:10] i filed a lot new bugs today [16:00:11] WilliamH: go ahead [16:00:21] I know that generally a package needs a last rites and 30 days before removing it from the main tree. [16:00:36] Is that also true for a package that is in p.mask? [16:00:42] WilliamH: might as well [16:00:44] s/p.mask/p.mask already/ [16:00:48] Unless there is some reason to rush. [16:00:57] Or unless of course it is already masked for removal. [16:01:15] My two cents at least. [16:01:21] WilliamH: I'd keep the 30 days between last rites and removal there too [16:01:29] but it's a guideline only [16:01:34] I used to give a few days then too, as e.g. sending a last-rites mail "has been masked since..., will be removed in 10 days" [16:01:38] rich0, et al. i have to run. i'll read the backlog [16:01:38] Obviously copyright issues or such warrant an exception [16:01:45] blueness: ok, [16:01:51] dilfridge: that's reasonable. [16:02:22] dilfridge: that's one reason I haven't pushed hard personally to work on p.mask. [16:02:33] dilfridge: I wasn't sure how to go about that. [16:02:39] ok [16:03:01] Anything else on that? [16:03:16] mgorny: ++ on bashcomp2. Just in time for my switch to zsh. :) [16:03:55] Anything else for open floor? [16:04:36] If not, we're done. Next meeting will be Nov 11 [16:05:10] I'll post the summary shortly, and start the agenda for next month. [16:05:13] Thanks all :)