Kristof Beyls via llvm-dev
2016-Feb-25 08:55 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Ah - I do commit to the test-suite from time to time. So, could the github-based project be set up so that we can just do 'git push'? Or would we have to go through the pull requests route on every commit? I'm afraid I've never committed to any github project before, so I am a bit confused on how committing would work in practice. Obviously, I hope for the mechanism to commit to be simple - e.g. just do a git push from the command line. Before making the decision to move the repo, I think this part also should be sorted out. On 25/02/2016 09:50, Chandler Carruth wrote:> Yes, I would hope that for most this boils down to cloning a different > URL. Except for folks pushing patches to the test suite, I'm > moderately confident there would be no other difference. > > It's the pushing patches side that would need to be sorted out in more > detail. > > On Thu, Feb 25, 2016 at 12:48 AM Kristof Beyls <kristof.beyls at arm.com > <mailto:kristof.beyls at arm.com>> wrote: > > My biggest concerns and care-abouts are largely what Matthias > expressed below. > Most of them have been addressed already further down the thread. > > I hope that the move to github in practice would mean that the > only difference is that I 'git clone https://github...' instead of > 'git clone http://llvm.org/git/test-suite.git' ? > > Thanks, > > Kristof > > > On 24/02/2016 22:25, Matthias Braun via llvm-dev wrote: >> I don't really care where the repository is located, but I do >> have some comments on the future test-suite directions: >> >>> On Feb 24, 2016, at 12:57 PM, Chandler Carruth via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Subject kinda says it all. Here is my rationale: >>> >>> The test-suite is really weird relative to the rest of the LLVM >>> project: >>> 1) It contains all manner of crazily licensed code. >> That's indeed a good reason to move the repository away. >> >>> 2) We don't really care about the history at all. Any concerns >>> around linear history or bisection are pretty much irrelevant. >> We do care about the history. Sometimes benchmarks get fixed or >> tweaked which may change the results, we should be able to dig >> into the history to see what happened when. In any way retaining >> the history wouldn't be a problem, would it? >> >>> 3) We don't ever plan to have LLVM code move into or out from >>> the test-suite >> I could actually see moving llvm code into the test-suite (we >> already use lit code from llvm) but indeed move code out of the >> testsuite into llvm I don't foresee happening. >> >>> 4) Its already big, and really should be much bigger. We >>> shouldn't have incentives to keep stuff out of the test suite >>> because of size, hosting cost, or anything else. >> I agree with the goal of having a big test-suite. However I think >> there is a point where we should rather strive to have a stable >> base system for building and running tests, etc. and then have >> the actual benchmarks/tests being modules on top of that. We >> already have that situation today with External/SPEC* and I think >> it would be a good idea to have a mode where you just checkout >> more benchmarks into a test-suite subdirectory and they are >> automatically recognized and used (in fact that is something on >> my TODO list though at a very low position). >> >> - Matthias >> >>> >>> For all of these reasons, and also because I'd like to see how >>> well (or rather, how poorly) a service like GitHub actually >>> works for the project, it seems like splitting the test-suite >>> out of the current subversion repository and moving it there is >>> the right call. >>> >>> When I chatted with folks on the board, this made sense to them >>> as well, and I've made sure we have a reasonable LLVM >>> organization set up on GitHub and all the board members are on >>> it: https://github.com/llvm (I think only my membership is >>> public at the moment). >>> >>> There is still plenty to figure out about how to manage this on >>> github, but before doing anything else I just wanted to shoot an >>> email and see if folks like this idea. >>> >>> Thanks! >>> -Chandler >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160225/4020d3a0/attachment.html>
Chandler Carruth via llvm-dev
2016-Feb-25 08:57 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Well, clearly we can't actually move stuff until committing is worked out. But I didn't want to spend the effort to work out stuff like committing (and what the repo looks like) unless folks were generally favorable of the direction. On Thu, Feb 25, 2016 at 12:55 AM Kristof Beyls <kristof.beyls at arm.com> wrote:> Ah - I do commit to the test-suite from time to time. > So, could the github-based project be set up so that we can just do 'git > push'? Or would we have to go through the pull requests route on every > commit? > I'm afraid I've never committed to any github project before, so I am a > bit confused on how committing would work in practice. > Obviously, I hope for the mechanism to commit to be simple - e.g. just do > a git push from the command line. > > Before making the decision to move the repo, I think this part also should > be sorted out. > > > On 25/02/2016 09:50, Chandler Carruth wrote: > > Yes, I would hope that for most this boils down to cloning a different > URL. Except for folks pushing patches to the test suite, I'm moderately > confident there would be no other difference. > > It's the pushing patches side that would need to be sorted out in more > detail. > > On Thu, Feb 25, 2016 at 12:48 AM Kristof Beyls <kristof.beyls at arm.com> > wrote: > >> My biggest concerns and care-abouts are largely what Matthias expressed >> below. >> Most of them have been addressed already further down the thread. >> >> I hope that the move to github in practice would mean that the only >> difference is that I 'git clone https://github...' instead of 'git clone >> http://llvm.org/git/test-suite.git' ? >> >> Thanks, >> >> Kristof >> >> >> On 24/02/2016 22:25, Matthias Braun via llvm-dev wrote: >> >> I don't really care where the repository is located, but I do have some >> comments on the future test-suite directions: >> >> On Feb 24, 2016, at 12:57 PM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Subject kinda says it all. Here is my rationale: >> >> The test-suite is really weird relative to the rest of the LLVM project: >> 1) It contains all manner of crazily licensed code. >> >> That's indeed a good reason to move the repository away. >> >> 2) We don't really care about the history at all. Any concerns around >> linear history or bisection are pretty much irrelevant. >> >> We do care about the history. Sometimes benchmarks get fixed or tweaked >> which may change the results, we should be able to dig into the history to >> see what happened when. In any way retaining the history wouldn't be a >> problem, would it? >> >> 3) We don't ever plan to have LLVM code move into or out from the >> test-suite >> >> I could actually see moving llvm code into the test-suite (we already use >> lit code from llvm) but indeed move code out of the testsuite into llvm I >> don't foresee happening. >> >> 4) Its already big, and really should be much bigger. We shouldn't have >> incentives to keep stuff out of the test suite because of size, hosting >> cost, or anything else. >> >> I agree with the goal of having a big test-suite. However I think there >> is a point where we should rather strive to have a stable base system for >> building and running tests, etc. and then have the actual benchmarks/tests >> being modules on top of that. We already have that situation today with >> External/SPEC* and I think it would be a good idea to have a mode where you >> just checkout more benchmarks into a test-suite subdirectory and they are >> automatically recognized and used (in fact that is something on my TODO >> list though at a very low position). >> >> - Matthias >> >> >> For all of these reasons, and also because I'd like to see how well (or >> rather, how poorly) a service like GitHub actually works for the project, >> it seems like splitting the test-suite out of the current subversion >> repository and moving it there is the right call. >> >> When I chatted with folks on the board, this made sense to them as well, >> and I've made sure we have a reasonable LLVM organization set up on GitHub >> and all the board members are on it: https://github.com/llvm (I think >> only my membership is public at the moment). >> >> There is still plenty to figure out about how to manage this on github, >> but before doing anything else I just wanted to shoot an email and see if >> folks like this idea. >> >> Thanks! >> -Chandler >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160225/bf8c23db/attachment.html>
Renato Golin via llvm-dev
2016-Feb-25 11:33 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Kristof, Chandler, I think most of the responses seem favourable of the move, the concerns being which Git repo we'll use (GitHub, GitLab, BitBucket), but they're essentially identical on the git side. Infrastructure decisions will need to be taken into account, but that doesn't interfere with the "how we commit" discussion in any way. On 25 February 2016 at 08:55, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I'm afraid I've never committed to any github project before, so I am a bit > confused on how committing would work in practice.GitHub (and others) work by fork&pull-request. Simply put, you fork the original repo, do your changes, push to your repo and make a "pull-request" to the original repo. The added work is that one of the original repo owners will have to "accept" your pull-request, and GitHub then merges your changes. One of the design decisions of working this way is to have less committers on the main repo, and everyone else works on their own. This is great for collaborative development, but not very similar of the way we work. I believe all those services use something similar to git-new-workdir, so even if we have 100 forks of the test-suite, we won't have 100 x 1GB of used space. But if we move into a "less owners" scenario, we will penalise them with pull-requests all the time. Having said that, if we have enough, and if they, too, follow the fork & pull-request model, I think it could work.> Obviously, I hope for the mechanism to commit to be simple - e.g. just do a > git push from the command line.This is a little more complex. SVN is very conservative on history, and that saves us from destroying the origin. Git, on the other hand, allows anyone with write access to completely wipe out the repo. I don't think anyone would want to, but accidents do happen in git. As was said earlier, "git doesn't destroy data" in the sense that anyone with a good tree can re-make the origin, or even for a limited time (while commits are still in cache), you can cherry-pick them back and remake the tree. But buildbots will NOT be happy with broken trees. With new committers coming all the time, it's hard to control how much people know about git and GitHub (et al), so accidents are bound to happen more often than they should. The other problem is about release validation. We'll need to do separate "releases" of the test-suite for each LLVM release, since we can't run old tests with new releases and vice versa. Another way to work with git is like the Linux kernel, where different maintainers have different trees and they all merge from each other. I personally think that would be a nightmare for us. If anyone with more git experience than me can come up with a safe way to have 100s of committers pushing to master, I'd be happy to know. cheers, --renato
Mehdi Amini via llvm-dev
2016-Feb-25 11:54 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
> On Feb 25, 2016, at 3:33 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Kristof, Chandler, > > I think most of the responses seem favourable of the move, the > concerns being which Git repo we'll use (GitHub, GitLab, BitBucket), > but they're essentially identical on the git side. > > Infrastructure decisions will need to be taken into account, but that > doesn't interfere with the "how we commit" discussion in any way. > > > On 25 February 2016 at 08:55, Kristof Beyls via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I'm afraid I've never committed to any github project before, so I am a bit >> confused on how committing would work in practice. > > GitHub (and others) work by fork&pull-request.GitHub offers a simple *raw* git hosting. All the fork&pull-request is sugar in the web interface. You don't *have to* use it.> Simply put, you fork > the original repo, do your changes, push to your repo and make a > "pull-request" to the original repo. The added work is that one of the > original repo owners will have to "accept" your pull-request, and > GitHub then merges your changes. > > One of the design decisions of working this way is to have less > committers on the main repo, and everyone else works on their own. > This is great for collaborative development, but not very similar of > the way we work.We don't *have to* work this way on GitHub, you can allow "everyone" to commit (by asking to be added to the committer list just the same way we do it with the current svn servers). I.e. it is possible to move to GitHub and *not* change our current workflow.> > I believe all those services use something similar to git-new-workdir, > so even if we have 100 forks of the test-suite, we won't have 100 x > 1GB of used space. But if we move into a "less owners" scenario, we > will penalise them with pull-requests all the time. Having said that, > if we have enough, and if they, too, follow the fork & pull-request > model, I think it could work. > > >> Obviously, I hope for the mechanism to commit to be simple - e.g. just do a >> git push from the command line. > > This is a little more complex. SVN is very conservative on history, > and that saves us from destroying the origin. Git, on the other hand, > allows anyone with write access to completely wipe out the repo. I > don't think anyone would want to, but accidents do happen in git.This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088 You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You can have a whitelist of people allowed to rewrite the history...).> > As was said earlier, "git doesn't destroy data" in the sense that > anyone with a good tree can re-make the origin, or even for a limited > time (while commits are still in cache), you can cherry-pick them back > and remake the tree. But buildbots will NOT be happy with broken > trees. With new committers coming all the time, it's hard to control > how much people know about git and GitHub (et al), so accidents are > bound to happen more often than they should. > > The other problem is about release validation. We'll need to do > separate "releases" of the test-suite for each LLVM release, since we > can't run old tests with new releases and vice versa.Not sure how this part relates to git/github/svn? -- Mehdi> > Another way to work with git is like the Linux kernel, where different > maintainers have different trees and they all merge from each other. I > personally think that would be a nightmare for us. > > If anyone with more git experience than me can come up with a safe way > to have 100s of committers pushing to master, I'd be happy to know. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Joachim Durchholz via llvm-dev
2016-Feb-25 12:46 UTC
[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Am 25.02.2016 um 12:33 schrieb Renato Golin via llvm-dev:> Kristof, Chandler, > > I think most of the responses seem favourable of the move, the > concerns being which Git repo we'll use (GitHub, GitLab, BitBucket), > but they're essentially identical on the git side.I'm repeating myself but not they are not identical on the git side. Not for people without push access to the main repo anyway. There's the GitHub model where you need to set up a remote repository, and the non-GitHub model where you push to a branch within the master repository. Obviously, the non-GitHub model needs to protect people from messing with other people's branches, particularly not with the master branch, but that's pretty much a solved problem.> Infrastructure decisions will need to be taken into account, but that > doesn't interfere with the "how we commit" discussion in any way.Regular committers with write access to repositories have a different workflow than occasional contributors who send patches or pull requests. You need to consider all values of "we" that you are interested in getting work from.> I believe all those services use something similar to git-new-workdir, > so even if we have 100 forks of the test-suite, we won't have 100 x > 1GB of used space.GitHub explicitly confirms that "forking" (remotely cloning) a repo does not copy the data. > But if we move into a "less owners" scenario, we> will penalise them with pull-requests all the time.What workflow are you comparing this to, if a pull request is a penalty?> This is a little more complex. SVN is very conservative on history, > and that saves us from destroying the origin. Git, on the other hand, > allows anyone with write access to completely wipe out the repo.This depends very much on repo configuration. For git itself, write access is roughly equivalent to svn administrator access. However, all public-writable repos have an authorization layer that prevents history from ever being wiped. Take a look at gitolite, that's the standard tool for managing such a layer.> If anyone with more git experience than me can come up with a safe way > to have 100s of committers pushing to master, I'd be happy to know.Nobody is allowing 100s of committers to push to master, that would be silly. You push to either a remote clone (GitHub) or a remote branch (GitLab), and the master's owner does the merge. These are essentially an alternative to sending patches by mail, with the added bonus that the Git* websites give you a forum website where you can open threads on individual lines of code, including an email gateway. Regards, Jo