Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
On Tue, May 14, 2013 at 10:19 AM, Peter Stuge wrote: > Rich Freeman wrote: >> Gerrit also requires letting the public push, but those pushes go >> to a contained area and each commit is isolated. > > Hm, how do you mean isolated? > > Gerrit introduces the convention to create a unique identifier for a > change the first time a commit is created. If later iterations of > that same logical change (e.g. a second commit after review) keep the > Change-Id line from the original commit message then Gerrit knows > that this commit is a new version of the old one as opposed to an all > new change. > Suppose master is Gentoo Portage. I clone it, make a change to package foo, and push that commit to gerrit. You clone it, make a change to package bar, and push that commit to gerrit. Those two commits go into two different requests and don't interfere (well, they might when merged if they contain conflicts - no avoiding that). If at that point somebody else clones the repo they get the official repo without either of our changes, until at some point our changes get merged. It is true that revisions of commits do update each other, but this is generally desirable. What is important is that each logical change stays isolated. The only way to do this with branching is to have a branch per change (which could be merged and deleted of course). Gitlab doesn't seem to support this though - I don't think there is any safe way to allow random public users to create branches, and of course if anybody does this they are published to the world. Gerrit keeps changes more tucked away, so that everybody is working off the official repo. If you just have everybody share one public branch then it will be a hodge-podge of commits that require a lot of cherry-picking to work with. The public branch itself might not even work, or it might need constant cleanup. It might even contain trojans so cloning it would be at your own risk (it would be safer to clone master and push to public, which means that everybody is stepping on each other's toes). Branches do make sense if you have groups working together on a single change. I'd encourage them for this use. However, in the case of isolated patches the Gerrit model seems better. Again, I could be missing some Gitlab feature. > > While Gerrit is probably most often used as a web application, it's > possible to perform most operations, including review, submit and > reject, via SSH. The only thing missing from the SSH interface is > doing inline review. The web interface allows writing review comments > per line in the commit, this is unfortunately not possible via SSH. > I know a lot of projects like Gerrit (Cyanogenmod comes to mind). Sure, it is Java, but I'd think it could be reasonably well-contained in a VM/etc. It could even be hosted - as long as we have backups/etc and can recover to our own infra I'd consider that pretty low-risk. Rich
Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
Rich Freeman wrote:
> Gerrit also requires letting the public push, but those pushes go
> to a contained area and each commit is isolated.
Hm, how do you mean isolated?
Gerrit introduces the convention to create a unique identifier for a
change the first time a commit is created. If later iterations of
that same logical change (e.g. a second commit after review) keep the
Change-Id line from the original commit message then Gerrit knows
that this commit is a new version of the old one as opposed to an all
new change.
Pushing to Gerrit looks and feels like pushing to a git repository but
in fact the push goes into Gerrit's own database ("contained area")
where it can be reviewed, iterated by pushing again as described
above, submitted (output into the project's (readonly) git repo) or
rejected.
The real beauty of Gerrit is that anything can be accepted into it
without affecting the project's real git repo at all, and that only
an OpenID is required for pushing.
Verification (testing) can be made a requirement before a commit can
be submitted in Gerrit, meaning that some test suite needs to pass
before a commit can enter the git repo.
Some of this can be orchestrated with multiple repositories and lots
of hooks, but Gerrit packages it all up quite nicely.
While Gerrit is probably most often used as a web application, it's
possible to perform most operations, including review, submit and
reject, via SSH. The only thing missing from the SSH interface is
doing inline review. The web interface allows writing review comments
per line in the commit, this is unfortunately not possible via SSH.
//Peter
Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
On Sun, May 12, 2013 at 3:18 PM, wrote: > - It supports "Merge Requests", which are almost the same as PRs on Github, > which allows user contributions to be reviewed quite easily. So, out of curiosity I set this up on a VM and started playing with it. It seemed like the UI for merge requests was limited to merges between branches on the same repository. Github lets you make pull requests between repositories. Logistically that is a BIG difference. With a Github-like model users don't need write access of any kind to the repository (they do their work in their own forks), but with Gitlab you'd need to give write access (not sure if you can limit that to only an incoming branch of some kind, which would be a free-for-all area (which might also create problems as this is essentially an arbitrary file hosting area)). I could be missing something though - seems like a useful tool but it might be more appropriate to closed teams than for public contribution. If somebody knows of something I missed by all means chime in. Gerrit also requires letting the public push, but those pushes go to a contained area and each commit is isolated. Again, let me know if I missed something. Rich
[gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
[...] > > Another option that looks nice is GitLab. > > How does it work? The screenshots look exactly like github. Maybe, I can summarize it up a bit: - GitLab is a Ruby-On-Rails Application => Requires very few setup on a gentoo system: ruby, a webserver and a mysql or postgresl database and redis. Some gems. That's it mostly. - It makes use of a lot of the FOSS-Code which was written by GitHub. - Itself is licensed under the MIT-License. - It used to be based around the gitolite shell, but nowadays has it's own shell to implement access restrictions on the managed repositories. - Repositories can be private (to users or teams) or public with write-access granted to individuals or teams. => Up to here, it's just a way to manage multiple git repositories via http and access them via git://, ssh://, http:// and https:// It can be used just the same way a pure gitolite installation can be used. (Which by the way is true for any repository on github as well). On top of that: - It supports "Merge Requests", which are almost the same as PRs on Github, which allows user contributions to be reviewed quite easily. - It can trigger web-hooks in a similar way to github. It has some other nice features - but I personally believe they are not very relevant to gentoo: - Issue tracking per git repository - Wiki per git repository I am running an instance of gitlab for some of my private projects. The instance is accessed from roughly a dozen scripts and me. I run it including it's database (aside to some other services) on a VServer, which has 1 CPU assigned to it and 1 gigabyte of ram. Accessing it never appeared any slower to me than accessing github (even given that low hardware). Though, i have no data on how it scales to bigger environments. Updates to it are release on a once-per-month basis. Most of the time they are quite straight forward and installed in less than 5 minutes. The overall configure on the above mentioned hardware took me roughly 2 hours (sql, nginx, ruby etc being already emerged). This is mostly due to the fact gitlab's author mainly targets ubuntu. But it wasn't very hard to adapt the instructions to Gentoo w/ OpenRC. Hopefully these datapoints help to fill up some gaps :-) Sascha
