diff options
Diffstat (limited to 'meeting-logs/20141021.txt')
| -rw-r--r-- | meeting-logs/20141021.txt | 405 |
1 files changed, 405 insertions, 0 deletions
diff --git a/meeting-logs/20141021.txt b/meeting-logs/20141021.txt new file mode 100644 index 0000000..28360bc --- /dev/null +++ b/meeting-logs/20141021.txt @@ -0,0 +1,405 @@ +[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>kde@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 xxx@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 :) |