rich0 14/10/21 20:26:18 Added: 20141014-summary.txt 20141014.txt 20141021-summary.txt 20141021.txt Log: Add October council logs/summary.
Revision Changes Path 1.1 xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt?rev=1.1&content-type=text/plain Index: 20141014-summary.txt =================================================================== Roll call ========= Present: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh Absent: The future of einstall ====================== "Einstall will be removed from EAPI6." aye: creffett (proxy for ulm), dberkholz, radhermit, rich0, williamh GLEP 64 ======= "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 with API versioning added." aye: blueness, dberkholz, dilfridge, radhermit, rich0 abstain: creffett (proxy for ulm), williamh Git Migration Issues ==================== "The yyyy/ prefix can be dropped from gentoo-news, timing to be determined by those implementing the change." Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh Can we drop CVS headers post-migration? Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh "The git migration should produce a separate historical and current repository, which can be spliced using git replace, but which are otherwise not connected." Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh "we don't see any big remaining obstacles and advise infra / the git migration project to proceed at their pace" Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh (Meeting was called due to time, with remaining items to be covered following week.) 1.1 xml/htdocs/proj/en/council/meeting-logs/20141014.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141014.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141014.txt?rev=1.1&content-type=text/plain Index: 20141014.txt =================================================================== [15:00:07] <rich0> Ok, roll call :) [15:00:10] <radhermit> here [15:00:15] <WilliamH> here [15:00:16] <dberkholz|mob> Sup [15:00:49] -*- creffett|irssi here for ulm, unless ulm is here already [15:01:02] <rich0> blueness, dilfridge, ulm? [15:01:57] <rich0> Ok, let's get started. [15:02:04] <rich0> First item, future of einstall [15:02:14] <rich0> http://thread.gmane.org/gmane.linux.gentoo.devel/92713 [15:02:14] <rich0> http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2212/focus=4025 [15:02:27] <rich0> Should einstall be banned in EAPI6. [15:02:32] <rich0> Any comments beyond the lists? [15:02:37] -*- creffett|irssi reviews his notes [15:02:49] <creffett|irssi> no comments here [15:02:54] <WilliamH> none here [15:03:27] <radhermit> I don't have anything more to say [15:03:32] <rich0> Ok, let's vote then. "Einstall will be removed from EAPI6." [15:04:07] -*- creffett|irssi yes [15:04:12] <dberkholz|mob> Yep [15:04:13] <radhermit> yes [15:04:16] <WilliamH> yes [15:04:31] -*- rich0 yes [15:04:49] <rich0> Ok, that's all of us [15:05:02] <rich0> Next item... [15:05:11] <rich0> https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 [15:05:20] <rich0> Blueness is requesting approval on this. [15:05:24] <radhermit> someone want to text blueness? [15:05:30] <rich0> good idea [15:06:24] <dilfridge> sorry, here [15:06:26] <rich0> I just texted him [15:06:55] <rich0> Do we want to move on to git? [15:07:05] <radhermit> sure [15:07:06] <rich0> I'd prefer to give him the option to present. [15:07:11] <blueness> here!!! [15:07:11] <rich0> Ok, let's move on to git. [15:07:16] <blueness> sorry thanks rich [15:07:18] <rich0> never mind. :) [15:07:22] <blueness> rich0, [15:07:24] <rich0> let's do glep64 - I think it will be faster [15:07:41] <rich0> blueness: do you have any comments you want to make? [15:07:51] <blueness> rich0, just a few points [15:07:58] <blueness> its was discussed on gentoo-dev@ [15:08:14] <blueness> it got feedback for ciarian and incorportated it [15:08:28] <blueness> do you need me to repeate the motivation? [15:08:39] <rich0> Nah - at least not for me. [15:08:42] <rich0> I can read. :) [15:08:52] <rich0> My only real comment is that it is a bit vague - deliberately so. [15:09:07] <blueness> this is the latest version -> https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 [15:09:11] <rich0> I don't mind approving it per se, but do we think that it will go anywhere? [15:09:37] <rich0> Ie are the various package managers behind it? [15:09:37] <dberkholz|mob> Do we have agreement in theory from PM implementers? [15:09:38] <blueness> rich0, i will try to work with ciarian and actually write code [15:09:55] <WilliamH> blueness: what about pkgcore? [15:09:56] <blueness> i'd like to hear from radhermit and package core [15:09:56] -*- dberkholz|mob high-fives rich0 [15:10:32] <blueness> radhermit, ping ^^^ [15:10:45] <blueness> also zmedico was in support [15:10:46] -*- radhermit is trying to skim through the mailing list thread :) [15:10:53] <blueness> radhermit, okay [15:10:58] <rich0> It sounds like most of this is in portage, it just needs the API to be written. [15:11:08] <rich0> From what I know of portage, it won't be hard to do there. [15:11:17] <rich0> Just needs commitment to the API. [15:11:27] <radhermit> can we version the vdb or something if we start properly specifying it? [15:11:40] <radhermit> maybe that's already in the glep [15:11:53] <blueness> radhermit, i didn't mention a version to vdb [15:12:00] <rich0> This GLEP doesn't really specify the VDB, so much as require an interface to it (without actually specifying it). [15:12:17] <radhermit> so mainly it's about standardized file naming? [15:12:17] <blueness> for the reason rich0 just mentioned ^^^ [15:12:24] <rich0> It might not hurt to incorporate some kind of VAPI versioning. [15:12:35] <blueness> radhermit and standardizing what's exported [15:12:40] <dberkholz|mob> Seems to me that vdb version would be a portage internal matter [15:12:47] <rich0> It basically is a spec for the spec. [15:12:48] <dberkholz|mob> What I care about is an API version on this [15:13:23] <blueness> dberkholz|mob, i can add a sentence to that effect [15:13:24] <rich0> dberkholz|mob: ++ [15:13:30] <dilfridge> good idea [15:13:36] <rich0> That should be a part of the API when it is specified. [15:13:58] <radhermit> basically what I meant [15:14:20] <rich0> It feels a bit odd to approve this other than going along with the general sentiment that it is a good idea, but I have no objections to it. [15:14:33] <rich0> It just feels a bit like approving a business case, vs a spec. [15:14:51] <blueness> yeah, it turns out now there are not only several packages but also one eclass depending on vdb information from portage, none of which work with other pm's but could [15:15:18] <rich0> SELinux and such sounded like a really good use case here. [15:15:27] <rich0> You'd want that to work with any PM. [15:15:48] <rich0> Or PaX in your example. [15:15:58] <blueness> rich0, the way selinux eclass works now is it looks for reverse deps to do the markings [15:15:59] <radhermit> mostly I'd like to quit having to read through portage code to make stuff like eix work :) [15:16:04] <radhermit> with pkgcore-merged pkgs [15:16:35] <rich0> Yeah, I have an EAPI hunter that depends on portage APIs, though to be fair this only pertains to installed packages I believel. [15:16:45] <rich0> It might make sense to extend that API to installable packages as well. [15:16:46] <blueness> yeah, i didn't even know about pkgcore until recently and it could benefit from this too [15:17:06] <rich0> Ok, do we want to vote to approve this? [15:17:13] <dilfridge> + [15:17:48] <rich0> "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 " [15:17:56] <rich0> Does that work? [15:18:00] <blueness> sure [15:18:10] <rich0> You can promise not to change it too much. :) [15:18:13] <rich0> Ok, let's vote. [15:18:17] <blueness> o [15:18:21] -*- rich0 yes [15:18:26] <dilfridge> yes [15:18:27] -*- blueness yes [15:18:32] -*- creffett|irssi abstain [15:18:36] <dberkholz|mob> Yes + API version [15:18:45] -*- WilliamH abstain [15:19:09] <radhermit> yes with API version stuff [15:19:28] <blueness> ulm, ? [15:19:37] <radhermit> creffett|irssi is ulm [15:19:49] <rich0> Ok, that's everybody - 5-0 [15:20:03] <rich0> And that includes the API version - I'll note that in the sumary. [15:20:21] <blueness> rich0, and everyone, i think that just a one sentencer no? [15:20:26] <rich0> I'll document it as: "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 with API versioning added." [15:20:33] <rich0> blueness: wfm [15:20:52] <rich0> Ok, now the fun topic. [15:20:54] <rich0> Git migration [15:21:11] <dilfridge> wheee [15:21:14] <blueness> shudder [15:21:19] <rich0> My personal goal here would be to get opinions recorded anywhere we think they matter. [15:21:25] <rich0> We're not going to bikeshed every detail. [15:21:39] -*- mgorny is around to help :P [15:21:41] <rich0> But, if there are things that we feel must be in place to do a migration, we should try to get them documented. [15:21:44] <rich0> That is my sense of it. [15:21:48] -*- WilliamH thinks we need to stop waiting for a perfect world and get it done ;-) [15:22:05] <rich0> Any other comments before we dive in? [15:22:34] <creffett|irssi> bring it on! [15:22:44] <rich0> The first question in the agenda, is do we need to continue to create new ChangeLog entries once we're operating in git? [15:22:54] -*- WilliamH no [15:22:59] <dilfridge> no [15:23:02] <rich0> no [15:23:07] <creffett|irssi> nope. [15:23:09] -*- blueness no [15:23:18] <dberkholz|mob> hell no [15:23:43] <radhermit> no [15:23:51] <rich0> Ok, well, let's just call that a vote. :) [15:23:52] <dilfridge> ! [15:24:26] <rich0> Ok, let's skip "are we done yet" and move that to the end after we tackle all the specifics [15:24:34] <rich0> Can yyyy/ prefix be dropped from gentoo-news? [15:24:44] <rich0> We've been through that one once before. [15:24:54] <rich0> http://archives.gentoo.org/gentoo-dev/msg_00f0a83b760b78c1baf32f118d1cb008.xml [15:25:01] <rich0> https://bugs.gentoo.org/show_bug.cgi?id=523828 [15:25:23] <rich0> mgorny: will dropping this still make your life easier with metadata? [15:25:38] <mgorny> rich0: a bit [15:25:59] <mgorny> i just find it utterly stupid that 'reading' and 'writing' formats are different [15:26:06] <rich0> ++ [15:26:11] <dilfridge> drop it [15:26:27] <rich0> Any opposing commentary? [15:26:38] <blueness> nah, no contraversy here [15:26:46] <dberkholz|mob> Nope [15:26:49] <blueness> who needs to implement this infra? [15:27:07] <mgorny> someone commit to repo + infra change the script used for gen [15:27:32] <rich0> Ok, let's vote "The yyyy/ prefix can be dropped from gentoo-news, timing to be determined by those implementing the change." [15:27:44] <rich0> Does that work? [15:27:44] -*- blueness yes [15:27:47] -*- rich0 yes [15:27:50] -*- creffett|irssi yes [15:27:50] -*- WilliamH yes [15:27:51] <dilfridge> yes [15:27:59] <radhermit> yes [15:28:04] <dberkholz|mob> Sure [15:28:49] <rich0> ok [15:29:10] <rich0> Ok, going in order of controversy... [15:29:15] <rich0> Can we drop CVS headers post-migration? [15:29:24] -*- WilliamH yes [15:29:29] -*- rich0 burn with nuclear fire [15:29:31] <dilfridge> yes please [15:29:33] <creffett|irssi> KILL IT [15:29:38] <blueness> heh [15:29:41] <WilliamH> I don't think ghere is an equivalent to that in git. [15:29:43] <creffett|irssi> er, I mean, yes [15:30:24] <rich0> dberkholz|mob, radhermit - care to make it a vote? [15:30:37] <rich0> blueness: also? [15:30:39] <dberkholz|mob> Yes pls [15:30:48] <radhermit> kill it of course [15:31:06] <rich0> blueness: heh==yes? [15:31:18] <blueness> yes [15:31:23] <dilfridge> heh we're fast :) [15:31:33] <rich0> ok [15:31:39] <rich0> Now a bit more controversy. [15:31:49] <rich0> Should we have separate git trees for historical vs current portage (with no parent commit reference from the one to the other)? [15:32:02] <rich0> http://thread.gmane.org/gmane.linux.gentoo.project/4030/ [15:32:37] <creffett|irssi> rich0: here's my question -- if someone did want to join the two trees locally, how much work would it be? [15:32:43] <dilfridge> if we can arrangeit that they can be combined seamlessly into one, yes [15:32:51] <dberkholz|mob> I would prefer a spliceable one [15:32:55] <rich0> mgorny: you probably have more git replace experience than I [15:33:19] <mgorny> git fetch history-remote; git replace ${first_commit_id} ${history_commit_id} [15:33:23] <rich0> I'd think you could just fetch a second origin into another branch and then git replace the one into the history of the other [15:33:29] <mgorny> (or teh other way around :P, easy to put on wiki) [15:33:47] <radhermit> I'd vote for spliceable too [15:33:55] <rich0> Yeah, you'd make the last commit in the history repo = the first commit in the active tree when doing a history [15:33:55] <dilfridge> means? [15:34:06] <radhermit> meaning you can graft the old tree onto the new one [15:34:12] <rich0> radhermit: exactly [15:34:14] <radhermit> if you want a giant, historical repo [15:34:24] <WilliamH> Which ever one can get us up and running sooner. ;-) [15:34:33] <rich0> Git will treat references to the first commit in the current tree as if it pointed to the last commit in the history tree. [15:34:33] <creffett|irssi> so it's fairly simple to do the join if someone wants to? [15:34:39] <radhermit> the old graft can technically be done later [15:34:39] <rich0> So it would appear to have a continuous history. [15:34:45] <mgorny> creffett|irssi: yes, only time consuming for fetch :) [15:34:53] <creffett|irssi> mgorny: okay [15:34:58] <creffett|irssi> then yes, separate is fine with me [15:35:01] <dilfridge> radhermit: dberkholz|mob: I don't understand what your "spliceable" version does different [15:35:06] <WilliamH> I have a question... [15:35:06] <blueness> rich0, what's the gain on the divisionb between historical and current? [15:35:14] <rich0> blueness: I outlined that in my post. [15:35:22] <blueness> k [15:35:25] <rich0> The current historical migrations have issues. [15:35:43] <rich0> If we improve on them, then the original "official" migration turns into baggage. [15:35:55] <dilfridge> blueness: we can start immediately and care about the exact history later [15:35:56] <rich0> You could still splice a new migration over the old one. [15:36:05] <WilliamH> So, if we have two trees: one would contain the history before the migration, and we would update the other from that point forward not worrying about the historical tree right? [15:36:14] <mgorny> blueness: 1.5G [15:36:24] <rich0> It also sidesteps arguments over whether the current migration is good enough, and makes the migration MUCH faster. [15:36:25] <dilfridge> WilliamH: basically, yes. we start from a current point. [15:36:26] <mgorny> 70M is 'current' afresh and grows [15:36:29] <mgorny> 1.5G is historical and grows [15:36:30] <blueness> so speed size and simplicity [15:36:57] <blueness> what happens in the far future when it gets 1.5GB again, can it be sliced again? [15:36:57] <dberkholz|mob> Ah I hadn't tracked the work on git replace. I'm fine with that [15:36:57] <dilfridge> the conversion of the cvs history becomes a non-blocker, and non-critical project [15:37:16] <rich0> exactly. I'd still run the best migration that I could. [15:37:32] <rich0> But, issues with it don't hold things up, and it could be improved on later. [15:37:54] <rich0> Any other questions/concerns? [15:38:10] <dilfridge> git question, if you end up pulling two separate histories, is there a way to prune the old, unused objects? [15:38:16] <dilfridge> mgorny: ^ [15:38:36] <WilliamH> I think "git gc" will do that. [15:38:37] <dilfridge> (not important now, just curiosity) [15:38:42] <mgorny> dilfridge: there will be no unused objects if you merge them via replace [15:38:55] <dilfridge> ok [15:38:56] <mgorny> unless you mean after removing the history replace, then gc should catch them [15:39:02] <dilfridge> ok [15:39:03] <dilfridge> good [15:39:25] <rich0> Yeah, the beauty of having separate repos is that you can easily get rid of the 750k bad commits if you have 750k better ones to replace them with. [15:39:42] <dilfridge> hehe [15:39:56] <rich0> The converted repository is pretty impressive, for all its faults. :) [15:40:04] <rich0> Something like 3M objects I think. [15:40:27] <rich0> Ok, anything else before we vote? [15:40:33] <blueness> i'm good [15:40:48] <mgorny> if you mean having history1 repo and replacing part of it with history2, then objects from both repos will have to be kept [15:40:53] <dberkholz|mob> I just want to make sure that the join gets tested, but I'm assuming that will happen [15:41:07] <mgorny> dberkholz|mob: i've already tested it initially [15:41:09] <rich0> "The git migration should produce a separate migrated and current repository, which can be spliced using git replace, but which are otherwise not connected." [15:41:11] <dberkholz|mob> Awesome. [15:41:20] <rich0> Any issues with the wording? [15:41:31] <dberkholz|mob> What does "current" mean [15:41:32] <rich0> The "which can be spliced with git replace" should cover the testing concerns. [15:41:40] <dberkholz|mob> Last year, last X commits to each file, etch [15:41:45] <rich0> Maybe historical and current ? [15:41:47] <dberkholz|mob> etc* [15:42:07] <rich0> Current means basically what you have in /usr/portage, really. [15:42:10] <mgorny> newest version snapshot [15:42:14] <rich0> Minus metadata/etc. [15:42:14] <dberkholz|mob> And i'd go with s/migrated/historical/ , "full history" or something like that [15:42:15] <mgorny> 'cvs up -dP' [15:42:20] <rich0> Agree [15:42:23] <mgorny> with some cleanup [15:42:27] <dberkholz|mob> Oh a funtoo style thing with zero history [15:42:35] <mgorny> that's the safe way of ensuring that we don't end up starting with broken repo [15:42:35] <rich0> "The git migration should produce a separate historical and current repository, which can be spliced using git replace, but which are otherwise not connected." [15:42:39] <mgorny> like current history migration causes [15:43:15] <rich0> Well, we can at least get the CURRENT tree right with the migration. It is identical now. [15:43:25] <rich0> Go one commit back and it is less so. [15:43:35] <rich0> Ok, if no issues with the wording... [15:43:51] <rich0> Let's vote: "The git migration should produce a separate historical and current repository, which can be spliced using git replace, but which are otherwise not connected." [15:43:55] -*- rich0 yes [15:44:10] -*- blueness yes [15:44:18] <radhermit> yes [15:44:21] <creffett|irssi> yes [15:44:30] -*- dilfridge yes [15:44:31] -*- WilliamH yes [15:44:44] <dberkholz|mob> k [15:44:56] <rich0> ok, 7-0 [15:45:13] <rich0> That brings us to, "are we done yet?" [15:45:37] <rich0> Are there any other high-level blockers we should consider, beyond just getting everything implemented and coordinated with infra, the migration team, etc? [15:45:59] <dberkholz|mob> Beyond implementation. Like that's a minor issue. heh [15:46:05] <dilfridge> mgorny: how's the status of whatever server-side hooks we need? [15:46:07] <rich0> Also, what do we want the actual migration to look like? Do we need to approve the final cutover, etc? [15:46:23] <dberkholz|mob> It would be helpful if we could open up whatever backend code possible to enable more people to easily work on it [15:46:37] <rich0> dberkholz|mob: ++ that is a problem with our current infra I think. [15:46:42] <blueness> dberkholz|mob, yeah i'd like to see that [15:46:46] <rich0> No reason the hooks/etc can't be FOSS. [15:46:53] <mgorny> dilfridge: mostly done, i think infra will handle the remaining updates [15:46:55] <rich0> Obviously passwords/configs/etc can be private. [15:47:22] <dilfridge> is anyone from infra around who cares to comment? _robbat21irssi? [15:47:45] <rich0> Making this FOSS would help a lot with anybody interested in "rolling your own Gentoo" [15:47:59] <mgorny> my code is on github, i think [15:48:01] <mgorny> or bitbucket ;P [15:48:11] <rich0> mgorny: I believe so. [15:48:49] <dilfridge> ok, let's consider a wurst-case scenario [15:49:03] <rich0> dilfridge: systemd eats the repo? :) [15:49:04] <blueness> mgorny, email the community whree the hooks are so we can take a look at them [15:49:07] <dilfridge> mgorny: if things fail badly, can we go back to cvs? [15:49:25] -*- radhermit is going afk for a bit [15:49:25] <dilfridge> (not that I want to, this is merely contingency planning) [15:49:25] <mgorny> they were linked in my mails :P [15:49:36] <rich0> dilfridge: that would be painful, at least if you wanted to preserve all the individual commits. [15:49:44] <creffett|irssi> dilfridge: we would need a way to go git -> CVS to dump the history back into CVS [15:49:44] <mgorny> dilfridge: i guess so though 'over dead commit access' of many people :) [15:49:50] <rich0> If we want to do some kind of big test, better to do it first. [15:50:12] <creffett|irssi> dilfridge: you could compromise, get a git->CVS bridge and keep the old CVS repo around for a little while until we're sure the bugs have been ironed out [15:50:14] <dilfridge> preserving individual commits is second order problem, first priority would be to keep us functional. [15:50:19] <dberkholz|mob> Can we stand up a beta, tell people to play with it for a week or so, then do the real cutover [15:50:34] <dberkholz|mob> Or is our infra setup not able to cope with that kind of duplication [15:50:44] <rich0> Well, having a read-only cvs for reference for a while makes sense. We can keep a CVSROOT tarball forever, basically. [15:50:48] <dilfridge> in this emergency case I'd be happy enough with seeing one big cvs commit "forward one week" [15:51:06] <rich0> dberkholz|mob: we're basically doing the beta on github already. [15:51:19] <rich0> I suppose it could be done on infra as well. [15:51:22] <dberkholz|mob> Yeah but it's not full fledged [15:51:27] <dberkholz|mob> That's a repo test, not a full distribution test [15:51:43] <rich0> It certainly doesn't involve mirrors and all that. [15:51:49] <mgorny> excelsior has all the git+rsync bits [15:51:49] <rich0> Were you thinking full-scale end-to-end? [15:51:53] <dilfridge> not sure how it could be full-fledged without switching e.g. the rsync mirror generation etc [15:52:05] <dilfridge> and that would also affect our users, so no beta [15:52:07] <dberkholz|mob> Don't need full scale, but at least full stack [15:52:11] <rich0> We do generate all the way up to rsync trees though. [15:52:24] <rich0> We can try to aggressively promote them. [15:52:27] <dilfridge> sounds good. [15:52:34] <WilliamH> So are we keeping rsync after the migration (I'm confused about that part) [15:52:40] <mgorny> yes [15:52:45] <mgorny> users can choose between git & rsync [15:52:47] <rich0> Though all users can really do is sync them. Unless we systematically sync all cvs commits it won't be the same as cvs. [15:53:04] <rich0> mgorny: ++ - at least for now. [15:53:14] <rich0> I think we should just generate the existing rsync, webrsync stuff. [15:53:18] <rich0> Allow git as another option. [15:53:24] <mgorny> this also means end users will not notice much of a difference [15:53:24] <rich0> Then maybe consider more change down the road. [15:53:38] <mgorny> except for disappearing changelogs and possibly resigned manifests [15:53:45] <blueness> hmm ... will there be a delay between developer commits and staging to the mirrors like there currently is? [15:54:23] <rich0> blueness: there would have to be some [15:54:35] <rich0> mgorny: any idea what it would be? [15:54:37] <mgorny> depends on exact implementation [15:54:49] <rich0> It shouldn't be any worse than what we have now, at least. [15:54:49] <blueness> we should try to keep one, just in case [15:54:55] <mgorny> right now, there's ~3 minutes between dev git & master rsync, i think [15:54:57] <rich0> I'd think that git will sync faster if nothing else. [15:55:06] <mgorny> mirrors could fetch more often than rsync [15:55:12] <mgorny> than with rsync* [15:55:13] <dberkholz|mob> With git we could take a more push-driven approach [15:55:20] <rich0> cvs syncing requires a full tree traversal. git syncing is a lot smarter. [15:55:21] <dberkholz|mob> Instead of 30 minute cron jobs or whatever [15:55:37] <rich0> (you basically have COW at each level of the tree) [15:56:20] <rich0> Ok, I have a hard stop in 4 mins. [15:56:26] <rich0> Anything else on this? [15:56:37] <rich0> I guess my question is, what next from us? [15:56:43] <rich0> Do we need to approve some final cutover plan? [15:56:51] <mgorny> 'd love to have games team decision today thouhg :P [15:56:55] <rich0> Or do we just leave it up to infra and the migration team to just tell everybody what to do? [15:57:21] <rich0> I don't necessarily mind if the rest continue on without me, but somebody else would have to chair that. [15:57:30] <rich0> But, if we can wrap up git... [15:57:45] <rich0> Does anybody feel that we need a final council vote on "all systems go?" [15:57:48] -*- WilliamH thinks we really can't do anything more at this point. [15:57:55] <rich0> Or can we just hand over the keys? [15:58:10] <dilfridge> we need to take the step at some point. [15:58:14] <dilfridge> so why not now. [15:58:20] <rich0> Obviously we can step in off-schedule if we see cause to panic. :) [15:58:22] <blueness> i'd like to hear from infra about this [15:58:27] <dilfridge> that said, *some* input from infra would be nice. [15:58:30] <blueness> since they have to brunt the work [15:58:40] <rich0> Well, nothing happens until they do something anyway. [15:58:40] <blueness> dilfridge, collision! [15:58:47] <dilfridge> :] [15:58:58] <blueness> rich0, yeah but we really need to know if they're okay with this plan [15:59:06] <rich0> I was thinking more in terms of whether we can just let infra and the git migration project run with the rest. [15:59:24] -*- WilliamH doesn't see any reason not to [15:59:40] -*- creffett|irssi needs to go shortly as well [15:59:46] <rich0> Ok, I think we're basically all for moving forward, but we just want to make sure that infra is coordinated. [15:59:49] <dilfridge> why not... we could just do a vote along "we don't see any big remaining obstacles and advise infra / the git migration project to proceed at their pace" [16:00:05] <rich0> dilfridge: I'm fine with that. [16:00:08] <rich0> Any strong objections? [16:00:15] <blueness> not really [16:00:27] <rich0> Ok. Let's vote, I have to RUN! :) [16:00:27] <creffett|irssi> no objections [16:00:29] -*- rich0 yes [16:00:31] -*- creffett|irssi yes [16:00:34] -*- dilfridge yes [16:00:34] -*- blueness yes [16:00:38] -*- WilliamH yes [16:00:44] <dberkholz|mob> ye [16:00:45] <dberkholz|mob> s [16:00:56] <dilfridge> rich0: shall I take over or do we postpone the rest? [16:01:05] <dberkholz|mob> I've gotta run too, as did somebody else [16:01:06] <rich0> radhermit ? [16:01:13] <rich0> I suggest we adjourn. [16:01:13] <dilfridge> ok then postpone I guess [16:01:16] <rich0> Next week? [16:01:20] <blueness> next week [16:01:24] -*- WilliamH is fine with next week [16:01:24] <dilfridge> next week [16:01:49] <dberkholz|mob> wfm [16:02:00] <rich0> Ok, we are adjourned until next week. Radhermit, ping me with your vote on the last bit. :) [16:02:17] <rich0> I'll post log/summary [16:02:20] <rich0> Thanks, all! [16:02:32] <rich0> sorry, mgorny [16:02:40] <rich0> games + herds next time [16:02:42] <rich0> adios 1.1 xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt?rev=1.1&content-type=text/plain Index: 20141021-summary.txt =================================================================== Roll call ========= Present: blueness, dilfridge, radhermit, rich0, ulm, williamh Absent: dberkholz Deprecating and killing the concept of herds ============================================ "The council is in favor of retiring herds, allowing non-maintainer aliases to exist, and having a way to distinguish between individuals, projects, and non-maintainer aliases in metadata.xml. The details of how to implement this will be worked out in the lists before the next meeting." Aye: blueness, dilfridge, radhermit, rich0, ulm, williamh Status of Games Team ==================== "Council deferrs to radhermit to continue working with the games team on the organization issues for another month. Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes." Aye: blueness, dilfridge, radhermit, rich0, ulm, williamh Status of Projects ================== 1) the multilib porting and subsequent disposal of emul-... packages 2) the migration of project web pages to our wiki http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2212/ See meeting log for further details. No actions by council. Bugs assigned to Council ======================== (5 minutes) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings dberkholz is reminded to follow-up... Open floor ========== (5 minutes) 1.1 xml/htdocs/proj/en/council/meeting-logs/20141021.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141021.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20141021.txt?rev=1.1&content-type=text/plain Index: 20141021.txt =================================================================== [15:00:23] <rich0> Ok, I have 19:00 on my watch. [15:00:27] <rich0> Roll call... [15:00:32] -*- ulm here [15:00:36] -*- WilliamH here [15:01:20] <rich0> blueness, dilfridge, radhermit? [15:01:20] <radhermit> here [15:02:45] <rich0> I just sent a text to dberkholz [15:02:59] <dilfridge> here [15:03:07] <rich0> Ok, just blueness [15:03:44] <blueness> here! [15:03:55] <blueness> shit i got busy in another channel [15:03:58] <blueness> but i'm ready :) [15:04:06] <rich0> Ok, let's get started - no word from dberkholz but I did text him. [15:04:09] <blueness> and there's the text :) [15:04:15] <blueness> at least this time i wasn't asleep [15:04:43] <rich0> Ok, same agenda, but we're up to Deprecating and killing the concept of herds [15:04:55] <rich0> Looks like mgorny is at the center of every agenda item today. :) [15:04:57] <WilliamH> kill them with fire and nukes [15:05:11] <blueness> WilliamH, no kill them with loooove [15:05:17] <rich0> Nah, nukes are reserved for cvs keywords. [15:05:26] <blueness> ah yes [15:05:29] <dilfridge> not kill but correct the definition (people not packages) [15:05:37] <ulm> I'm o.k. with killing herds, as long as we keep a distinction in metadata if the maintaining entity is a person or a team [15:05:38] <blueness> okay i'm all for killing herds, but two things [15:06:00] <blueness> 1) we keep the mail aliases somehow so that we can track packages [15:06:04] <WilliamH> ulm: you can tell that in the <maintainer> tags [15:06:14] <blueness> so maybe change <herd> to just <email> [15:06:24] <dilfridge> <maintainer><email>k...@gentoo.org</email><name>Gentoo KDE team</name></maintainer> [15:06:31] <dilfridge> compare this ^ to [15:06:36] <dilfridge> <herd>kde</herd> [15:06:38] <blueness> i like that [15:06:48] <rich0> Would we require all packages to have a maintainer or project listed to be considered maintained? [15:06:54] <WilliamH> dilfridge: nuke the <herd> tag [15:06:57] <ulm> dilfridge: that's not what the DTD defines as name [15:07:00] <rich0> That is, just an alias isn't good enough unless it is a real project? [15:07:01] <blueness> 2) we need to really figure out what the relationship between herds and projects are [15:07:02] <WilliamH> dilfridge: it is unnecessary [15:07:05] <ulm> name is for a person [15:07:27] <blueness> i don't even know what teams i'm on anymore because i've just been working with herds aka mail aliases [15:07:35] <WilliamH> blueness: herds are groups of packages, maintained by devs who are members of projects. [15:07:36] <dilfridge> if we can come up with a similarly concise metadata fomulation then I am for nuking something. I'm not happy to blow up all metadata files to infinity. [15:07:46] <radhermit> so this doesn't kill herds, just changes metadata? I'm fine with that, never liked the 2nd layer of redirection [15:08:13] <blueness> radhermit, that's my understanding [15:08:14] <ulm> dilfridge: +1 [15:08:15] <WilliamH> blueness: for example, the accessibility project maintains the accessibility and gnome-accessibility herds. [15:08:19] <blueness> so we're really not loosing any data [15:08:21] <rich0> I think we're all for simplifying things here. I'm not quite sure we are solid on what we want to change TO. [15:08:40] <dilfridge> a) keep metadata.xml somehow short and concise. [15:08:55] <radhermit> just use straight email addresses in metadata only [15:09:01] <ulm> WilliamH: same for emacs team, it maintains emacs and xemacs herds [15:09:08] <dilfridge> b) kill the concept "herds=sets of packages" (because noone uses it like that) [15:09:19] <blueness> on point b correct [15:09:42] <WilliamH> The <herd> tag should go [15:10:11] <ulm> WilliamH: replace it by <project> or <team>? [15:10:13] <dilfridge> which leads us to - what else is needed after a) and b) is done? redefine former herds as teams? [15:10:23] <rich0> Should metadata have a way to distinguish between personal and alias emails? Can alias emails be "maintainers" unless they're projects? Where do non-maintaining aliases go? [15:11:00] <rich0> dilfridge: I think we should define where we want to be. Getting there is a simpler problem. [15:11:14] <dilfridge> we could introduce a <team> tag that goes to a x...@gentoo.org alias [15:11:23] <blueness> dilfridge, that would be better [15:11:26] <dilfridge> same usage as herd today [15:11:33] <mgorny> why extra tags? <maintainer type="xxx"> [15:11:41] <rich0> mgorny: ++ [15:11:44] <rich0> That was my thought. [15:11:47] -*- WilliamH agrees with mgorny here, why keep tags? [15:11:51] <blueness> i've got this gut feeling that we need to define the existing and members so we know who is taking care of what packages [15:11:54] <dilfridge> because it's an extra 20 characters that I have to type. [15:11:54] <radhermit> <maintainer type="bot"> [15:12:02] <rich0> But what about aliases that aren't maintainers? Do we want to ban them? Only true projects can have aliases? [15:12:17] <blueness> we want aliases that are not maintaiers [15:12:25] <dilfridge> sure [15:12:27] <WilliamH> dilfridge: here specifically does *not* go to an email@g.o I don't think, you have to look it up in herds.xml [15:12:34] <WilliamH> s/here/herd/ [15:12:38] <rich0> Maybe the tag should be <email type="maintainer"> [15:12:42] <dilfridge> WilliamH: yes, but that's an abomination [15:12:56] <blueness> rich0, interesting idea [15:12:59] <dilfridge> one level of indirection beyond sanity [15:14:16] <rich0> So, some principles. Get rid of herds. Have email in metadata, and have a way to tell if the email is personal, proejct, or just non-maintaining alias. [15:14:21] <ulm> just rename <herd> to <team> [15:14:26] <WilliamH> Ok, a maintainer tag contains a name and an email... that email could be an alias, just like we do now... [15:14:35] <ulm> no attributes or other such xml abominations [15:14:36] <dilfridge> rich0, ulm: ++ [15:15:00] <mgorny> ulm: that's extra work for no benefit [15:15:02] <blueness> rich0, yeah that sounds okay [15:15:03] <rich0> ulm: what is a "team"? :) Just an email address, that may or may not be a project, and which may or may not maintain a package? [15:15:15] <dilfridge> with the distinction that <team>x</team> directly maps to x...@gentoo.org without exceptions [15:15:22] <ulm> mgorny: we'll have to update the dtd in any case [15:15:31] <rich0> Ok, is our goal to fully spec this out today, or do we want to punt on the details and resolve next meeting? [15:15:43] -*- WilliamH is against a team tag [15:15:46] <rich0> Maybe we just vote on the direction, and then let the DTD be fixed on the lists or something. [15:15:49] <ulm> rich0: a team is the group of devs maintaining what is currently called a herd [15:15:50] <blueness> rich0, this is too complex for me to think on the fly [15:16:03] <WilliamH> just use a maintainer tag... [15:16:08] <rich0> blueness: that is my concern - I don't just want to bikeshed the solution in 10mins. [15:16:12] <WilliamH> maintainers can be aliases... [15:16:33] <rich0> We can vote on the general direction and requirements, but then let the implementation be worked out on the lists with a final vote. [15:16:38] <rich0> We can also propose a migration plan on the lists. [15:16:51] <rich0> Until today we didn't really know where everybody stood on it. [15:17:05] <dilfridge> please migrate after git, it will make it so much more sane [15:17:08] <rich0> That would be my proposal. [15:17:28] <WilliamH> That's reasonable because it could all be done in one commit. [15:17:42] <rich0> ++ - Git will be done next Tuesday anyway. :) [15:17:49] -*- rich0 ducks [15:17:50] <WilliamH> heh [15:17:52] <radhermit> heh ok [15:18:13] <ulm> while we're at it, we could also make the maintainer tag for individual devs more concise [15:18:24] <ulm> nick should be enough for gentoo devs [15:18:39] <dilfridge> true [15:18:40] <rich0> ulm: what about proxies? [15:18:45] <rich0> Shoudl they get a different tag? [15:18:50] <rich0> (or attribute) [15:18:59] <radhermit> do we need to bikeshed this all now? [15:18:59] <rich0> I'm thinking about software that has to parse this stuff. [15:18:59] <ulm> rich0: they would keep full e-mail addresses of course [15:19:05] <radhermit> seems like something for lists [15:19:11] <WilliamH> rich0: I'm not sure that's necessary, because you can list multiple maintainers [15:19:14] <dilfridge> no @ -> dev [15:19:16] <rich0> radhermit: ++ [15:19:20] <dilfridge> ++ [15:19:21] <ulm> yeah, let's discuss it on lists [15:19:21] <blueness> http://dpaste.com/1J2YMFS [15:19:29] <rich0> Ok, then how about this for a quick summary: [15:19:32] <blueness> ^^ this seems to be what we are all saying [15:19:42] <mgorny> also note that metadata.xml is not only for gx86 but also for other repos [15:19:45] <mgorny> including non-gentoo [15:20:07] <WilliamH> mgorny: all we have to be concerned about is gentoo-x86 [15:20:24] <rich0> "The council is in favor of retiring herds, allowing non-maintainer aliases to exist, and having a way to distinguish between individuals, projects, and non-maintainer aliases in metadata.xml. The details of how to implement this will be worked out in the lists before the next meeting." [15:20:43] <blueness> yes! [15:20:47] <blueness> perfect [15:20:47] <ulm> +1 [15:20:51] -*- WilliamH yes [15:20:54] <radhermit> yes [15:20:57] -*- rich0 yes [15:20:57] -*- ulm yes [15:20:57] <dilfridge> yes [15:21:19] <rich0> Ok, I think that is all six of us [15:21:44] <rich0> Ok, recorded. [15:21:46] <rich0> Next topic. [15:21:51] <rich0> Status of Games Team [15:22:05] <rich0> Looking at the past summary, I believe radhermit was going to try to coordinate an election. [15:22:06] <radhermit> I sent one email, probably should have sent a followup one at some point [15:22:13] <radhermit> but that didn't happen [15:22:35] <radhermit> and no election happened because no new members stepped forward afaik [15:23:03] <WilliamH> So should we disband the team and assign everything to m-n then? [15:23:12] <rich0> I guess my question is whether the urgency to do something is the same? [15:23:15] <blueness> there's no real way of asking "who's on such and such a team" is there? [15:23:17] <dilfridge> WilliamH: would that help? [15:23:38] <rich0> We did give the go-ahead for people to avoid the team if they felt the need. [15:23:48] <rich0> So, it should be less of a barrier to progress. [15:23:50] <radhermit> I'll probably be in the same room as the current team leader sometime later today if that helps anything :P [15:23:55] <WilliamH> blueness: the project page should list the members [15:24:05] <radhermit> if you want me to force him to relinquish his crown ;) [15:24:20] <blueness> radhermit, how is that? [15:24:29] <blueness> i'm not even sure who's who on that team [15:24:33] <radhermit> We're both located near Boston [15:24:36] <dilfridge> https://wiki.gentoo.org/wiki/Project:Games [15:24:49] <blueness> oh mike [15:25:05] <radhermit> afaik, vapier probably doesn't care about being lead in games anymore [15:25:05] <ulm> heh, they moved the project page to the wiki? [15:25:10] <radhermit> I can ask him though [15:25:21] <dilfridge> btw that page is incorrect as per council decision [15:25:30] <dilfridge> "The Gentoo Games Project manages all games that are added into the Portage tree." [15:26:04] <rich0> radhermit: I definitely think you should talk to him if you have the opportunity. [15:26:10] <rich0> I'd be interested in how he feels about things. [15:26:23] <dilfridge> it was migrated by creffett|irssi by the way, most likely together with a bunch of others [15:26:30] <rich0> I don't want to block somebody from contributing - really most of this issue is about making sure games doesn't block others from contributing. [15:27:07] <blueness> mgorny, is my understanding correct that games is blocking the removal of emul-* stuff which is blocking multilib stuff from progressing? [15:27:22] <mgorny> not anymore [15:27:23] <radhermit> uh, I don't think so [15:27:27] <mgorny> multilib team did all the work for them [15:27:30] <radhermit> multilib should just fix stuff [15:27:33] <radhermit> since they want it done [15:27:39] <mgorny> though most of the dependencies are still insane [15:27:42] <radhermit> like how most stuff works in the tree [15:28:05] <blueness> okay so isn't that the original issue with that team? i mean if the original problem is gone, can we just leave it alone? [15:28:10] <blueness> or are there other issues? [15:28:26] <mgorny> did they solve the 10-year security issue? [15:28:27] <rich0> blueness: that is what I'm thinking. I don't want to just outright disband the team if they're doing something and they aren't really a problem. [15:28:29] <radhermit> people mentioned wanting to rework how games were installed/policies/etc [15:28:32] <mgorny> about nethack? [15:28:53] <rich0> mgorny: I guess I'd ask whether anybody else wants to solve that issue. If games is standing in the way that is one thing. [15:28:54] <blueness> hey! leave nethack alone ... its legendary! [15:28:58] <blueness> j/k [15:29:12] <WilliamH> <qa hat on> There are a number of games that are hard masked in the tree because of security issues. these are closed-source binaries so will probably not be fixed. </qa hat> [15:29:18] <radhermit> imo, if people are serious about changing stuff just join and start discussing more [15:29:22] <mgorny> it's not nethack being broken, it's games.eclass install of it [15:29:32] <rich0> WilliamH: If they're hard-masked, then it isn't a problem, right? [15:29:48] <rich0> If something is truly broken and isn't maintained, then that is a treecleaning issue. [15:29:50] <blueness> mgorny, okay thanks for that clarification [15:29:58] <WilliamH> rich0: what's the point of them being in the tree if they are hard masked for security and have been for years? [15:30:07] <rich0> WilliamH: do they still work? [15:30:14] <rich0> Maybe people still want to use it? [15:30:26] <blueness> mgorny, can we have a clear list of what's wrong with games team and then we can decide whether or not to leave lying dogs alone [15:30:55] <rich0> I'll buy that nethack is doing something wrong. The question is, is somebody gong to fix it, or are we talking about treecleaning nethack/ [15:30:56] <blueness> if the problems are big, we already get the picture that there's no movement there, we'll just disband and treeclean [15:31:00] <WilliamH> rich0: I'm not saying people shouldn't use it if they want to, I'm just questioning why it is still in the main tree instead of an overlay? [15:31:18] <blueness> WilliamH, that's a good idea, move it to an overlay [15:31:20] <ulm> blueness: it's all in mgorny's e-mail message, requiring an agenda item for a previous meeting [15:31:35] <ulm> mgorny: do you have a pointer to it? [15:31:37] <rich0> WilliamH: I get that, but why not allow it in the main tree? Does it hurt anything? [15:31:42] <mgorny> ulm: a minute [15:31:49] <blueness> ulm, mgorny i read it but i need a reminder [15:31:49] <mgorny> i think it's still in qa agenda [15:32:23] <WilliamH> rich0: we should unmask if it is going to stay in the main tree; p.mask should not be permanent. [15:32:28] <rich0> Making all of games m-n won't make the bugs disappear. [15:32:35] <ulm> mgorny: this on, I think: http://thread.gmane.org/gmane.linux.gentoo.project/3919 [15:32:35] <mgorny> http://article.gmane.org/gmane.linux.gentoo.project/3919 [15:32:36] <blueness> rich0, if there's a real problem(s) here, then let's act by saying we're give QA the power to move that stuff to an overlay and disband the game team [15:32:38] <ulm> *one [15:32:39] <rich0> WilliamH: I don't see why not, but we can take that offline. [15:32:44] <ulm> heh :) [15:33:07] <rich0> I'm not sure that there is a policy against having masked security problems in the tree permanently. [15:33:14] <rich0> As long as they build/etc. [15:33:19] <mgorny> but QA's dead! [15:33:24] <mgorny> we need to disband it too :P [15:33:29] <WilliamH> mgorny: not completely. [15:33:30] <radhermit> ... [15:33:32] <dilfridge> how about we state "everyone is free to join games team" instead? [15:33:45] <radhermit> didn't I sort of state that already? [15:33:50] <mgorny> but seriously, since last failed meeting i don't know if qa can work [15:34:04] <dilfridge> hmm? what did I miss this time? [15:34:08] <dilfridge> never mind, later [15:34:14] <mgorny> i also mailed the -qa@ list about games team, and never got any response [15:34:24] <blueness> mgorny, two problems i see: 1) political. demanding exclusivity. 2) the games.eclass breaking things like LFH [15:34:36] <dilfridge> 1) is solved [15:34:52] <dilfridge> 2) is solved by solving 1), noone is forced to use games.eclass [15:35:00] <dilfridge> what's the problem? [15:35:27] <blueness> dilfridge, well there's only one problem remaining and that is a treecleaning of bad packages [15:35:41] <rich0> blueness: I suggest we let QA/treecleaners do that per-package. [15:35:43] <blueness> if we remove that cruft from the tree than i'd be happy with the state of things [15:35:46] <ulm> dilfridge: lack of consistency throughout the tree is an issue [15:35:48] <mgorny> well, the problem is that even if not everyone is forced to use it, we end up being inconsistent [15:35:50] <dilfridge> ok, but that applies to all packages, not just games [15:35:55] <radhermit> it would be nice to do things in a uniform fashion [15:35:57] <radhermit> right [15:36:07] -*- WilliamH agrees with dilfridge [15:36:09] <mgorny> recently gnome team rewrote their packages to use games.eclass [15:36:15] <radhermit> seriously? [15:36:15] <dilfridge> huh? [15:36:15] <mgorny> because someone told them to [15:36:26] <dilfridge> that is kinda stupid. [15:36:29] <WilliamH> mgorny: who told them to? [15:36:34] <mgorny> hasufell, i think [15:36:39] <rich0> Still, I don't buy that we can NEVER have a package with a potential security issue in the tree if it is masked. But, I think we can let QA/tree-cleaners do their job first. [15:36:40] <dilfridge> LOL [15:36:49] <WilliamH> gees [15:36:49] <mgorny> now if i tell them to switch back, we end up in kinda stupid way [15:36:57] <WilliamH> mgorny: go for it. [15:37:08] <WilliamH> mgorny: they don't need to use games.eclass [15:37:35] <rich0> I don't have a problem with people using the eclass. It just shouldn't be mandatory, and of course that makes it kind of useless. [15:37:35] <dilfridge> this is getting slightly bizarr [15:37:39] <blueness> rich0, this looks messier than i thought. how about as a first line of action the council asks treecleaners to focus on games that are abondoned or seroius disrepair [15:38:03] <rich0> Well, first line of action is that radhermit chats with vapier, but yes, agree blueness [15:38:11] <blueness> rich0, yeah true [15:38:15] <rich0> I think we should separate org vs package issues. [15:38:18] <WilliamH> blueness: basically we just need to do the work in qa; [15:38:21] <radhermit> don't treecleaners scan for all pkgs with tons of open bugs anyway? [15:38:26] <WilliamH> blueness: following up on p.mask. [15:38:32] <WilliamH> blueness: not just games [15:38:34] <radhermit> i.e. they should already be catching things [15:38:46] <radhermit> open bugs that are ancient at least [15:38:47] <WilliamH> blueness: so I don't think there is any need for the council to do anything on that. [15:39:14] -*- WilliamH really isn't part of treecleaners [15:39:22] <WilliamH> I can't really speak for how they do things [15:39:47] <rich0> So, how about something like this: [15:39:47] <ulm> should we make any statement about policy? like games group, or non-FHS directory layout in games.eclass? [15:39:50] <ulm> or do we leave this to qa? [15:40:07] -*- WilliamH votes leave p.mask to qa [15:40:28] <dilfridge> leave it to qa for now, since the question of exclusivity has been decided [15:40:30] <radhermit> right, if people have serious issues with certain pkgs, contact qa [15:40:34] <radhermit> we don't micromanage [15:40:49] <blueness> right [15:41:03] <radhermit> if QA is unresponsive... well then [15:41:11] <radhermit> find some new QA members? :) [15:41:20] <mgorny> i'm the new QA member :P [15:41:21] <rich0> "Council deferrs to radhermit to continue working with the games team on the organization issues for another month. Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes." [15:41:38] <mgorny> but i don't feel like stating 'i decide this because nobody else responded and qa was unable to meet properly' [15:41:49] <radhermit> heh that is always fun [15:42:06] <radhermit> we've had QA dictators in the past... ;) [15:42:08] <rich0> is creffett still the QA lead? [15:42:17] <WilliamH> rich0: yes [15:42:51] <rich0> Is there another election due soon? [15:42:58] <rich0> I'd think that would be coming up soon. [15:43:00] <dilfridge> december according to schedule, I think [15:43:12] <dilfridge> let me look it up [15:43:16] <rich0> Maybe we should just ping them and figure out where things stand. [15:43:25] <rich0> Thankless job I'm sure. :) [15:43:45] <rich0> In any case, I suggest we defer on games to radhermit and QA/treecleaners for another month. [15:43:50] <rich0> Maybe continue to monitor. [15:43:56] <ulm> dilfridge: 2013-12-16 was last election [15:44:00] <rich0> I don't think anybody wants to take any kind of direct action right now. [15:44:02] <dilfridge> yes [15:44:19] <rich0> Ok, was my proposal above worth voting on? We don't necessarily need to vote. [15:44:20] <dilfridge> bug 494454 [15:44:22] <willikins> https://bugs.gentoo.org/494454 "Vote of confirmation QA lead creffett"; Community Relations, Developer Relations; RESO, FIXE; dilfridge:council [15:44:23] <rich0> We can just ping them. [15:45:05] <dilfridge> rich0: you get a yes from me [15:45:07] <rich0> Ok, any objections to moving on in the agenda. [15:45:10] <ulm> rich0: voting is ok for me [15:45:19] <ulm> moving on, too :) [15:45:23] <rich0> ok, then let's vote: "Council deferrs to radhermit to continue working with the games team on the organization issues for another month. Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes." [15:45:27] -*- rich0 yes [15:45:30] -*- ulm yes [15:45:31] -*- dilfridge yes [15:45:35] <radhermit> sure [15:45:36] <blueness> yes [15:45:36] -*- WilliamH yes [15:45:43] <rich0> ok [15:45:48] <rich0> next item. [15:45:53] <rich0> Status of projects:\ [15:45:59] <rich0> the multilib porting and subsequent disposal of emul-... packages [15:46:12] <mgorny> i replide to the mail [15:46:19] <rich0> Anybody want anything further? [15:46:21] <mgorny> replied* [15:46:26] <rich0> I don't need to see mgorny dance... [15:46:37] <ulm> mgorny: any eta for stable unmasking? [15:46:43] <mgorny> i'm currently working on finishing qt work for qt folks [15:47:00] <mgorny> i think all issues are being worked out, so it's a matter of review + moving to the tree [15:47:02] <mgorny> then stabilizations [15:47:05] <radhermit> do qt5 work too while you're at it ;) [15:47:11] <dilfridge> ugh I see dev-lang/perl in the list :( [15:47:12] <mgorny> with arch teams... i'd say 1-2 months :P [15:47:33] <dilfridge> ok let's summarize, things are moving ahead. [15:47:34] <dilfridge> ok? [15:47:39] <radhermit> oh I see we finally have it in the tree masked, nevermind... [15:48:13] <dilfridge> https://wiki.gentoo.org/wiki/Multilib_porting_status < the ultimate list [15:48:20] <mgorny> qt4 is probably ~1 month too [15:48:38] <radhermit> libperl? [15:48:43] <dilfridge> yes [15:48:45] <radhermit> isn't that dead? [15:49:00] <dilfridge> the libperl package is dead, but that's just a library in dev-lang/perl [15:49:01] <radhermit> or merged with perl itself [15:49:04] <radhermit> right [15:49:10] <radhermit> but that list has the actual pkg [15:49:14] <mgorny> the emul- list is not 100% necessary [15:49:21] <radhermit> alright [15:49:22] <mgorny> we only port the packages that are actually necessary [15:49:28] <dilfridge> sys-devel/libperl is gone soon. [15:49:43] <mgorny> perl won't need to be multilib most likely [15:49:47] <dilfridge> phew [15:49:47] <mgorny> python may be necessary for samba-5 [15:49:51] <mgorny> unless we find way around it [15:50:07] <radhermit> next up... multilib PMS ;) [15:50:27] -*- dilfridge feels like kicking someone :o) [15:50:57] <dilfridge> ok about the migration of packages to the wiki [15:51:07] <dilfridge> s/packages/project pages/ [15:51:19] <rich0> dilfridge: go ahead [15:51:36] <dilfridge> the silly thing is, being in the metastructure project I'm probably the right person to talk to myself [15:52:02] <dilfridge> https://wiki.gentoo.org/wiki/Project:Wiki/Project_Page_Migration_Status [15:52:08] <dilfridge> this is the definitive list here [15:52:29] <dilfridge> just translating a page is in most cases (imho) trivial [15:52:41] <dilfridge> maybe we should propose a deadline? [15:53:07] <rich0> dilfridge: after that we disband x86 and amd64? :) [15:53:18] <dilfridge> :P [15:54:00] <rich0> I do think a deadline does make sense all the same. [15:54:07] <dilfridge> but seriously, it is not too much work per page. of course for one person doing all is a lot of work. [15:54:23] <rich0> For obviously-critical projects we may just have to do something, but some of those projects may be defunct. [15:55:45] <rich0> Ok, anything else on that? [15:55:55] <rich0> Do we want to actually take action? The agenda is just for status. [15:56:09] <dilfridge> status is "stalled in the middle" right now [15:56:22] <ulm> maybe send a reminder to the mailing list? [15:56:28] <dilfridge> yes, good idea. [15:56:38] <rich0> yeah, talk is cheap at least :) [15:56:59] <rich0> Ok, next agenda item is bug 503382 [15:57:01] <willikins> rich0: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council [15:57:10] -*- rich0 looks around the room [15:57:14] -*- blueness smacks head [15:57:34] <mgorny> i say disband previous council [15:58:10] <rich0> ok, moment of silence observed... [15:58:20] <ulm> that was dberkholz [15:58:22] <blueness> hd=eh [15:58:24] <rich0> yup [15:58:27] <blueness> erre heh [15:58:30] <rich0> Ok, we'll prod him. [15:58:40] <rich0> I don't see him on the list of chairs for this term [15:58:48] <dilfridge> :) [15:58:53] <rich0> Ok... [15:59:00] <rich0> Open floor [15:59:06] <rich0> Anybody want to take a shot? [16:00:00] <WilliamH> Ok, I have a question about a procedure... [16:00:02] <mgorny> i can say that bashcomp2 is progressing fast too :P [16:00:10] <mgorny> i filed a lot new bugs today [16:00:11] <rich0> WilliamH: go ahead [16:00:21] <WilliamH> I know that generally a package needs a last rites and 30 days before removing it from the main tree. [16:00:36] <WilliamH> Is that also true for a package that is in p.mask? [16:00:42] <rich0> WilliamH: might as well [16:00:44] <WilliamH> s/p.mask/p.mask already/ [16:00:48] <rich0> Unless there is some reason to rush. [16:00:57] <rich0> Or unless of course it is already masked for removal. [16:01:15] <rich0> My two cents at least. [16:01:21] <ulm> WilliamH: I'd keep the 30 days between last rites and removal there too [16:01:29] <ulm> but it's a guideline only [16:01:34] <dilfridge> I used to give a few days then too, as e.g. sending a last-rites mail "has been masked since..., will be removed in 10 days" [16:01:38] <blueness> rich0, et al. i have to run. i'll read the backlog [16:01:38] <rich0> Obviously copyright issues or such warrant an exception [16:01:45] <rich0> blueness: ok, [16:01:51] <WilliamH> dilfridge: that's reasonable. [16:02:22] <WilliamH> dilfridge: that's one reason I haven't pushed hard personally to work on p.mask. [16:02:33] <WilliamH> dilfridge: I wasn't sure how to go about that. [16:02:39] <dilfridge> ok [16:03:01] <rich0> Anything else on that? [16:03:16] <rich0> mgorny: ++ on bashcomp2. Just in time for my switch to zsh. :) [16:03:55] <rich0> Anything else for open floor? [16:04:36] <rich0> If not, we're done. Next meeting will be Nov 11 [16:05:10] <rich0> I'll post the summary shortly, and start the agenda for next month. [16:05:13] <rich0> Thanks all :)