Add missing logs 25/Oct/2015

2 files changed, 845 insertions, 0 deletions

diff --git a/meeting-logs/20151025.txt b/meeting-logs/20151025.txt
new file mode 100644
index 0000000..8500cb4
--- /dev/null
+++ b/meeting-logs/20151025.txt
@@ -0,0 +1,826 @@
+[00:00:00] - {Tageswechsel: Sonntag, 25. Oktober 2015}
+[20:01:14] <dilfridge> !expn council 
+[20:01:15] <willikins> council = jlec,k_f,blueness,dilfridge,rich0,williamh,ulm,
+[20:01:18] <dilfridge> meeting time! :)
+[20:01:21] -*- K_F here
+[20:01:21] * ulm has changed topic for #gentoo-council to: "Next meeting: now | http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 | https://wiki.gentoo.org/wiki/Project:Council | Agenda: https://archives.gentoo.org/gentoo-project/message/9b567a5ff7647a7991fdac4e166895d8"
+[20:01:26] -*- jlec here
+[20:01:28] -*- WilliamH here
+[20:01:29] <dilfridge> who's here
+[20:01:32] -*- ulm here
+[20:01:49] -*- rich0 here
+[20:02:15] <jlec> Round III
+[20:02:19] <dilfridge> exactly
+[20:02:24] <dilfridge> blueness?
+[20:03:10] <-- blueness (~blueness@gentoo/developer/blueness) hat das Netzwerk verlassen (Quit: blueness)
+[20:03:17] <dilfridge> ^ ^
+[20:03:30] <dilfridge> that's not what I wanted to see :D
+[20:03:35] --> blueness (~blueness@gentoo/developer/blueness) hat #gentoo-council betreten
+[20:03:35] *** Modus #gentoo-council +o blueness by ChanServ
+[20:03:46] * ulm has changed topic for #gentoo-council to: "Next meeting: now | http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 | https://wiki.gentoo.org/wiki/Project:Council | Agenda: https://archives.gentoo.org/gentoo-project/message/476866bae3b8f91b1601bc5f59b3ff9b"
+[20:03:56] <blueness> here with some network issues
+[20:04:01] <blueness> can you hear me now?
+[20:04:04] <dilfridge> yes
+[20:04:08] <dilfridge> excellent
+[20:04:10] <blueness> sorry guys
+[20:04:19] <dilfridge> so
+[20:04:22] <blueness> for the last 5 mins i've been talking to /dev/null
+[20:04:40] <dilfridge> 1. Projects, herds, etc. [10,11,12]
+[20:04:50] <dilfridge> [10] https://archives.gentoo.org/gentoo-project/message/179d5d298333dfeef45a6eb78f0d6f17
+[20:04:50] <dilfridge> [11] https://archives.gentoo.org/gentoo-project/message/70451197c3109e61ddd27e14a7bf89fa
+[20:04:50] <dilfridge> [12] https://archives.gentoo.org/gentoo-project/message/3cf270a336636b94187b2a2b8f1b7e7f
+[20:04:53] -*- WilliamH says kill herds
+[20:05:05] <K_F> I'm in favor of uniformity
+[20:05:06] <WilliamH> People aren't using them correctly anyway.
+[20:05:16] <WilliamH> A herd is a group of packages not devs
+[20:05:25] <mgorny> WilliamH: your info is not up to date
+[20:05:27] <jlec> yeah. projects with teams. No herds
+[20:05:37] <mgorny> WilliamH: definition was changed some time in the past
+[20:05:47] <dilfridge> link?
+[20:05:48] <WilliamH> mgorny: link please?
+[20:05:55] <ulm> mgorny: a herd always was a group of packages
+[20:05:58] <ulm> and still is
+[20:06:02] <mgorny> don't have it handy but someone pointed it out to me
+[20:06:13] <WilliamH> Herds need to die.
+[20:06:18] <jlec> mgorny: I still train recruits in the original meaning. would be good to get more informations
+[20:06:44] <mgorny> also: https://archives.gentoo.org/gentoo-project/message/f595f9fef4bce02c875e980ec5d21841
+[20:06:44] <ulm> well, if we're going to kill herds then it won't matter what the meaning was
+[20:06:53] <mgorny> here i split the topic into series of questions
+[20:07:07] <WilliamH> Kill herds, use maintainers.
+[20:08:06] <dilfridge> nice list
+[20:08:13] <WilliamH> I don't like all of the indirection we have.
+[20:08:17] <jlec> How about all the resulting problems when herds are gone?
+[20:08:23] <dilfridge> exactly
+[20:08:29] <dilfridge> jlec: means? example?
+[20:08:45] <rich0> Problems like knowing whether somebody is actually maintaining a package?
+[20:08:48] <jlec> dropping herds from metadata.xml breaks tools
+[20:08:54] <WilliamH> jlec: there are no problems, just convert everything to maintainers.
+[20:09:09] <WilliamH> jlec: fix them.
+[20:09:20] <dilfridge> define <project>=<herd>, provide a long transition time, ...
+[20:09:42] <WilliamH> dilfridge: project should also be an email address.
+[20:09:52] <blueness> if we convert all <herd> takes to <maintainer> tags in the metadata.xml, the nothing will breka.  i don't know if we want that
+[20:09:52] <WilliamH> dilfridge: <project>base-system@g.o</project>
+[20:09:53] <dilfridge> yeah then we get a fresh set of problems
+[20:10:07] <ulm> WilliamH: nope, that doesn't work
+[20:10:18] <dilfridge> WilliamH: that is imho silly since all projects are gentoo projects ere by def
+[20:10:24] <ulm> there's no mapping between projects and e-mail addresses
+[20:10:31] <dilfridge> (not yet)
+[20:10:52] <WilliamH> dilfridge: the assumption could be that project name = email address.
+[20:10:53] <K_F> project doesn't need email addresse in full, however, should define a shortname for each project that can be used as projA@proj.g.o (or similar)
+[20:11:20] <K_F> then <project>projA</project> should suffice
+[20:11:21] <WilliamH> <project>base-system</project> = base-system@g.o
+[20:11:27] <mgorny> K_F: yes, it does. bugzilla operates on e-mail addresses, so we need those for projects
+[20:11:29] <rich0> Just stick the project email as a maintainer.  If you want to know more about an email have another that tells you whether an email belongs to a project/uberproject/subproject/microproject or whatever, and everything about it.
+[20:11:31] <blueness> *sigh* we can't solve this during a council meeting, we need a solution to come to use that we can vote on
+[20:11:44] <ulm> I would be very much in favour of what was proposed in [11]
+[20:12:01] <WilliamH> Just make the project name an email address@g.o and be done with it ;-)
+[20:12:08] <ulm> plus considering the issues raised in [12]
+[20:12:10] <blueness> ulm:  what's 11?
+[20:12:13] <K_F> mgorny: it still doesn't need to be part of the project tag with a 1:1 mapping in a separate namespace
+[20:12:23] <ulm> [11] = dilfridge's proposal
+[20:12:24] <dilfridge> WilliamH: that does not work for obscure technical reasons
+[20:12:34] <WilliamH> There doesn't need to be a separate mapping for project names to email addresses.
+[20:12:37] <ulm> [12] = robbat2's reply
+[20:12:40] <mgorny> ulm: as i see it, that's just a rename with no real benefit
+[20:12:49] <mgorny> we can as well make herds.xml autogenerated from wiki
+[20:12:55] <ulm> mgorny: it is not a rename
+[20:13:02] <mgorny> same end result with compatibility kept
+[20:13:32] <ulm> because we group by projects (= set of devs) instead of herds (= set of packages)
+[20:13:42] <mgorny> ulm: ok, it's a reintroduction of the same idea with a bit different implementation
+[20:14:00] <WilliamH> ulm: kill herds, make project tag an email address. What reasons are there that shouldn't work?
+[20:14:26] <rich0> Main issue is that it changes the schema, so it is a pita to implement.
+[20:14:31] <mgorny> WilliamH: why create a new element when we have <maintainer/> element already? it means we have to change DTD, update all tools
+[20:14:32] <rich0> But, it works.
+[20:14:45] <rich0> I don't get why we don't just use maintainer
+[20:14:46] <dilfridge> and it is a lasting simplification
+[20:15:06] <WilliamH> mgorny: Actually what you are saying makes sense, and that was my original proposal. Kill herds and use maintainers.
+[20:15:09] <K_F> yeah, using maintainer works
+[20:15:16] <mgorny> as i said, adding type="project" to <maintainer/> is backwards-compatible
+[20:15:26] <dilfridge> WilliamH: that did not work in the past because x@gentoo.org was not available if x was a system username (cron, mysql, ...)
+[20:15:29] <WilliamH> mgorny: heh, ok, that makes sense.
+[20:15:36] <rich0> If i were designing a data model, I wouldn't define what an email address belongs to in every record that references it.
+[20:15:36] <ulm> mgorny: when we change it then we should do it right, and not compromise because some programs have to be minimally adapted
+[20:16:03] <mgorny> ulm: how do you define 'right'?
+[20:16:09] <rich0> ulm: I don't think that <project> is doing it right.
+[20:16:13] <ulm> just use <project> and be done
+[20:16:20] <mgorny> if we end up studying philosophy here, we won't get anywhere
+[20:16:22] <ulm> plus shortname in the wiki
+[20:16:27] <dilfridge> I still claim that we should avoid <maintainer type="project" property="highlycritical">bla</maintainer>
+[20:16:36] <rich0> dilfridge: I wouldn't do that either
+[20:16:37] <WilliamH> ulm: No, kill shortname, that is another remapping we don't need.
+[20:16:38] <dilfridge> and do <project>bla</project> 
+[20:16:48] <rich0> I'd just do <maintainer>games@gentoo.org</maintainer> and leave it at that.
+[20:16:55] <ulm> dilfridge: we should avoid xml there altogether, but that's a different topic
+[20:17:02] <rich0> If you want to know whether games@gentoo.org is a project or not, just stick that someplace else.
+[20:17:12] <dilfridge> <maybe></maybe>
+[20:17:13] <blueness> hmmm rich0  i think you may be onto something
+[20:17:13] -*- WilliamH is with rich0, maybe <maintainer type=project>games@gentoo.org</maintainer>
+[20:17:25] <mgorny> dilfridge: if you have <project/> and <maintainer/> that're both used to define maintainers, that's not a valid data model
+[20:17:28] <WilliamH> That way you know that maintainer is a project.
+[20:17:29] <rich0> Then one day games@gentoo.org can be a proejct, the next it could be a herd, and the next it can be an initiative.
+[20:17:37] <ulm> I am strongly opposed against using e-mail addresses to identify projects
+[20:17:51] <dilfridge> mgorny: not better or worse than current <herd> and <maintainer>
+[20:18:02] <rich0> WilliamH: just look up what it is in another file.
+[20:18:17] <mgorny> dilfridge: as ulm said, we are supposed to do it right, not 'as bad as it is right now'
+[20:18:19] <rich0> The nice thing about software is that you can do a join in microseconds...
+[20:18:21] <WilliamH> ulm: why?
+[20:18:28] <ulm> it's like using the telephone number to identify a person
+[20:18:34] <WilliamH> ulm: I don't want to have to look up the email address for a project somewhere else.
+[20:18:43] <rich0> ulm: I can buy that argument
+[20:18:58] <ulm> rich0: it's the exact analogue :)
+[20:19:02] <mgorny> ulm: you're using e-mail address to identify developers already. do you plan to change that?
+[20:19:02] <WilliamH> ulm: we do that all the time.
+[20:19:03] <rich0> Main risk is if a project needs to change its email address, and we're using it as a unique ID.
+[20:19:09] <rich0> Just give each project a GUID.  :)
+[20:19:23] -*- rich0 ducks
+[20:19:27] <ulm> mgorny: no, I'm using nicks to identify developers
+[20:19:28] <mgorny> rich0: developer change usernames and e-mail addresses too
+[20:19:48] <mgorny> ulm: what about proxied maintainers?
+[20:20:05] <WilliamH> ulm: nick@g.o = email address
+[20:20:29] <mgorny> of course it would be nice to identify people by name
+[20:20:35] <mgorny> but it would be also terribly inconvenient
+[20:20:42] <ulm> mgorny: oh well, sometimes we don't even know their name, or if they're a person :)
+[20:20:46] <rich0> mgorny: the nice thing about guids is that we'll never run out.  proxied maintainers can ask for as many as they need.  :)
+[20:21:10] -*- dilfridge tries to remember his IBAN
+[20:21:12] <WilliamH> ulm: that's another issue all together. :p
+[20:21:17] <mgorny> rich0: you just volunteered to rewrite bugzilla
+[20:22:04] <jlec> Is there an argument to move projects to foo@proj.gentoo.org?
+[20:22:07] <rich0> Well, I think we can all agree that projects/maintainers/whatever need SOME kind of identifier we use.
+[20:22:30] <K_F> jlec: avoids namespace collission with system services (mysql@proj.g.o works)
+[20:22:32] <mgorny> and i think we can agree that nobody's going to change bugzilla not to use e-mail addresses for that
+[20:22:37] <rich0> I think email is as convienient as any, but I'm not opposed to a short name.
+[20:22:38] <dilfridge> jlec: the main and only reason for that is namespace collissions
+[20:23:08] <jlec> yes and we would have a mark in the email adress to identify projects
+[20:23:08] <K_F> and it is fresh namespace, so we can set up names correctly without worrying about existing names
+[20:23:14] <K_F> then do forwards as appropriate
+[20:23:18] <dilfridge> this way one could guarantee that cron@proj.gentoo.org is available
+[20:23:25] <ulm> dilfridge: could you try to somewhat focus this discussion please? otherwise we'll achieve nothing today and should better be deferring it to mailing lists again
+[20:23:27] <jlec> So we could simply go for maintainers and would know which are projects
+[20:23:42] <dilfridge> sure, I just wanted to keep it running for a bit, but we can do that now
+[20:23:48] <dilfridge> ok
+[20:24:00] <dilfridge> let's try to make some decisions
+[20:24:05] <WilliamH> I like the idea of <maintainer type=project></maintainer>
+[20:24:08] <dilfridge> first of all
+[20:24:26] <dilfridge> let's talk about the word "herd" alone
+[20:24:33] <jlec> okay
+[20:24:39] <WilliamH> herds are dead
+[20:24:54] <jlec> ++
+[20:24:56] <mgorny> words don't really matter
+[20:24:56] <dilfridge> Do we need the distinction between herd (as used, not as defined) and project/team?
+[20:25:05] -*- WilliamH votes no
+[20:25:24] <blueness> well wait, the question is ambiguous
+[20:25:29] <dilfridge> ok I suggest the following motion
+[20:25:35] <jlec> I don't see a problem to simply join a team instead of being on a herd alias
+[20:25:38] <blueness> there is a functioning difference between them
+[20:25:52] <WilliamH> blueness: the concept of herds died long ago
+[20:25:55] <blueness> so do we want to keep that difference and re-encode it differently
+[20:26:28] <WilliamH> blueness: A herd is a group of packages... developers maintain herds.... developers are not members of herds.
+[20:26:40] <mgorny> how about: do we want to have developer groups that don't form a project (i.e. don't have wiki page)?
+[20:26:44] <blueness> or are you asking whether we want to just keep <herd>  i'm for removing <herd> but i want that information remapped
+[20:27:03] <dilfridge> A) The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package should be maintained by a project. A current herd maintainer should become member of the corresponding project. 
+[20:27:11] <WilliamH> blueness: there is nothing relevant about that information.
+[20:27:12] <jlec> I am for simplicity and consolidate both
+[20:27:19] <blueness> dilfridge:  that sounds better
+[20:27:20] <K_F> dilfridge: s/should/could/
+[20:27:35] <K_F> single maintainer is still ok
+[20:27:52] <jlec> dilfridge: B?
+[20:27:55] <dilfridge> A') The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package could be maintained by a project. A current herd maintainer should become member of the corresponding project. 
+[20:27:58] <WilliamH> Right, single maintainers are still ok.
+[20:28:02] <rich0> single maintainer is to be preferred if the project isn't really a project.
+[20:28:21] <K_F> (a native english speaker should comment on could vs can)
+[20:28:27] <ulm> rich0: why?
+[20:28:28] <dilfridge> can is better
+[20:28:28] <rich0> Too many packages are in herds simply because...herds!
+[20:28:31] <blueness> dilfridge:  will that be something maintainers ahve to do, or will we automate taht
+[20:28:48] <ulm> a project page can still provide documentation, even with a single maintainer
+[20:28:52] <rich0> If a group of devs is actually coordinating their actions and working as a team, they should by all means do so.
+[20:29:12] <rich0> When a herd/project/whatever is just a tag on an ebuild that says nothing about how it is REALLY maintained, it should go.
+[20:29:29] <dilfridge> A'') The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package can be maintained by a project. A current herd maintainer should become member of the corresponding project. 
+[20:29:32] <K_F> rich0: won't we accomplish that by using project structure?
+[20:29:50] <rich0> K_F: yes
+[20:30:00] <mgorny> dilfridge: 'by zero or more projects and/or people'? ;-p
+[20:30:13] -*- WilliamH agrees with mgorny
+[20:30:14] <dilfridge> I think if someone's really interested s/he will join the project
+[20:30:26] <dilfridge> mgorny: no, because "can" means it can also be different
+[20:30:29] <WilliamH> We don't mandate that everyone be part of a project.
+[20:30:37] <rich0> I'm just saying that not every package that is in a herd today should necessarily end up in a project.  Some might just go to maintainer-wanted.
+[20:30:57] <dilfridge> just the possibility exists that a project maintains packages
+[20:31:02] <mgorny> dilfridge: well, there were herds that were supposed to be 1:1 to projects, sub-herds for projects and totally disjoint from projects
+[20:31:06] <ulm> hm, m-w is a herd though
+[20:31:09] <K_F> rich0: ah, gotcha, you were thinking  of automation question. Yeah, I'm in favor of not automating it as well to actually clean up things
+[20:31:24] <mgorny> so in some cases, we just replace herd with project, in other we may create new projects or inline developers
+[20:31:43] <dilfridge> mgorny: that's kinda the next question, but imho it is cheap to generate subprojects
+[20:32:05] <ulm> dilfridge: not if every subproject must elect a lead :)
+[20:32:21] <rich0> ulm: we've already decided that projects don't _have_ to elect a lead.
+[20:32:22] <mgorny> dilfridge: exactly. i'd say you should be able to make this motion simpler
+[20:32:23] <K_F> a question then is whether there should be some formal structure to email addresses of sub-projects
+[20:32:39] <K_F> projA-subX etc
+[20:32:42] <mgorny> K_F: you are going offtopic
+[20:32:49] <dilfridge> you know, I elected myself lead of the vmware project really quickly
+[20:33:04] <WilliamH> The concept of herds is deprecated and the <herd> tag in metadata should be converted to an appropriate <maintainer> tag or dropped.
+[20:33:17] <ulm> or <project> tag
+[20:33:30] <dilfridge> WilliamH: you are combining problem A with problem B
+[20:33:48] <rich0> dilfridge++ - one step at a time
+[20:34:02] <dilfridge> so anyone has an improvement on A'' ?
+[20:34:03] <WilliamH> So can we all agree then that <herd> is deprecated?
+[20:34:09] <dilfridge> no
+[20:34:18] <dilfridge> because we're not talking about that yet.
+[20:34:20] <blueness> dilfridge:  its sounding good but before we vote can you state it agian
+[20:34:43] <blueness> WilliamH:  we cannot agree <herd> is deprecated unconditionally
+[20:34:46] <dilfridge> A''') The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package can be maintained by a project. A current herd maintainer should become member of a corresponding project. 
+[20:34:51] <dilfridge> (minor wording change)
+[20:35:09] <WilliamH> s/project/project or developer/
+[20:35:10] <blueness> that works for me
+[20:35:27] <K_F> works for me
+[20:35:27] <mgorny> dilfridge: how about: The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package can be maintained by a project. A current herd maintainer can become a member of the corresponding project or individual maintainer.
+[20:35:34] <mgorny> changed last sentence
+[20:35:40] <blueness> WilliamH:  that's no ened for that change, read it carefully ... "can"
+[20:35:41] <ulm> wfm
+[20:35:42] <mgorny> fix my english now ;-)
+[20:35:50] <jlec> I am not sure whether we should directly integrate the transition
+[20:35:56] <jlec> Otherwise I am for it
+[20:36:15] <blueness> mgorny: that version is fine too
+[20:36:19] <jlec> *suggestion for transition
+[20:36:21] <dilfridge> mgorny: not sure if we need that
+[20:36:22] <rich0> I'm fine with it
+[20:36:26] <dilfridge> but I dont oppose
+[20:36:36] <dilfridge> so
+[20:37:12] <dilfridge> A'''' The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package can be maintained by a project. A current herd maintainer can become a member of the corresponding project or take over individual maintainership.
+[20:37:31] <dilfridge> vote please
+[20:37:36] <ulm> doesn't really make sense like this. if the package is maintained by a project, then why should there be an individual maintainer in addition?
+[20:37:38] -*- K_F aye
+[20:37:48] -*- ulm no (because of the bad wording)
+[20:37:48] -*- blueness yes
+[20:37:56] <dilfridge> well
+[20:38:02] <dilfridge> ulm is right
+[20:38:03] -*- WilliamH has issues with the wording
+[20:38:10] <rich0> ulm: can't anybody choose to co-maintain anything at any time?
+[20:38:12] <dilfridge> so let's get back to previous version
+[20:38:13] <WilliamH> hang on a sec let me work on it.
+[20:38:23] <ulm> dilfridge: penultimate wording was better IMHO
+[20:38:28] <dilfridge> A''') The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package can be maintained by a project. A current herd maintainer should become member of a corresponding project. 
+[20:38:30] <mgorny> ulm: some people may decide not to join the project but maintain some packages from it
+[20:38:49] <ulm> mgorny: note the word "can"
+[20:39:01] <dilfridge> "should" does also not mean "must"
+[20:39:10] <blueness> ulm:  in english it might be better to use the word "may" there
+[20:39:12] <ulm> we cannot describe all possible alternatives
+[20:39:20] <blueness> it has the sense of there being an options about it
+[20:39:23] <mgorny> "should" indicates it's the correct action
+[20:39:27] <blueness> "a package maybe be maintained"
+[20:39:44] <blueness> err ... "a package may be maintained"
+[20:39:56] <WilliamH> Just remove the second sentence from a. then we come up with the replacement as b.
+[20:39:57] <blueness> rich0:  ^^^ opinion or too subtle grammatically
+[20:40:20] <dilfridge> A5) The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package may be maintained by a project.
+[20:40:24] <rich0> I'd say may
+[20:40:31] <dilfridge> can we vote on A5 please?
+[20:40:39] -*- mgorny is fine with A5
+[20:40:40] -*- K_F A5 aye
+[20:40:40] <WilliamH> restate it please?
+[20:40:43] -*- ulm yes A5
+[20:40:46] <dilfridge> A5) The concept of "herds" is abandoned, and the usage of the term deprecated. As a replacement, a package may be maintained by a project.
+[20:40:50] -*- dilfridge yes A5
+[20:40:57] -*- rich0 yes
+[20:41:17] -*- jlec yes
+[20:41:25] -*- WilliamH says s/project/project or maintainer/
+[20:41:45] <WilliamH> If you do that you have my vote
+[20:41:53] <ulm> WilliamH: a package can already now have a single maintainer, so nothing changes there
+[20:41:54] <dilfridge> WilliamH: that makes no sense
+[20:42:09] <mgorny> WilliamH: that's not necessary since it states 'as a replacement [for herd]'
+[20:42:15] <dilfridge> ok we have 5 yes
+[20:42:20] <dilfridge> motion passed
+[20:42:20] -*- blueness yes
+[20:42:23] <dilfridge> 6 yes
+[20:42:23] -*- WilliamH yes
+[20:42:28] <dilfridge> 7 yes, unanimous
+[20:42:32] <blueness> (sorry i'm having connection issues)
+[20:42:33] <dilfridge> next problem
+[20:43:11] <dilfridge> do we want to keep the <herd> tag or deprecate it for something else?
+[20:43:22] <WilliamH> deprecate it.
+[20:43:31] <mgorny> note that we still need a data format for projects, so we can reuse herds.xml for that
+[20:43:32] <ulm> kill it with fire
+[20:43:33] <dilfridge> I think we should deprecate it
+[20:43:36] <jlec> A5 says it is deprecated
+[20:43:54] <dilfridge> ok
+[20:44:03] <jlec> Give a transition period to allow fixing tools
+[20:44:07] <blueness> deprecate it
+[20:44:08] <dilfridge> then the question is, how do we want to replace it
+[20:44:19] <dilfridge> options are 
+[20:44:21] <WilliamH> dilfridge: you don't.
+[20:44:32] <ulm> mgorny: herds.xml would have to be renamed though, like projects.xml
+[20:44:37] <dilfridge> * introduce a new tag <project>
+[20:44:43] <WilliamH> dilfridge: I still don't see what information we lose by killing it.
+[20:44:44] <mgorny> ulm: what for? that doesn't add any value
+[20:44:50] <dilfridge> a introduce a new tag <project>
+[20:44:51] <ulm> mgorny: the term "herd" is deprecated
+[20:44:52] <dilfridge> b introduce a new tag <project>
+[20:44:54] <dilfridge> err
+[20:45:08] <WilliamH> dilfridge: why not do that as a maintainer type?
+[20:45:11] <dilfridge> b introduce a type of <maintainer>< ...>
+[20:45:13] <rich0> do we get to choose a or b?
+[20:45:41] <WilliamH> ulm: the concept of herds is deprecated.
+[20:45:42] <blueness> dtd = zero or more project tags, zero or more maintainers, at least one of project or maintainer
+[20:46:01] <ulm> WilliamH: so we shouldn't use the word either, to avoid confusion
+[20:46:09] <mgorny> a kinda sucks since it still has the issues that came from having <herd>
+[20:46:13] --> pacho2 (~pacho@gentoo/developer/pacho) hat #gentoo-council betreten
+[20:46:20] <dilfridge> mgorny: explain
+[20:46:23] <WilliamH> If I'm going to assign a bug to a project...
+[20:46:34] <WilliamH> I see <project>name</project>
+[20:46:43] <WilliamH> I want to assign the bug to name@g.o
+[20:46:44] <mgorny> dilfridge: like right now you always assume <maintainer> is more important than <herd>
+[20:46:52] <mgorny> (unless extra notes say otherwise)
+[20:46:58] <mgorny> having one element means we can really rely on the order
+[20:47:16] <dilfridge> I see
+[20:47:19] <WilliamH> I don't want the indirection of having <project> </project> not be an email address.
+[20:47:24] <ulm> mgorny: we can still rely on the order even with several elements
+[20:47:28] <WilliamH> if we have <project>
+[20:47:42] <dilfridge> WilliamH: let's keep the question of the e-mail addresses for the next step
+[20:47:50] <mgorny> ulm: except when people are still used to meaning of <herd> and will apply the same assumptions to <project>
+[20:47:59] <dilfridge> we can't do everything in one go, because otherwise we will never decide anything
+[20:47:59] <-- pacho2 (~pacho@gentoo/developer/pacho) hat #gentoo-council verlassen
+[20:48:14] -*- ulm likes <project>
+[20:48:14] <dilfridge> ok
+[20:48:16] <rich0> mgorny++ I was thinking about what happens when you have two projects and two maintainers and they go back-and-forth in ordering.
+[20:48:25] <mgorny> let's be honest. in any sane data model, there can't be two elements meaning the same thing (maintainership)
+[20:48:27] <WilliamH> mgorny: makes a good point. if we just use maintainers for everything we can rely on the order of the elements.
+[20:48:37] <dilfridge> I think we have agreement that we need some replacement, so let's just vote how it should look like in principle
+[20:48:57] <mgorny> we can decide how <maintainer> looks inside, but there should be only one element for that
+[20:49:26] <dilfridge> B do we want a "<project>bla</project>" or b "<maintainer><project>bla ..." ?
+[20:49:33] <jlec> I think we should go for maintainer with type. no project with mgorny's argument.
+[20:49:50] <ulm> keep it short and simple please
+[20:49:50] <jlec> *because of
+[20:49:58] -*- WilliamH is with jlec 
+[20:50:01] <ulm> no complicated xml abominations
+[20:50:25] <mgorny> ulm: metadata is meant for machines, correctness is more important than shortness
+[20:50:29] <rich0> Personally I'd prefer a simple maintainer tag and that's it.
+[20:50:30] <K_F> yeah, if we go for <maintainer I'm in favor of type rather than sub-element
+[20:50:37] <dilfridge> so how would that look like in valid xml? <maintainer type="project">bla
+[20:50:49] <ulm> mgorny: except that I edit metadata.xml manually most of the time
+[20:50:49] <jlec> ulm: I am all with you there. But mgorny is right
+[20:50:55] <rich0> I'd prefer just <maintainer> and no attributes.
+[20:51:00] <WilliamH> dilfridge: yes.
+[20:51:09] <jlec> dilfridge: yes, same can go for proxy etc too
+[20:51:10] <ulm> dilfridge: please beware us of such
+[20:51:15] <rich0> If a human reads it, they'll know whether the maintainers are projects by their names.
+[20:51:19] <jlec> rich0: me too
+[20:51:19] <blueness> rich0:  i agree, no attributes to maintainer
+[20:51:19] <dilfridge> B2 do we want a) "<project>bla</project>" or b) "<maintainer><project>bla ..." or c) "<maintainer type="project">bla" ?
+[20:51:29] <mgorny> how about we go for <maintainer type="project">...</maintainer> with current xml structure
+[20:51:30] <rich0> If a computer reads it, then it can read the appropriate source to determine what they are.
+[20:51:36] <mgorny> and aim for replacing metadata.xml with simpler format in the future?
+[20:51:46] <jlec> mgorny ++
+[20:51:49] -*- WilliamH is with mgorny 
+[20:51:53] <WilliamH> and jlec
+[20:51:54] <mgorny> like yaml: maintainer: - Foo Bar <foobar@gentoo.org>
+[20:51:56] <rich0> dilfridge: you left out d> <maintainer>bla</maintainer>
+[20:52:18] <jlec> Do we need ot identify projects?
+[20:52:27] <jlec> If not we would really reduce the problem.
+[20:52:44] <jlec> then d) would be the best solution
+[20:52:52] <dilfridge> B2 do we want a) "<project>bla</project>" or b) "<maintainer><project>bla</project></maintainer>" or c) "<maintainer type="project">bla</maintainer>" or d) "<maintainer>bla</maintainer>" ?
+[20:52:56] <dilfridge> B3 do we want a) "<project>bla</project>" or b) "<maintainer><project>bla</project></maintainer>" or c) "<maintainer type="project">bla</maintainer>" or d) "<maintainer>bla</maintainer>" ?
+[20:52:57] <mgorny> jlec: i'd say the goal here is to be able to tell who to ping on irc, saying lightly
+[20:53:08] <mgorny> jlec: but you can identify project by specific e-mail address even
+[20:53:14] <dilfridge> ok B3 has all the options, may I ask for a vote?
+[20:53:17] <mgorny> since person & project e-mail addresses can't ocllide
+[20:53:20] <dilfridge> a,b,c,d
+[20:53:32] <mgorny> dilfridge: i think d is unclear now
+[20:53:36] -*- rich0 d
+[20:53:38] <dilfridge> sigh
+[20:53:44] <dilfridge> so what is d supposed to mean?
+[20:54:00] <dilfridge> (hold the voting)
+[20:54:03] <rich0> d means you put the identifier in the maintainer tag and don't qualify what it means
+[20:54:11] <mgorny> rich0: identifier as in e-mail address?
+[20:54:16] <WilliamH> d works because you can describe maintainers
+[20:54:19] <rich0> mgorny: we didn't get that far
+[20:54:24] <mgorny> oh
+[20:54:35] <mgorny> sorry
+[20:54:46] <WilliamH> <maintainer><name>accessibility project></name><email>...</email></maintainer>
+[20:54:56] -*- dilfridge thinks this is horrible
+[20:54:59] <dilfridge> but anyway
+[20:55:00] <rich0> but, assuming for argument that we agree on email, it might be <maintainer>toolchain@gentoo.org</maintainer>
+[20:55:07] <blueness> yeah now i'm confuse
+[20:55:08] <blueness> d
+[20:55:37] <dilfridge> can anyone give a full example for c or d please?
+[20:55:45] <WilliamH> rich0: The maintainer tag has email and name subtags
+[20:55:55] <rich0> dilfridge: ok, hang on
+[20:56:10] <rich0> <maintainer><email>toolchain@gentoo.org</email></maintainer>
+[20:56:17] <blueness> rich0:  that's athw i'm confused about, what are the allowed subtags?
+[20:56:17] <dilfridge> ^ d
+[20:56:18] <ulm> dilfridge: AIUI c = <maintainer type="project">emacs</maintainer>
+[20:56:24] <dilfridge> ^ c
+[20:56:25] <dilfridge> ok
+[20:56:27] <dilfridge> got it
+[20:56:31] <dilfridge> rewriting
+[20:56:32] <rich0> but, I'm fine with changing the subtags
+[20:56:35] <mgorny> we can also mix c & d
+[20:56:43] <rich0> I figured we weren't voting on the subtags yet
+[20:56:47] <mgorny> i.e. type="" added but preserving current substructure
+[20:56:51] <WilliamH> All, there already is a way things can happen with maintainers...
+[20:57:00] <WilliamH> hold a sec let me type
+[20:57:02] <rich0> Otherwise we can probably add about 7 more options
+[20:57:07] <mgorny> dilfridge: maybe try to vote on two vs one tag first
+[20:57:07] <WilliamH> <maintainer>
+[20:57:09] <dilfridge> B4 do we want a) "<project>bla</project>" or b) "<maintainer><project>bla</project></maintainer>" or c) "<maintainer type="project">bla</maintainer>" or d) "<maintainer><email>bla@gentoo.org</email></maintainer>" ?
+[20:57:20] <WilliamH> HANG ON A SEC...
+[20:57:29] <WilliamH> I can't keep up ;-)
+[20:57:33] -*- dilfridge hanging
+[20:57:37] -*- ulm a (1st choice) c (2nd choice)
+[20:57:43] <WilliamH> <maintainer>
+[20:57:55] <WilliamH> <name>Base System Project</name>
+[20:58:09] <WilliamH> <email>base-system@gentoo.org></email>
+[20:58:16] <WilliamH> </maintainer>
+[20:58:23] <rich0> I suggest we don't vote on name/email/etc, because we're divided on that as well.
+[20:58:25] <WilliamH> That's completely valid as things stand right now.
+[20:58:27] <ulm> WilliamH: that doesn't tag it as project or developer
+[20:58:34] <dilfridge> WilliamH: do you really want to type that much?
+[20:58:39] <WilliamH> ulm: does that matter?
+[20:58:56] <dilfridge> anyway, that's basically the same as d
+[20:58:57] <ulm> WilliamH: projects can become empty
+[20:59:04] <blueness> ulm:  correct, we need to distinguish somehwo between project and maintainer
+[20:59:21] <WilliamH> <maintainer type="project">
+[20:59:22] <WilliamH> ...
+[20:59:26] <WilliamH> </maintainer>
+[20:59:33] <ulm> that's c basically
+[20:59:33] <blueness> that's c
+[20:59:37] <dilfridge> ok unless someone comes up with another item for my a-d list, I'll call the vote again
+[20:59:46] -*- ulm a
+[20:59:47] <dilfridge> B4 do we want a) "<project>bla</project>" or b) "<maintainer><project>bla</project></maintainer>" or c) "<maintainer type="project">bla</maintainer>" or d) "<maintainer><email>bla@gentoo.org</email></maintainer>" ?
+[20:59:47] <rich0> dilfridge: I don't care for any of them
+[21:00:02] <rich0> I would keep them more consistent
+[21:00:12] <WilliamH> d folds into c
+[21:00:15] <rich0> make d) "<maintainer>bla</maintainer" to be consistent with the others
+[21:00:15] <mgorny> e) <maintainer type="project"><email>...
+[21:00:29] <WilliamH> mgorny: that's c
+[21:00:34] <blueness> that's what i'm reading c as
+[21:00:36] <dilfridge> €
+[21:00:42] <blueness> CEEEE!
+[21:00:47] <mgorny> well, d has subel, so that's really confusing ;-p
+[21:00:56] <rich0> I think we need to fix d
+[21:01:01] <blueness> mgorny:  i know its a bit ambiguious
+[21:01:04] <dilfridge> ok then let's fix d
+[21:01:09] <dilfridge> write it down please
+[21:01:11] <K_F> so are we saying c would need the sub element to be valid? or can we just use the project name in that context?
+[21:01:12] <WilliamH> mgorny: a maintainer can have a name and email address as it stands
+[21:01:23] <rich0> d) <maintainer>bla</maintainer>
+[21:01:29] <WilliamH> mgorny: c just adds type="project"
+[21:01:29] <rich0> That is the same format as the other 3
+[21:01:30] -*- dilfridge is for a by the way
+[21:01:36] <mgorny> K_F: all type=""s of maintainer have to have the same structure, i think
+[21:01:37] <blueness> K_F:  i'm interpreting c as just like our current maintainer but with the extra attribute in there
+[21:01:44] <rich0> Any of the other 3 could contain <email> as well
+[21:01:51] <rich0> or not
+[21:01:52] -*- K_F a
+[21:01:53] -*- WilliamH votes for c
+[21:01:57] -*- rich0 d
+[21:02:00] -*- ulm a
+[21:02:00] -*- blueness c
+[21:02:03] -*- jlec d
+[21:02:09] <WilliamH> d = c
+[21:02:30] <dilfridge> ok now we have a vote, we just need to figure out what it means
+[21:02:31] <WilliamH> show d again...
+[21:02:41] <rich0> dilfridge: it doesn't mean anythign - no majority
+[21:02:41] <dilfridge> 3x a, 2x c, 2x d
+[21:03:24] <mgorny> i agree with williamh that c is basically d with extra type="" tag
+[21:03:28] <jlec> That means we are basically substituting herds by project
+[21:03:40] <ulm> condorcet vote please :p
+[21:03:48] <dilfridge> ulm: please you do that
+[21:04:13] <mgorny> dilfridge: i'd say we can reduce that to <project> vs <maintainer>, then vote on extra type="" attribute
+[21:04:24] <dilfridge> that makes sense
+[21:04:24] <mgorny> (if <maintainer> wins)
+[21:04:31] <dilfridge> so let's ask a more simple question
+[21:04:43] <ulm> mgorny: that would be bending of the vote
+[21:05:05] <dilfridge> well, I dont like it either, but
+[21:05:26] <dilfridge> it is kinda logical
+[21:05:27] <mgorny> well, my previous points apply to using two elements instead of one
+[21:05:30] <blueness> unfortunately the rules of the voting were unclear we still have to vote, its not clear how we were going to judge a winner
+[21:05:33] <mgorny> so it's the kind of vote to do first
+[21:05:56] <dilfridge> so, let's scratch B because it was a mess, and ask the following question
+[21:05:58] <rich0> Ultimately, I think we need SOMETHING that 4 of us can agree with
+[21:06:16] <rich0> If a majority don't agree with the final outcome, it doesn't matter how we got there.
+[21:06:28] <dilfridge> C: New <project> tag, or add something to existing <maintainer> tag?
+[21:06:35] -*- dilfridge project
+[21:06:38] <blueness> ulm:  are you not okay with mgorny 's two tier voting?
+[21:06:52] -*- WilliamH maintainer
+[21:06:59] <ulm> dilfridge: you could ask which of the alternatives a c d people like least
+[21:07:10] <rich0> I think condorcet would actually be informative, but that isn't going to be quick to setup
+[21:07:29] <rich0> ulm: ah, and exercise in game theory :)
+[21:07:44] <WilliamH> I think the current question is a good way to go.
+[21:07:46] -*- ulm likes d least, btw
+[21:08:28] <WilliamH> If we introduce a project tag, I feel strongly that tag should include an email address
+[21:08:43] <WilliamH> <project>projname@g.o</project>
+[21:08:44] <mgorny> as i see it, 4 people were for having one tag, and 3 for two tags but without direct vote i can't really judge that 100%
+[21:08:46] <dilfridge> in the end I dont care that much, except I dont like too many email addresses in there
+[21:09:02] -*- WilliamH votes for maintainer
+[21:09:06] <mgorny> we can discuss what's in the tag later
+[21:09:07] <K_F> dilfridge: ditto
+[21:09:10] <WilliamH> it keeps it simple. one element...
+[21:09:13] <dilfridge> C: New <project> tag, or add something to existing <maintainer> tag?
+[21:09:16] <dilfridge> ^ please
+[21:09:20] -*- rich0 maintainer
+[21:09:22] -*- dilfridge project
+[21:09:25] -*- K_F project
+[21:09:26] -*- WilliamH maintainer
+[21:09:27] -*- blueness project
+[21:09:29] -*- jlec maintainer
+[21:09:32] -*- ulm project
+[21:09:49] <dilfridge> that's 4x project and 3x maintainer
+[21:10:09] <dilfridge> which means a lot of questions just magically resolved themselves. :)
+[21:10:17] <mgorny> and we're back to square one
+[21:10:22] <dilfridge> next question
+[21:10:25] <jlec> :)
+[21:10:26] <mgorny> does the order of elements matter now or not?
+[21:10:27] <rich0> dilfridge: assuming you get 4 votes for the final proposal :)
+[21:10:32] <dilfridge> no
+[21:10:32] <WilliamH> That means now that the project must be an email address @g.o
+[21:10:47] <rich0> order should matter
+[21:10:54] <ulm> rich0: +1
+[21:11:14] <dilfridge> D: what goes into the <project> tag?  a project shortname or an e-mail address?
+[21:11:21] <ulm> no e-mail addresses in there please
+[21:11:28] -*- K_F project shortname
+[21:11:31] <ulm> these are all potential spam magnets
+[21:11:33] -*- WilliamH email address
+[21:11:33] -*- dilfridge project shortname
+[21:11:37] -*- ulm shortname
+[21:12:06] -*- blueness shortname
+[21:12:07] -*- rich0 abstain
+[21:12:09] <WilliamH> You realize short names don't help bug wrangling right?
+[21:12:22] -*- jlec abstain
+[21:12:26] <dilfridge> that means 4x shortname, 1x e-mail, 2x abstain
+[21:12:47] <dilfridge> E: do we want a 1:1 mapping of a new e-mail address to the project shortname?
+[21:12:53] <WilliamH> That also means that projects can't have bugs assigned to them
+[21:13:13] -*- K_F E: yes
+[21:13:18] -*- WilliamH yes
+[21:13:19] -*- blueness yes
+[21:13:23] -*- dilfridge E: yes definitely
+[21:13:24] -*- ulm no
+[21:13:37] <rich0> Any reason it might not be 1:1?
+[21:13:50] -*- jlec no
+[21:14:01] <ulm> dilfridge: amapping from shortname to e-mail address makes sense, but not the other direction
+[21:14:05] <ulm> *a mapping
+[21:14:14] <rich0> Could there be a reason to have more than one email for a project, or more than one project for an email?  I'm leaning towards 1:1 but I don't want to gloss over that if the shortname is the unique id
+[21:14:45] <ulm> rich0: e.g. emacs and gnu emacs projects share a common e-mail address
+[21:14:45] <dilfridge> ok so maybe I misformulated, the motion passed but I would still like to know what's the problem
+[21:14:51] <WilliamH> We use email aliases for that mapping already.
+[21:14:58] <ulm> having two addresses would just confuse users
+[21:15:00] <blueness> ulm do you mean a 1:N mapping shortname to emails
+[21:15:14] <WilliamH> All we've affectively done with all of this is
+[21:15:30] <WilliamH> <here>name</herd> is now <project>name</project>
+[21:15:46] <ulm> blueness: left-total from shortname to e-mail
+[21:15:57] <blueness> ulm:  i can agree tot hat
+[21:16:15] <rich0> WilliamH: well, we did get rid of the herd-vs-project confusion, but I've already said I don't think this is the ideal state, fwiw.  :)
+[21:16:28] <dilfridge> huh?
+[21:16:54] <ulm> dilfridge: why do we need anything beyond the e-mail address on the project's wiki page
+[21:17:00] <WilliamH> All we've done with all of this bikeshedding is say that we should change <herd>name</herd> to <project>name</project>
+[21:17:05] <ulm> maybe mirrored
+[21:17:10] <dilfridge> ulm: explain please, not sure what you mean with left-total
+[21:17:21] <K_F> ulm: ease bug-wrangling
+[21:17:23] <rich0> WilliamH: well, we've only had 80min to work on this :)
+[21:17:27] <ulm> dilfridge: every project should have an e-mail address
+[21:17:38] <K_F> ulm: if shortname always maps you can do shortname -> shortname@proj.g.o
+[21:17:48] <K_F> without an additional alias table lookup
+[21:18:01] <mgorny> dilfridge: how about voting for shortname@proj.g.o? it sounds like a good idea independently of everything else
+[21:18:03] <rich0> Is there a bugzilla issue with having anything other than 1:1 ?
+[21:18:15] <WilliamH> K_F: you have to have the alias lookup on the email side; that isn't going anywhere.
+[21:18:28] <K_F> WilliamH: why?
+[21:18:34] <WilliamH> K_F: because a project can have multiple members.
+[21:18:43] <rich0> If emacs and gnuemacs have the same email address, will that cause bugzilla issues?
+[21:18:47] <K_F> WilliamH: that email alias is auto-generated
+[21:19:01] <K_F> so that is a separate issue
+[21:19:10] <WilliamH> K_F: actually it isn't.
+[21:19:27] <WilliamH> K_F: those are on woodpecker in /var/mail/alias/*
+[21:19:27] <ulm> rich0: I don't think so, but if it does then it can be resolved
+[21:19:31] <dilfridge> anyway
+[21:19:35] <dilfridge> we're drifting
+[21:19:46] <dilfridge> so 
+[21:20:06] <dilfridge> we have said we want to use shortname, but not said anything where it comes from
+[21:20:06] <WilliamH> dilfridge: all we've done is say s/herd/project/ in metadata.xml
+[21:20:59] <K_F> imho defined in wiki page, and I'd prefer subproject to include the parent project as part of the shortname
+[21:21:06] <dilfridge> here's the suggestion,
+[21:21:18] <WilliamH> K_F: I don't agree with the second part of that
+[21:21:23] <ulm> K_F: like lisp-emacs-gnuemacs@proj.g.o?
+[21:21:38] <K_F> ulm: yup
+[21:21:48] <dilfridge> K_F: you mean, kde-desktop@projects.gentoo.org?
+[21:22:04] <mgorny> i'd say that's nonsense
+[21:22:05] <ulm> K_F: what if a project changes its parent?
+[21:22:07] <WilliamH> dilfridge: I think he means desktop-kde
+[21:22:09] <mgorny> esp. taht project structure can change
+[21:22:18] <WilliamH> But I agree with mgorny
+[21:22:32] <rich0> The only smart code is a dumb code...
+[21:23:13] <K_F> goes back to namespace collission
+[21:23:36] <dilfridge> F: define the project shortname on the wiki project page, and expect that any project is *also* reachable as shortname@projects.gentoo.org
+[21:23:37] <ulm> base-system-amd64@proj.g.o is another example
+[21:23:54] <rich0> 69d29b10-a793-44ef-bd97-a94705b68179@gentoo.org ?
+[21:24:08] <dilfridge> 0xDEADBEEF
+[21:24:09] <ulm> dilfridge: careful
+[21:24:11] <blueness> rich0:  serously!
+[21:24:21] <dilfridge> ulm: why?
+[21:24:24] <ulm> the projects.gentoo.org domain is used for hosting already
+[21:24:28] <dilfridge> uh
+[21:24:29] <dilfridge> ok
+[21:24:30] <dilfridge> right
+[21:24:38] <dilfridge> so 
+[21:24:41] <ulm> proj.g.o or project.g.o
+[21:24:50] <dilfridge> F2: define the project shortname on the wiki project page, and expect that any project is *also* reachable as shortname@proj.gentoo.org
+[21:24:59] -*- WilliamH isn't for either one, just g.o
+[21:25:01] -*- K_F F2 yes
+[21:25:14] <dilfridge> WilliamH: that does not work, as already mentioned
+[21:25:21] -*- blueness yes
+[21:25:24] -*- dilfridge F2 yes
+[21:25:26] -*- jlec yes
+[21:25:36] -*- WilliamH abstains
+[21:25:40] <ulm> dilfridge: proj.g.o is the alias, the existing one still the main address?
+[21:25:51] <dilfridge> ulm: I havent said anything about that
+[21:25:58] -*- ulm abstains
+[21:26:26] <dilfridge> ok 
+[21:26:30] <dilfridge> I kinda lost track
+[21:26:40] <dilfridge> what else can we talk about in this context?
+[21:26:55] <jlec> ulm: we should transfer all aliases on a long term to pgo
+[21:26:57] <ulm> I guess in the end it won't matter which one is main and which the alias
+[21:26:59] <K_F> dilfridge: robbat2's email
+[21:27:11] <ulm> jlec: I'm strongly opposed to that
+[21:27:20] <jlec> reason?
+[21:27:30] <WilliamH> I don't really understand what the benefit of a separate <project> tag is
+[21:27:37] <ulm> jlec: just convenience
+[21:27:38] <K_F> https://archives.gentoo.org/gentoo-project/message/3cf270a336636b94187b2a2b8f1b7e7f < projects can have non-public members etc
+[21:27:52] <dilfridge> K_F: so far only 0. of the mail is relevant
+[21:28:23] <dilfridge> the rest of it only becomes relevant once we somehow connect alias list <> project member list
+[21:28:25] <jlec> ulm: okay. so no real problem.
+[21:28:42] <K_F> dilfridge: ah, yeah, misread your question to what to look into next..
+[21:29:14] <dilfridge> and, seriously, the question of alias<>project members is too complicated for today
+[21:29:32] <mgorny> as i see it, mail alias problem is for infra, not council
+[21:29:51] <dilfridge> that too
+[21:29:52] -*- mgorny doesn't really like the idea of Council being a group of people who force others to do their wannabe work
+[21:30:07] <dilfridge> well who else should do the forcing? :)
+[21:30:21] -*- WilliamH tends to agree 
+[21:30:38] <WilliamH> That's why I don't see why we voted to create this <project> tag in the first place
+[21:30:56] <rich0> WilliamH: ++
+[21:31:02] <WilliamH> I honestly don't understand what it preserves
+[21:31:11] <dilfridge> here's a suggestion, we could at least do a "soft, non-binding vote" whether we are interested in any sort of coupling of mail aliases and project member lists
+[21:31:35] <WilliamH> The project tag is absolutely useless
+[21:31:43] <rich0> dilfridge: ++ on non-binding soft votes just to get ideas out there
+[21:31:58] <K_F> straw poll sounds good indeed
+[21:32:02] <jlec> Isn't it in the interest of a project memember to be part of the alias?
+[21:32:04] -*- WilliamH motions that we undo the <project> tag vote
+[21:32:09] <rich0> I think we are going to end up needing to come back to this with more solid proposals, and preferably ones that somebody has signed up to implement
+[21:32:29] <K_F> jlec: I would expect so, if not a subproject could make sense
+[21:32:36] <rich0> WilliamH: honestly, I'd drop that for now.  we're never going to get through this today.  Better to just brainstorm, then take it to the lists.
+[21:32:55] <rich0> Any idea we come up with in a <project> world could be implemented in a <maintainer> world
+[21:33:12] <ulm> dilfridge: can I still change my vote on C?
+[21:33:19] <blueness> while i agree with mgorny  that we're not here to get others to do this work, i don't see how to avoid that in this question, no brought forwards soemthing that said, i'm doing this, yes or no?
+[21:33:20] <dilfridge> G: The council is interested in exploring methods to couple project alias membership automatically to project membership. The details are still to be discussed.
+[21:33:20] <WilliamH> We have already deprecated herds, and that's cool, but I don't get the objection to using maintainers.
+[21:33:48] <WilliamH> I really want us to kill the <project> tag formally since we voted to add it.
+[21:34:07] <WilliamH> It is useless
+[21:34:10] <dilfridge> ulm: if you change your opinion on C, we basically have to scrap everything afterwards and restart there
+[21:34:18] <rich0> WilliamH: I don't really see that vote as binding.  It is just starting down a direction.  We never voted for anythign implementable.
+[21:34:20] <blueness> WilliamH:  we voted on that already, let's come back to it afterwards and look at the whole package
+[21:34:43] <rich0> blueness: ++ - we can always just vote against the final package and just start over
+[21:34:45] <ulm> dilfridge: well, sorry
+[21:35:11] <dilfridge> I have another 10min and then I need to leave
+[21:35:15] <ulm> I see now that there are good arguments for both
+[21:35:27] -*- WilliamH motions then that we vote that this whole package is tentative and we are still exploring ideas, so that no one sees it as binding
+[21:35:29] <blueness> we shouldn't have been doing this anyhow, we need begining-to-end proposals, including who's championing the work
+[21:35:36] <ulm> dilfridge: but o.k., I won't change my vote
+[21:35:54] <WilliamH> The problem if we don't do that is that people will see our votes as binding
+[21:36:04] <dilfridge> blueness: the problem is that this won't work, because we will never agree on anything that we can vote on
+[21:36:11] <rich0> blueness: I think it is fine to just talk and hash out opinions and recommendations, but yes, I think in the end we actually need a solid proposal that somebody intends to implement
+[21:36:19] <rich0> It is the PMS problem all over again
+[21:36:31] <dilfridge> so
+[21:36:37] <mgorny> well, i guess on top of this i can assemble some partial proposal that could match some of the votes and i could still opt for implementing
+[21:36:38] <dilfridge> here's a radical proposal
+[21:36:47] <blueness> rich0:  i'm not against discussing it but  .... ${issues}
+[21:36:49] <dilfridge> should this be done via a glep?
+[21:37:01] <blueness> qeori3qji3qgjj3g[g!
+[21:37:06] <mgorny> dilfridge: sounds like we're going to have 4 GLEPs
+[21:37:07] <rich0> dilfridge: that actually isn't a bad idea
+[21:37:08] <WilliamH> dilfridge: maybe so.
+[21:37:13] <mgorny> pretty much back to the original ml thread
+[21:37:19] <dilfridge> well
+[21:37:21] <K_F> dilfridge: yeah, that sounds like good idea
+[21:37:28] <dilfridge> voting on a glep is a better idea than this mess
+[21:37:31] <blueness> yeah it should probably be a glep
+[21:37:32] <WilliamH> We have accomplished nothing today then
+[21:37:33] <rich0> but, putting a GLEP label on it doesn't really make the problem go away
+[21:37:37] <blueness> deprecating an older glep
+[21:37:47] <dilfridge> rich0: no, but it would be first worked out and then voted on
+[21:37:47] <blueness> rich0:  no but it formalizes the process
+[21:37:54] <rich0> WilliamH: I disagree.  I learned that some projects share email addresses, etc.
+[21:37:55] <ulm> WilliamH: we have deprecated the concept of herds at least
+[21:38:09] <rich0> ulm: ++
+[21:38:19] <rich0> In fact, it took us 40min just to deprecate the herds :)
+[21:38:28] <WilliamH> ulm: ok, lets me write something real quick we can vote on... to cover just that.
+[21:38:30] <blueness> yeah this was productive in my opinion but incmplete
+[21:38:37] <K_F> rich0: the way I see it that isn't necessarily an issue, they could still do so, that is just a question of what is on the alias afterwards
+[21:39:07] <WilliamH> The council has decided that the concept of herds is deprecated. We are in the process of exploring alternatives.
+[21:39:28] <dilfridge> here's a more detailed thing
+[21:39:33] <WilliamH> That's all we really should say and we should throw  out all other votes today
+[21:40:15] <WilliamH> It should be pretty simple and we should say that we haven't  decided on a replacement.
+[21:40:54] <dilfridge> Proposal: "All votes today from B on are anulled. The council recommends that the details on herds to projects transition should be worked out in a GLEP."
+[21:41:15] -*- WilliamH yes
+[21:41:16] <jlec> ++
+[21:41:19] <dilfridge>  /me yes
+[21:41:19] -*- K_F yes
+[21:41:22] -*- jlec yes
+[21:41:35] <ulm> *sigh*
+[21:41:39] -*- ulm yes
+[21:41:43] -*- rich0 yes
+[21:41:47] <blueness> abstain
+[21:42:13] <rich0> But, I think working through some of this was helpful at least in getting a sense of where everybody stands...
+[21:42:14] <dilfridge> that's 6 yes and 1 abstention. well at least we decided on something. :)
+[21:42:38] <K_F> rich0: I think the discussions have been helpful, for sure
+[21:42:41] <dilfridge> will be an interesting summary
+[21:42:48] <blueness> this sets a bad precedence in that we nullify voting too easily
+[21:43:05] <ulm> it shows again that you cannot develop a sound proposal during the meeting
+[21:43:07] <blueness> i would have left this vote until we're done
+[21:43:08] <K_F> blueness: yeah, I don't necessarily like it, but they are void since we go GLEP route
+[21:43:24] <blueness> K_F:  sure but don't say it!
+[21:43:29] <K_F> so in that context, they have been more a question of guiding the discussion
+[21:43:36] <dilfridge> blueness: I see your point, but it was a mess before already.
+[21:43:43] <rich0> ulm: ++ - I think when we take up issues like this without sound proposals, we should just agree to have some free discussion over the entire topic and then send it back for work
+[21:43:48] <blueness> now who's writing the glep?
+[21:43:59] <dilfridge> hrhr
+[21:44:25] <blueness> watch how i delegate :)
+[21:44:27] <K_F> rich0: in essence isn't that what we're doing?
+[21:44:32] <WilliamH> Hmm was metadata defined somewhere in a glep?
+[21:44:37] <blueness> if i write it, i'm putting <project> in there!
+[21:44:40] <mgorny> i doubt that we're going to be happy with single GLEP
+[21:44:42] <blueness> anyone object
+[21:44:49] <rich0> K_F: sure
+[21:44:55] <WilliamH> blueness: me strongly
+[21:45:03] <mgorny> i can write a GLEP but some of you won't agree with it
+[21:45:07] <WilliamH> blueness: <project> isn't necessary
+[21:45:07] <blueness> WilliamH:  then you can write it ;)
+[21:45:19] <mgorny> but it'd at least be implementable
+[21:45:22] <blueness> WilliamH:  i'm joking, long meeting
+[21:45:24] <WilliamH> blueness: I see a project as a type of maintainer.
+[21:45:33] <blueness> mgorny: why several gleps?
+[21:45:41] <blueness> what are you envisioning?
+[21:45:42] <WilliamH> blueness: heh
+[21:45:44] <WilliamH> ;-)
+[21:45:50] <mgorny> blueness: seen the original thread? there were at least 4 big proposals
+[21:46:00] <WilliamH> Folks, where was metadata.xml defined? Is that in a glep?
+[21:46:01] <dilfridge> well it's easier to vote on one of three worked-out gleps than on 298 half-baked ideas
+[21:46:07] <blueness> mgorny:  yeah but the final structure was simple
+[21:46:12] <ulm> dilfridge: are we going to do the open bug still today?
+[21:46:18] <dilfridge> yeah
+[21:46:20] <dilfridge> so
+[21:46:22] <ulm> namely bug 503382
+[21:46:22] <dilfridge> errm
+[21:46:24] <willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
+[21:46:27] <dilfridge> OPEN BUGS
+[21:46:39] <dilfridge> any news on that?
+[21:46:47] <ulm> summary for 20131210 meeting is here: https://dev.gentoo.org/~ulm/20131210-summary.txt
+[21:47:08] <ulm> also previously sent to council@ at 2015-10-05
+[21:47:23] <WilliamH> blueness: My objection wasn't to you writing the glep either, it was just to the <project> tag...
+[21:47:28] <K_F> ulm: thanks for writing it up, I didn't see anything to comment on
+[21:48:21] <K_F> ulm: well, except for PGP/OpenPGP nitpicking perhaps..
+[21:48:31] <ulm> K_F: yes?
+[21:48:42] <K_F> "- Status of PGP key GLEP [5]."
+[21:49:00] <K_F> but that isn't material
+[21:49:00] <dilfridge> GLEP proposal: Gentoo GPG key policies
+[21:49:05] <K_F> OpenPGP
+[21:49:14] <dilfridge> s/PGP/GPG/ or s/PGP/OpenPGP/
+[21:49:16] <K_F> GPG and PGP are implementations, OpenPGP is the protocol
+[21:49:25] <dilfridge> the glep says GPG
+[21:49:48] <ulm> dilfridge: there wasn't a glep back then, though
+[21:49:48] <K_F> yeah, which isn't necessarily a good thing :)
+[21:50:01] <dilfridge> http://comments.gmane.org/gmane.linux.gentoo.project/3155
+[21:50:14] <K_F> anyhow, not material, and something I comment on whenever I come across it as I like to keep the terminology proper
+[21:50:34] <blueness> guys, i have to leave. we're at the end though
+[21:50:38] <dilfridge> yep
+[21:50:49] <ulm> so s/PGP/GPG/ or s/PGP/Open&/ ?
+[21:51:02] <K_F> ulm: I'd say OpenPGP
+[21:51:25] <dilfridge> I'd say stick to the glep
+[21:51:27] <K_F> (rfc4880 is the OpenPGP message format)
+[21:51:44] <K_F> GPG also supports X.509 certificates
+[21:51:55] <K_F> so GPG key strictly speaking doesn't make sense
+[21:51:58] <dilfridge> but anyway we can slug this out later, and the rest should be fine since noone else objects
+[21:52:25] <ulm> whatever, I'll change it to OpenPGP if noone objects
+[21:52:29] <dilfridge> do it
+[21:52:35] <dilfridge>  
+[21:52:38] <dilfridge> last thing
+[21:52:40] <ulm> if someone does then we'll need a vote :p
+[21:52:44] <dilfridge> OPEN FLOOR
+[21:52:56] <dilfridge> anyone gotten abducted by aliens recently?
+[21:53:05] <WilliamH> lol
+[21:53:16] <ulm> for next meeting's agenda: EAPI 6 approval
+[21:53:21] <dilfridge> yep
+[21:53:30] <dilfridge> looking forward to it
+[21:53:30] <jlec> sweet
+[21:53:37] <ulm> who will be chairing?
+[21:53:40] <K_F> ulm: me
+[21:53:41] <jlec> Another three weeks
+[21:53:41] <dilfridge> K_F
+[21:53:55] <rich0> guess we gotta figure out eapply_user :)
+[21:53:58] <dilfridge> two weeks
+[21:54:06] <K_F> can we try to avoid multi-week meetings? If the agenda is mandating it, can we try to allocate more time at original time?
+[21:54:11] <K_F> dilfridge: he ment dragging on..
+[21:54:14] <jlec> I meant 3 weeks in a row meetings
+[21:54:22] <ulm> so call for agenda items should be sent today
+[21:54:31] <dilfridge> nah, I'd say we can do EAPI=6 in 5min :D
+[21:54:39] <dilfridge> so 
+[21:54:40] <dilfridge> anyway
+[21:54:43] <dilfridge> no aliens
+[21:54:45] <dilfridge> so 
+[21:54:46] <K_F> ulm: yes I'm sending it later, wanted to see where we ended up :)
+[21:54:50] <dilfridge> meeting closed!
+[21:54:55] -*- dilfridge bangs something on the table
diff --git a/meeting-logs/20151025.txt.asc b/meeting-logs/20151025.txt.asc
new file mode 100644
index 0000000..8b27b63
--- /dev/null
+++ b/meeting-logs/20151025.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2.1
+
+iQJ8BAABCgBmBQJXCoVOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
+NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkDpEQAJ9zHhAno9t+svTbvy8ppOcG
+YoAgEyYfnrz5T67KfDeDgWvFWLYn5OBNN+CoxqOj2Kdi49lvxogkJuiuWJOVcm/g
+8U4VjuvSfFgu8K3z6HLW/zHOoB2cTzab8fVO75Ck84rcZx+k8kh8BPRoUU68CQRL
+Bv/jpM5+7O0FhqcTa/dPlD4luqBhJY8W1B6OI0U9QderF6+yiRdI562orMZOzNqB
+/arexLwqNIk/gJ8I8PeIoMo9niKVJ68SxqkwCiMLlidywLj+LyWsDMl35r9i3VWU
+wvq5stohH/U/m+UaT3bkXWqqH5f+MMMGa9cFSBs2aCMa2lWIsBi8IbywdyDSbfOw
+6ZY5wvNIAalYR1zpwaGQ/XVW5O1LdlKC387DOGcRz9stbY1e6rgW13rl4XRd7qis
+YlzHI4N+KxJFX7kOxAKKhyZguA8hJBoGi92sx4RBcfrZnHEZ/DyvJ0m4LwPeKK9i
+pcfU0WPFSjrqTAxs5qL0kZYA51N8hPQ1OBkdPJ2U6EBCBpioSoS/KYAVvstilCgb
+gaHVTmZvGPHQjk1gUHvLIKee8cGz7Y1IJoKYIDaFMaA0Q37Zh8h4S9AGXMAmZEou
+EaHfKS+gaNKhJpUzXU2itLA/dAcYP5Pd8ysojx7brC9MI/5NHwL/9WiOR/ZBrgf4
+Sjj1dXZct7yQAVPLTXgn
+=ViF4
+-----END PGP SIGNATURE-----