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