On Mon, Sep 15, 2014 at 11:50 PM, Brian Harring <ferri...@gmail.com> wrote: > > On Sun, Sep 14, 2014 at 10:33 AM, Rich Freeman <ri...@gentoo.org> wrote: >> >> On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny <mgo...@gentoo.org> wrote: >> > >> > Of course, that assumes infra is >> > going to cooperate quickly or someone else is willing to provide the >> > infra for it. >> >> The infra components to a git infrastructure are one of the main >> blockers at this point. I don't really see cooperation as the issue - >> just lack of manpower or interest. > > > I can't speak for current gentoo infra, but it'd help to think through > exactly who will have RO access to the git repo. > > Trying to have the entire gentoo userbase accessing the repo via git is > going to be resource intensive- if you're intending that, well, start > donating frankly. > > If however you're angling for just devs having git access, and utilizing the > existing rsync mirror, that should be a helluva lot more doable (even with > shitty hardware).
I believe that is the proposal here. There would be a dev-only main repository which is where all commits would go. Then there would be a power-user sync repo derived from that, and then an rsync tree derived from that. This isn't all that different from what we do with cvs. Git is pretty easy to mirror, since it is after all a distributed system at its heart. It would probably make sense to do one push/pull from the main repository to the power-user repo, do whatever magic needs to be done with it, and then push out from there to a mirror network, github, wherever. We'd probably want mirrors of both the original dev tree and the one with metadata and such. >> People love to point out linux and its insane commit rate. The thing >> is, the mainline git repo with all those commits has exactly one >> committer - Linus himself. They don't have one big repo with one >> master branch that everybody pushes to. At least, that is my >> understanding (and there are certainly others here who are more >> involved with kernel development). > > > To be frank, I think you're seriously overthinking it and worrying about a > nonissue. Worrying about this while ignoring security enhancements like > requiring signed commits on push is a bit weird to me. So far the discussion in the thread has included the commit signing issue. I tend to agree that commit rate probably won't be a problem after some discussion, as long as we don't require a repoman check 100% of the time in-between pull and push. For a single package that won't be a problem, but doing it at the category/tree level is just going to make collisions inevitable. > One additional point no one has mentioned; when cutting over to git, > afterwards someone will need to go through and rip out all of the cvs $Id > style tags that exist in the tree- depending on how folks are doing the > conversion, it might be worth just jamming that in right off the bat rather > than trying to clean the tree afterwards. I'd suggest that we not go too much further with editing history - consolidating Manifest/package commits did make sense, and the other fixes do as well. I'd prefer not to go trying to remove keywords from the tree during conversion. We've already had all kinds of headaches from keywords as it is (especially with patches/etc). I suggest that we initially convert the tree and leave the keywords in, and we can always clean them up later, either by script or manually. I'd suggest keeping scripting to a minimum guaranteed-safe level (such as just our ebuild headers), and leave it up to maintainers to get any stray ones. In-band signaling is lousy design in this day and age. Oh, did somebody bring up Changelogs? :) > ~ferringb, who was enjoying his retirement very much thank you I appreciate your email - there is a lot of history we can stand to benefit from. I think I have a container set up now that can efficiently migrate cvs->git using your scripts, and I'm just doing some more testing and work to make it fully transportable. From there we just need to figure out where to run it when the time comes, which should be the easy part. I do believe that mgorny was offering to step up to help out with the scripting though. If we have the scripts/hooks needed to manipulate gentoo-x86 to produce the various trees, then I think that transplanting them to infra will not be a difficult next step. Really that part is the part which is most lacking right now, so if a few are willing to step up on this I think we can get somewhere. -- Rich
