Joachim Durchholz via llvm-dev
2016-Feb-25 15:01 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Am 25.02.2016 um 14:41 schrieb Renato Golin:> On 25 February 2016 at 12:46, Joachim Durchholz via llvm-dev >> What workflow are you comparing this to, if a pull request is a penalty? > > Today, 100s of people commit directly.Ah. I wasn't aware of that, I thought LLVM had a gatekeeper model. > In a GitHub style, 100s of> people will have to wait for a merge from a few folks.I guess in that case, you'd probably give these people write access to the GitHub repo. It would probably be a good idea to prevent them from force-pushing and rebasing on the master branch so they cannot change recorded history. I am not sure whether GitHub allows that kind of restriction. > Those few folks> will have the additional job of merging lots of patches. It's more > like GCC, where maintainers are gate-keepers, and not one we have used > so far. I'm ok with it, but other people might not.It would be a considerable workload, but it would also be a considerable QA measure. From what I have seen, QA seems quite healthy on LLVM so I suppose the project will find that unattractive.>> Nobody is allowing 100s of committers to push to master, that would be >> silly. > > My personal preference is to not do that. I can't even cope with > myself pushing to master from different repositories, let alone 100s > of people. But I take it everyone else is indicating that would be the > way forward.I do not think this is on the table yet.> I haven't mastered git enough to know the pros and cons, but you seem > certain. Can you share your thoughts on the subject?Well, PRs are a good way to discuss proposed patches, so you can take the discussion there. Particularly if the git hoster gives you all the web forum thingies you want, including the ability to be helpful with Markdown. Also, a PR is easy to integrate once it's done. So while the PR route is very, very unattractive if there's a readymade patch that you just need to integrate, it's a useful tool while the patch is being built, assuming the PR runs through a website that offers a discussion. It's just very slick if you don't have to quote some code just to say "I'd like to have xxx changed on line 512 of that patch", if you can simply point to the line of code and can say "I'd like to have xxx changed here". You can write annotations while you read - it does encourage write-before-you-think so it does have its downsides, but it is still a big timesaver because everybody is known to be in the same boat wrt. what line of code one is talking about. Now that's the website side of things. On the git side of things, you need to make sure that history isn't rewritten official branches such as master. One way to achieve that is protecting those branches (that's the GitLab mechanism, GitHub implemented something similar last fall but I don't know if it's really the same); in that case people can still push to master without risking history. The other would be setting up a clone and going through PRs even if you don't need a review. PRs do not really protect you against a history rewrite, they can still kill history - but you'll have to force-pull that so the people who do the pull will be alerted to potential damage. On many projects, people still go through PRs even if they have direct write access. Simply to make sure that a second pair of eyes have looked at the code before it goes in. It does require disciplined committers, so this does not work too well in practice. To make it fly, committers need to priorize reviewing over committing and keep that up; I do not know whether that's a viable policy for LLVM. It does have its advantages if everybody knows his code will be eyeballed before it goes in though. But if it's a policy change for LLVM, this is something to consider for experimentation after the GH repo is set up, nothing that's up for decision right now.> The main reason to move to GitHub/Lab is one of cost: storage, > bandwidth and uptime, not one of tools.For that, public git hosting services are a no-brainer. You need to look at permissions because you can't simply set up gitolite, you have to live with whatever the service offers. > Even if we end up using the> GitHub interface in the future, I think we should consider a less > radical move first.The opportunities will be there from day one. Whether they are being used, or useful, is something to explore.> Of course, if the problems of moving to git but still following our > style becomes prohibitive, I think we should move to GitHub and use > their style, as IMHO, the cost argument is stronger than the tooling.The GitHub "flow" isn't the right one for every project, so the tooling does matter.
Renato Golin via llvm-dev
2016-Feb-25 15:34 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
On 25 February 2016 at 15:01, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Well, PRs are a good way to discuss proposed patches, so you can take the > discussion there. Particularly if the git hoster gives you all the web forum > thingies you want, including the ability to be helpful with Markdown. > Also, a PR is easy to integrate once it's done.Phabricator, for better or worse, has all those qualities.> On the git side of things, you need to make sure that history isn't > rewritten official branches such as master.Someone mentioned server-side hooks, I think that settles the problem.> On many projects, people still go through PRs even if they have direct write > access. Simply to make sure that a second pair of eyes have looked at the > code before it goes in.With the amount of commits we have (~100 / day), that would be impossible. But we still do that with Phab on the more complicated bits. We're aware of the benefits of code review, etc. I was wondering if you had some technical issues with git not being suitable. It seems there isn't anything particularly broken, that some hooks can't fix.> For that, public git hosting services are a no-brainer. > You need to look at permissions because you can't simply set up gitolite, > you have to live with whatever the service offers.That's a small cost, I'd say. And we can always move providers later on, which is a lot simpler with git than SVN.> The GitHub "flow" isn't the right one for every project, so the tooling does > matter.As a first step, we're not planning on following the GitHub flow, just using the GitHub storage and bandwidth. :) cheers, --renato
Sanjoy Das via llvm-dev
2016-Feb-25 16:25 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
One thing to watch out for: by default, in git, only the commit date (and not the *push date*) is part of the commit metadata. This means if I write a patch today and push it two months later, the commit date on the commit will be skewed by two months. We could fix this using a hook, but then the complication is that as soon as the hook changes the commit date to `date`, the SHA-1 of the newly edited commit will change. I'm not a git expert though, so it could be I'm overlooking something obvious. -- Sanjoy On Thu, Feb 25, 2016 at 7:34 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 25 February 2016 at 15:01, Joachim Durchholz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Well, PRs are a good way to discuss proposed patches, so you can take the >> discussion there. Particularly if the git hoster gives you all the web forum >> thingies you want, including the ability to be helpful with Markdown. >> Also, a PR is easy to integrate once it's done. > > Phabricator, for better or worse, has all those qualities. > > >> On the git side of things, you need to make sure that history isn't >> rewritten official branches such as master. > > Someone mentioned server-side hooks, I think that settles the problem. > > >> On many projects, people still go through PRs even if they have direct write >> access. Simply to make sure that a second pair of eyes have looked at the >> code before it goes in. > > With the amount of commits we have (~100 / day), that would be > impossible. But we still do that with Phab on the more complicated > bits. > > We're aware of the benefits of code review, etc. I was wondering if > you had some technical issues with git not being suitable. It seems > there isn't anything particularly broken, that some hooks can't fix. > > >> For that, public git hosting services are a no-brainer. >> You need to look at permissions because you can't simply set up gitolite, >> you have to live with whatever the service offers. > > That's a small cost, I'd say. And we can always move providers later > on, which is a lot simpler with git than SVN. > > >> The GitHub "flow" isn't the right one for every project, so the tooling does >> matter. > > As a first step, we're not planning on following the GitHub flow, just > using the GitHub storage and bandwidth. :) > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Sanjoy Das http://playingwithpointers.com