[20:00:26] -*- WilliamH is here [20:00:48] -*- mgorny is here for blueness [20:00:58] hi [20:01:08] I'm around-ish [20:01:16] In the cab 2min from home.. [20:01:28] I'm here until 19:30. [20:01:57] Could any of you please do roll call? [20:03:05] sort of just did, unofficially [20:03:10] just rich0 and ulm? [20:03:43] here [20:04:17] -*- WilliamH here until 19:30 [20:04:29] rich0: ping [20:04:57] blueness mentioned rich0 needed a proxy too but he didn't ping me afterwards [20:05:08] ah right [20:07:10] ok here again [20:07:16] ok here again [20:07:18] http://article.gmane.org/gmane.linux.gentoo.project/4132 [20:07:20] the agenda [20:07:34] i'm actually working on that council summary right now [20:07:37] should get it committed today [20:07:38] :) [20:08:03] so do we have anything to say on bug 523828 ? [20:08:08] dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep [20:09:16] I'm all for dropping the yyyy subdir, since we started removing old news items anyway. [20:09:46] as long as it's not hundreds of files, that should not make any problems [20:09:49] -*- WilliamH is for droping the subdir as well [20:09:53] dropping * [20:10:23] anyone else? [20:10:27] we need an updated commit hook [20:10:42] yeah, means coordiation mgorny<>infra [20:10:48] presumably not open source so it's gonna be impossible for anyone to work on it [20:10:49] yep [20:11:10] maybe we'll sync that with gitmig [20:11:10] that doesnt worry me too much since it was already modified once [20:11:33] mgorny: do it now, one thing less to worry about [20:11:55] ok [20:12:02] i'll ping infra people about it [20:12:12] do we need a vote? [20:12:51] -*- ulm notes that nobody has objected [20:13:00] indeed [20:13:12] so I think this is good to go from our side and we can un-cc council. [20:13:33] last words for this topic? [20:13:54] seems not. [20:13:57] ok [20:13:59] item 3 [20:14:03] open floor [20:14:06] anyone? [20:14:38] in metadata.xml! [20:14:44] ... [20:14:48] do we want to revisit this? [20:15:33] (talking as mgorny, not blueness now :P) [20:15:33] either leave everything as it is, or get rid of herds [20:15:43] -*- WilliamH says nuke herds [20:15:54] but don't rename it only to a more verbose syntax [20:16:00] so herds.xml completely and leave mail aliases? [20:16:31] mgorny: that would be my thought, just make herds into aliases if they aren't already, make them maintainers. [20:16:34] nuke herds as a concept ("groups of packages"), but unify/simplify it as mail aliases [20:17:23] I have a question in regards to EAPI 6 now that we have mgorny here too. Did we ever officially include (or vote on) banning global helpers? [20:17:27] so no type="" in maintainer? [20:17:34] and find a way to keep metadata.xml [20:18:05] if we are to change in backwards-incompat, we should probably switch from XML to JSON [20:18:10] or YAML, even better [20:18:22] - maintainers: foo@gentoo.org, bar@gentoo.org [20:18:30] even without - [20:18:47] mgorny: simpler, introduce a NEW tag that expands its contents to contents@gentoo.org [20:19:03] nope, that's a bad idea [20:19:13] why? [20:19:32] again it's going in the direction of having more rules [20:19:36] I personally like the (non-doable) dilfridge [20:19:53] plus not every ebuild repo is gentoo [20:20:09] dilfridge: yeah, keep it simple [20:20:40] eselect [20:20:41] emacs [20:20:45] right now the perl is a short alternative to a very long ... [20:20:56] and I dont want to lose this [20:21:01] so well, simplifying it in non-backwards compatible way is second step, i'd say [20:21:23] could we focus on the first step which is unifying alias style? [20:21:28] maintainer tag* [20:21:31] mgorny: it's not even backwards-incompat to move to yaml, you'd put it in metadata.yaml and could translate [20:21:38] yml rather [20:21:59] dberkholz: keep the .xml for a transition time? [20:22:08] just disallow having both [20:22:29] there are some tools/sites using the xml [20:22:37] packages.g.o I suppose [20:22:39] ulm: pretty much, yeah. server-side translator, if .yml exists it has precedence and might even be able to refuse commits to .xml [20:23:34] I have no problems with using xml, just there are ways of xml and xmn>m [20:24:45] 2. we want to replace metadata.xml with something simpler [20:25:19] strong no to 1. [20:25:21] mgorny: lgtm [20:25:25] 3. writing out @gentoo.org in every e-mail address sucks for the gentoo repository [20:25:39] if we want to, i can convert all metadata.xml to metadata.yml easily [20:25:42] we need a way to distinguish between teams and individuals [20:25:47] the other way would be a bit harder [20:25:48] dilfridge: you can't drop @g.o because of proxy maintainers? [20:26:10] no "@" versus "@" present? [20:26:13] ulm: .... but you just said no to keeping herds? [20:26:41] dilfridge: that's unprofessional assumption [20:26:46] mgorny: we don't drop projects and teams [20:26:50] just herds [20:26:57] ulm: so you say we change herd -> team? [20:27:10] (or project) [20:27:13] more or less, yes [20:27:23] mgorny: why? every e-mail address has to contain @. so the repository may as well provide a default domain if it is not given. [20:27:58] dilfridge: still, having explicit @gentoo.org does not hurt [11 chars] [20:28:10] and people tend to copy metadata.xml when forking ebuilds [20:28:12] how about a rewrite hook for lazy devs? [20:28:21] 11 chars times number of metadata files in the tree [20:28:35] ulm: you don't write 100 metadata.xml files every day [20:28:45] not to mention it's *not* hard to have a template [20:28:52] vim even generates good metadata.xml by default [20:28:56] with my e-mail and so on [20:29:05] 18038 metadata.xml in portage [20:29:07] ulm: an individual will more than likely not have the same name as a team. [20:29:17] ulm: or the same email address. [20:29:29] ulm: systemd and openrc come to mind as examples. [20:29:55] -*- WilliamH is out taxi is here for dental appointment [20:30:08] good luck [20:31:25] ulm: so do you agree with my currently suggested metadata.xml change with just type="developer|team"? [20:31:36] and project [20:31:50] proxies too or just assume they're developer-like too/ [20:32:10] no strong opinion about this [20:32:24] but don't name it "proxy-maintainer" if you keep them [20:32:26] ok [20:32:38] so i'll focus on changing this, and then try to preapre a new spec for metadata.yml [20:32:45] with short syntax to make people happy [20:32:46] developer = single person could be gentoo dev, proxied user or upstream. email ends with gentoo.org => gentoo-dev [20:33:54] or no domain => default to @gentoo.org => dev [20:34:41] even could keep the default domain in repos.conf [20:34:55] I mean layout.conf [20:35:10] yep [20:35:20] but that still makes stuff non-standalone [20:35:32] people can't copy metadata.xml without losing information [20:36:08] mgorny: is this necessary? [20:36:19] this happens a lot [20:36:20] why would you copy metadata.xml from another repo, without fixing maintainer [20:36:40] because people fork ebuilds and don't care about metadata? :P [20:36:43] not that such metadata is very useful [20:36:52] but well-formedness! [20:36:59] do you want to get maintainer mails from a forked ebuild? [20:37:27] if it's my bug, why not [20:37:30] but i'm weird [20:37:38] hm repos.conf idea is sexy because it hides emails [20:37:51] which results in probably less spam [20:37:55] I mean the default could well be @doesnotexist.org which is overridden in ::gentoo by @gentoo.org [20:37:59] good point [20:38:25] lol @ less spam in gentoo [20:38:31] yeah well [20:38:33] we should start by fixing bugzie :P [20:38:45] but it's too late i say [20:38:48] brb [20:38:53] i like the default domain in repos.conf [20:39:00] would make life easier for corp repos too [20:39:26] we may move on to default maintainer in repos.conf [20:39:41] in case of repos such as gnome overlay that are maintained by one team [20:40:41] true [20:40:46] thinmetadata :> [20:41:12] do we also want to move repo_name to layout.conf? [20:41:22] i mean, i think we already state this is the modern layout [20:41:47] mgorny: iirc it's deprecated, but there were some tools still checking for it [20:42:57] PMS requires repo_name [20:43:28] right so this will need a longer process [20:43:38] ok [20:43:45] I think we've collected a lot of ideas [20:44:02] so we should maybe table it for today [20:44:25] anyone still wants to say something about this topicß [20:44:26] ? [20:45:05] seems nto [20:45:12] any other things for the open floor? [20:45:38] qa elections are due [20:45:46] right [20:45:55] so we should send them a friendly reminder :) [20:45:56] I haven't seen any applications, so far [20:46:23] dilfridge: we asked for applications in the last qa meeting [20:46:37] :/ [20:47:17] so what's going to happen if there are no applicants? [20:48:16] that case is not foreseen, I fear [20:48:18] we vote unanimously on the old lead [20:48:29] revisiting my question, did we ever officially ban global helpers yet for EAPI 6? [20:48:36] it's not included on the wiki apge [20:48:37] good question [20:48:46] and it's in portage :) [20:48:57] radhermit: and in PMS, since EAPI 0 :) [20:49:11] radhermit: I'm checking the logs [20:49:37] mgorny: then why does portage check for EAPI when doing that? Or maybe I was imagining things [20:49:53] i recall this being discussed somewhere, but i don't remember if it was the Council, QA or just dev-portage [20:50:02] radhermit: for backwards compatibility [20:50:10] hmm [20:50:26] ok I can't find anything quickly in the summaries [20:50:33] we don't want to risk that for some reason uninstall of installed package will die [20:50:58] mgorny: but that's fine if it only dies in EAPI>=6 [20:51:06] yes [20:51:12] ok [20:51:31] shall we vote on this? [20:52:01] mgorny: radhermit: could you propose a wording please? [20:52:16] i don't think we need an extra vote for making portage conform to PMS in next EAPI [20:52:34] we would if we were to make it for all EAPIs [20:52:54] I tend to agree, but I also see it as unproblematic, so why not... [20:53:11] radhermit: what do you think? [20:53:31] vote: ban calling helpers in global scope in portage starting with EAPI=6 [20:54:32] anyone? [20:54:45] what? vote in open floor? [20:54:58] dilfridge wanted some voting today :) [20:55:00] shrug [20:55:21] we can pretend to be voting for dilfridge as QA lead [20:55:25] ulm: what's the alternative? discuss on the mailing list that portage should adhere to pms? [20:55:42] we already had a qa vote for this [20:55:53] ok then I dont care [20:55:55] do it [20:55:57] imho [20:56:05] so sure, the council can confirm, but what's the point? [20:56:14] hmm, didn't QA move some things to council anyway? [20:56:19] i don't recall from the meeting [20:56:28] seems there is general agreement that global helpers should be banned [20:56:30] radhermit: why are you asking about this? [20:56:42] -*- dilfridge is thinking what would be affected [20:57:08] mgorny: you voted yes :) [20:57:23] or rather, it was unanimous [20:57:35] i know but i'm asking if there were other matters maybe [20:58:21] QA vote was: Making global-scope 'use*', 'has_version' and 'best_version' fatal since EAPI 6 [20:58:42] and we postponed the decision about fatal in previous eapis [20:58:51] ok so a) we're likely not voting on it, and b) I doubt a vote is actually needed, since qa has spoken. [20:59:25] -*- dilfridge notes that the one obviousl consumer is toolchain multislot, but qa has likely known about that. [20:59:40] -*- ulm shudders [20:59:51] ok [21:00:14] I'm hungry, so unless anyone now still wants someting reeeeallly important... [21:00:40] hmm [21:00:56] we can talk about gcc[awt] if you want to [21:01:28] -*- dilfridge doesn't really want to... [21:01:30] dilfridge: it's an art to have a meeting ongoing for a full hour, with an agenda that is essentially empty :p [21:01:34] hehe [21:01:38] ok [21:01:51] mgorny: if you want that on the agenda, next time. [21:01:57] meeting closed. :P