path: root/meeting-logs/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: foo@gentoo.org, bar@gentoo.org
[20:18:30] <mgorny> even without -
[20:18:47] <dilfridge> mgorny: simpler, introduce a NEW tag that expands its contents to contents@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