[15:00:07] Ok, roll call :) [15:00:10] here [15:00:15] here [15:00:16] Sup [15:00:49] -*- creffett|irssi here for ulm, unless ulm is here already [15:01:02] blueness, dilfridge, ulm? [15:01:57] Ok, let's get started. [15:02:04] First item, future of einstall [15:02:14] http://thread.gmane.org/gmane.linux.gentoo.devel/92713 [15:02:14] http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2212/focus=4025 [15:02:27] Should einstall be banned in EAPI6. [15:02:32] Any comments beyond the lists? [15:02:37] -*- creffett|irssi reviews his notes [15:02:49] no comments here [15:02:54] none here [15:03:27] I don't have anything more to say [15:03:32] Ok, let's vote then. "Einstall will be removed from EAPI6." [15:04:07] -*- creffett|irssi yes [15:04:12] Yep [15:04:13] yes [15:04:16] yes [15:04:31] -*- rich0 yes [15:04:49] Ok, that's all of us [15:05:02] Next item... [15:05:11] https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 [15:05:20] Blueness is requesting approval on this. [15:05:24] someone want to text blueness? [15:05:30] good idea [15:06:24] sorry, here [15:06:26] I just texted him [15:06:55] Do we want to move on to git? [15:07:05] sure [15:07:06] I'd prefer to give him the option to present. [15:07:11] here!!! [15:07:11] Ok, let's move on to git. [15:07:16] sorry thanks rich [15:07:18] never mind. :) [15:07:22] rich0, [15:07:24] let's do glep64 - I think it will be faster [15:07:41] blueness: do you have any comments you want to make? [15:07:51] rich0, just a few points [15:07:58] its was discussed on gentoo-dev@ [15:08:14] it got feedback for ciarian and incorportated it [15:08:28] do you need me to repeate the motivation? [15:08:39] Nah - at least not for me. [15:08:42] I can read. :) [15:08:52] My only real comment is that it is a bit vague - deliberately so. [15:09:07] this is the latest version -> https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 [15:09:11] I don't mind approving it per se, but do we think that it will go anywhere? [15:09:37] Ie are the various package managers behind it? [15:09:37] Do we have agreement in theory from PM implementers? [15:09:38] rich0, i will try to work with ciarian and actually write code [15:09:55] blueness: what about pkgcore? [15:09:56] i'd like to hear from radhermit and package core [15:09:56] -*- dberkholz|mob high-fives rich0 [15:10:32] radhermit, ping ^^^ [15:10:45] also zmedico was in support [15:10:46] -*- radhermit is trying to skim through the mailing list thread :) [15:10:53] radhermit, okay [15:10:58] It sounds like most of this is in portage, it just needs the API to be written. [15:11:08] From what I know of portage, it won't be hard to do there. [15:11:17] Just needs commitment to the API. [15:11:27] can we version the vdb or something if we start properly specifying it? [15:11:40] maybe that's already in the glep [15:11:53] radhermit, i didn't mention a version to vdb [15:12:00] This GLEP doesn't really specify the VDB, so much as require an interface to it (without actually specifying it). [15:12:17] so mainly it's about standardized file naming? [15:12:17] for the reason rich0 just mentioned ^^^ [15:12:24] It might not hurt to incorporate some kind of VAPI versioning. [15:12:35] radhermit and standardizing what's exported [15:12:40] Seems to me that vdb version would be a portage internal matter [15:12:47] It basically is a spec for the spec. [15:12:48] What I care about is an API version on this [15:13:23] dberkholz|mob, i can add a sentence to that effect [15:13:24] dberkholz|mob: ++ [15:13:30] good idea [15:13:36] That should be a part of the API when it is specified. [15:13:58] basically what I meant [15:14:20] 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] It just feels a bit like approving a business case, vs a spec. [15:14:51] 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] SELinux and such sounded like a really good use case here. [15:15:27] You'd want that to work with any PM. [15:15:48] Or PaX in your example. [15:15:58] rich0, the way selinux eclass works now is it looks for reverse deps to do the markings [15:15:59] mostly I'd like to quit having to read through portage code to make stuff like eix work :) [15:16:04] with pkgcore-merged pkgs [15:16:35] 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] It might make sense to extend that API to installable packages as well. [15:16:46] yeah, i didn't even know about pkgcore until recently and it could benefit from this too [15:17:06] Ok, do we want to vote to approve this? [15:17:13] + [15:17:48] "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 " [15:17:56] Does that work? [15:18:00] sure [15:18:10] You can promise not to change it too much. :) [15:18:13] Ok, let's vote. [15:18:17] o [15:18:21] -*- rich0 yes [15:18:26] yes [15:18:27] -*- blueness yes [15:18:32] -*- creffett|irssi abstain [15:18:36] Yes + API version [15:18:45] -*- WilliamH abstain [15:19:09] yes with API version stuff [15:19:28] ulm, ? [15:19:37] creffett|irssi is ulm [15:19:49] Ok, that's everybody - 5-0 [15:20:03] And that includes the API version - I'll note that in the sumary. [15:20:21] rich0, and everyone, i think that just a one sentencer no? [15:20:26] 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] blueness: wfm [15:20:52] Ok, now the fun topic. [15:20:54] Git migration [15:21:11] wheee [15:21:14] shudder [15:21:19] My personal goal here would be to get opinions recorded anywhere we think they matter. [15:21:25] We're not going to bikeshed every detail. [15:21:39] -*- mgorny is around to help :P [15:21:41] 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] 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] Any other comments before we dive in? [15:22:34] bring it on! [15:22:44] 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] no [15:23:02] no [15:23:07] nope. [15:23:09] -*- blueness no [15:23:18] hell no [15:23:43] no [15:23:51] Ok, well, let's just call that a vote. :) [15:23:52] ! [15:24:26] Ok, let's skip "are we done yet" and move that to the end after we tackle all the specifics [15:24:34] Can yyyy/ prefix be dropped from gentoo-news? [15:24:44] We've been through that one once before. [15:24:54] http://archives.gentoo.org/gentoo-dev/msg_00f0a83b760b78c1baf32f118d1cb008.xml [15:25:01] https://bugs.gentoo.org/show_bug.cgi?id=523828 [15:25:23] mgorny: will dropping this still make your life easier with metadata? [15:25:38] rich0: a bit [15:25:59] i just find it utterly stupid that 'reading' and 'writing' formats are different [15:26:06] ++ [15:26:11] drop it [15:26:27] Any opposing commentary? [15:26:38] nah, no contraversy here [15:26:46] Nope [15:26:49] who needs to implement this infra? [15:27:07] someone commit to repo + infra change the script used for gen [15:27:32] 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] 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] yes [15:27:59] yes [15:28:04] Sure [15:28:49] ok [15:29:10] Ok, going in order of controversy... [15:29:15] Can we drop CVS headers post-migration? [15:29:24] -*- WilliamH yes [15:29:29] -*- rich0 burn with nuclear fire [15:29:31] yes please [15:29:33] KILL IT [15:29:38] heh [15:29:41] I don't think ghere is an equivalent to that in git. [15:29:43] er, I mean, yes [15:30:24] dberkholz|mob, radhermit - care to make it a vote? [15:30:37] blueness: also? [15:30:39] Yes pls [15:30:48] kill it of course [15:31:06] blueness: heh==yes? [15:31:18] yes [15:31:23] heh we're fast :) [15:31:33] ok [15:31:39] Now a bit more controversy. [15:31:49] 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] http://thread.gmane.org/gmane.linux.gentoo.project/4030/ [15:32:37] rich0: here's my question -- if someone did want to join the two trees locally, how much work would it be? [15:32:43] if we can arrangeit that they can be combined seamlessly into one, yes [15:32:51] I would prefer a spliceable one [15:32:55] mgorny: you probably have more git replace experience than I [15:33:19] git fetch history-remote; git replace ${first_commit_id} ${history_commit_id} [15:33:23] 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] (or teh other way around :P, easy to put on wiki) [15:33:47] I'd vote for spliceable too [15:33:55] 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] means? [15:34:06] meaning you can graft the old tree onto the new one [15:34:12] radhermit: exactly [15:34:14] if you want a giant, historical repo [15:34:24] Which ever one can get us up and running sooner. ;-) [15:34:33] 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] so it's fairly simple to do the join if someone wants to? [15:34:39] the old graft can technically be done later [15:34:39] So it would appear to have a continuous history. [15:34:45] creffett|irssi: yes, only time consuming for fetch :) [15:34:53] mgorny: okay [15:34:58] then yes, separate is fine with me [15:35:01] radhermit: dberkholz|mob: I don't understand what your "spliceable" version does different [15:35:06] I have a question... [15:35:06] rich0, what's the gain on the divisionb between historical and current? [15:35:14] blueness: I outlined that in my post. [15:35:22] k [15:35:25] The current historical migrations have issues. [15:35:43] If we improve on them, then the original "official" migration turns into baggage. [15:35:55] blueness: we can start immediately and care about the exact history later [15:35:56] You could still splice a new migration over the old one. [15:36:05] 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] blueness: 1.5G [15:36:24] It also sidesteps arguments over whether the current migration is good enough, and makes the migration MUCH faster. [15:36:25] WilliamH: basically, yes. we start from a current point. [15:36:26] 70M is 'current' afresh and grows [15:36:29] 1.5G is historical and grows [15:36:30] so speed size and simplicity [15:36:57] what happens in the far future when it gets 1.5GB again, can it be sliced again? [15:36:57] Ah I hadn't tracked the work on git replace. I'm fine with that [15:36:57] the conversion of the cvs history becomes a non-blocker, and non-critical project [15:37:16] exactly. I'd still run the best migration that I could. [15:37:32] But, issues with it don't hold things up, and it could be improved on later. [15:37:54] Any other questions/concerns? [15:38:10] git question, if you end up pulling two separate histories, is there a way to prune the old, unused objects? [15:38:16] mgorny: ^ [15:38:36] I think "git gc" will do that. [15:38:37] (not important now, just curiosity) [15:38:42] dilfridge: there will be no unused objects if you merge them via replace [15:38:55] ok [15:38:56] unless you mean after removing the history replace, then gc should catch them [15:39:02] ok [15:39:03] good [15:39:25] 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] hehe [15:39:56] The converted repository is pretty impressive, for all its faults. :) [15:40:04] Something like 3M objects I think. [15:40:27] Ok, anything else before we vote? [15:40:33] i'm good [15:40:48] 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] I just want to make sure that the join gets tested, but I'm assuming that will happen [15:41:07] dberkholz|mob: i've already tested it initially [15:41:09] "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] Awesome. [15:41:20] Any issues with the wording? [15:41:31] What does "current" mean [15:41:32] The "which can be spliced with git replace" should cover the testing concerns. [15:41:40] Last year, last X commits to each file, etch [15:41:45] Maybe historical and current ? [15:41:47] etc* [15:42:07] Current means basically what you have in /usr/portage, really. [15:42:10] newest version snapshot [15:42:14] Minus metadata/etc. [15:42:14] And i'd go with s/migrated/historical/ , "full history" or something like that [15:42:15] 'cvs up -dP' [15:42:20] Agree [15:42:23] with some cleanup [15:42:27] Oh a funtoo style thing with zero history [15:42:35] that's the safe way of ensuring that we don't end up starting with broken repo [15:42:35] "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] like current history migration causes [15:43:15] Well, we can at least get the CURRENT tree right with the migration. It is identical now. [15:43:25] Go one commit back and it is less so. [15:43:35] Ok, if no issues with the wording... [15:43:51] 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] yes [15:44:21] yes [15:44:30] -*- dilfridge yes [15:44:31] -*- WilliamH yes [15:44:44] k [15:44:56] ok, 7-0 [15:45:13] That brings us to, "are we done yet?" [15:45:37] 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] Beyond implementation. Like that's a minor issue. heh [15:46:05] mgorny: how's the status of whatever server-side hooks we need? [15:46:07] Also, what do we want the actual migration to look like? Do we need to approve the final cutover, etc? [15:46:23] 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] dberkholz|mob: ++ that is a problem with our current infra I think. [15:46:42] dberkholz|mob, yeah i'd like to see that [15:46:46] No reason the hooks/etc can't be FOSS. [15:46:53] dilfridge: mostly done, i think infra will handle the remaining updates [15:46:55] Obviously passwords/configs/etc can be private. [15:47:22] is anyone from infra around who cares to comment? _robbat21irssi? [15:47:45] Making this FOSS would help a lot with anybody interested in "rolling your own Gentoo" [15:47:59] my code is on github, i think [15:48:01] or bitbucket ;P [15:48:11] mgorny: I believe so. [15:48:49] ok, let's consider a wurst-case scenario [15:49:03] dilfridge: systemd eats the repo? :) [15:49:04] mgorny, email the community whree the hooks are so we can take a look at them [15:49:07] mgorny: if things fail badly, can we go back to cvs? [15:49:25] -*- radhermit is going afk for a bit [15:49:25] (not that I want to, this is merely contingency planning) [15:49:25] they were linked in my mails :P [15:49:36] dilfridge: that would be painful, at least if you wanted to preserve all the individual commits. [15:49:44] dilfridge: we would need a way to go git -> CVS to dump the history back into CVS [15:49:44] dilfridge: i guess so though 'over dead commit access' of many people :) [15:49:50] If we want to do some kind of big test, better to do it first. [15:50:12] 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] preserving individual commits is second order problem, first priority would be to keep us functional. [15:50:19] 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] Or is our infra setup not able to cope with that kind of duplication [15:50:44] Well, having a read-only cvs for reference for a while makes sense. We can keep a CVSROOT tarball forever, basically. [15:50:48] in this emergency case I'd be happy enough with seeing one big cvs commit "forward one week" [15:51:06] dberkholz|mob: we're basically doing the beta on github already. [15:51:19] I suppose it could be done on infra as well. [15:51:22] Yeah but it's not full fledged [15:51:27] That's a repo test, not a full distribution test [15:51:43] It certainly doesn't involve mirrors and all that. [15:51:49] excelsior has all the git+rsync bits [15:51:49] Were you thinking full-scale end-to-end? [15:51:53] not sure how it could be full-fledged without switching e.g. the rsync mirror generation etc [15:52:05] and that would also affect our users, so no beta [15:52:07] Don't need full scale, but at least full stack [15:52:11] We do generate all the way up to rsync trees though. [15:52:24] We can try to aggressively promote them. [15:52:27] sounds good. [15:52:34] So are we keeping rsync after the migration (I'm confused about that part) [15:52:40] yes [15:52:45] users can choose between git & rsync [15:52:47] 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] mgorny: ++ - at least for now. [15:53:14] I think we should just generate the existing rsync, webrsync stuff. [15:53:18] Allow git as another option. [15:53:24] this also means end users will not notice much of a difference [15:53:24] Then maybe consider more change down the road. [15:53:38] except for disappearing changelogs and possibly resigned manifests [15:53:45] hmm ... will there be a delay between developer commits and staging to the mirrors like there currently is? [15:54:23] blueness: there would have to be some [15:54:35] mgorny: any idea what it would be? [15:54:37] depends on exact implementation [15:54:49] It shouldn't be any worse than what we have now, at least. [15:54:49] we should try to keep one, just in case [15:54:55] right now, there's ~3 minutes between dev git & master rsync, i think [15:54:57] I'd think that git will sync faster if nothing else. [15:55:06] mirrors could fetch more often than rsync [15:55:12] than with rsync* [15:55:13] With git we could take a more push-driven approach [15:55:20] cvs syncing requires a full tree traversal. git syncing is a lot smarter. [15:55:21] Instead of 30 minute cron jobs or whatever [15:55:37] (you basically have COW at each level of the tree) [15:56:20] Ok, I have a hard stop in 4 mins. [15:56:26] Anything else on this? [15:56:37] I guess my question is, what next from us? [15:56:43] Do we need to approve some final cutover plan? [15:56:51] 'd love to have games team decision today thouhg :P [15:56:55] Or do we just leave it up to infra and the migration team to just tell everybody what to do? [15:57:21] I don't necessarily mind if the rest continue on without me, but somebody else would have to chair that. [15:57:30] But, if we can wrap up git... [15:57:45] 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] Or can we just hand over the keys? [15:58:10] we need to take the step at some point. [15:58:14] so why not now. [15:58:20] Obviously we can step in off-schedule if we see cause to panic. :) [15:58:22] i'd like to hear from infra about this [15:58:27] that said, *some* input from infra would be nice. [15:58:30] since they have to brunt the work [15:58:40] Well, nothing happens until they do something anyway. [15:58:40] dilfridge, collision! [15:58:47] :] [15:58:58] rich0, yeah but we really need to know if they're okay with this plan [15:59:06] 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] Ok, I think we're basically all for moving forward, but we just want to make sure that infra is coordinated. [15:59:49] 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] dilfridge: I'm fine with that. [16:00:08] Any strong objections? [16:00:15] not really [16:00:27] Ok. Let's vote, I have to RUN! :) [16:00:27] 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] ye [16:00:45] s [16:00:56] rich0: shall I take over or do we postpone the rest? [16:01:05] I've gotta run too, as did somebody else [16:01:06] radhermit ? [16:01:13] I suggest we adjourn. [16:01:13] ok then postpone I guess [16:01:16] Next week? [16:01:20] next week [16:01:24] -*- WilliamH is fine with next week [16:01:24] next week [16:01:49] wfm [16:02:00] Ok, we are adjourned until next week. Radhermit, ping me with your vote on the last bit. :) [16:02:17] I'll post log/summary [16:02:20] Thanks, all! [16:02:32] sorry, mgorny [16:02:40] games + herds next time [16:02:42] adios