One of those two is my fork and yes I did it to fix something, but edandersen's point was more geared towards a real fork (i.e. something that takes the project into a different direction) instead of the fork that GitHub requires to send a PR.
I agree with him, we already have a bunch of popular .NET build tools other than MSBuild like FAKE, basing one off of MSBuild doesn't seem to add a lot of value imho.
People committing to gcc probably have workflows that predate github. I think there are many "forks" that are just done as fixes on a local machine then sent directly as a patch.
Sorry, I wasn't talking about forks the github term, I was referring to forking the project. It's useful to have open source available just for maintenance.
sudo apt-get install fsharp
[...]
Need to get 22.2 MB of archives.
After this operation, 66.0 MB of additional disk space will be used.
Personally, I wouldn't call that heavy.
Remember that the 10MB figure for CoreCLR you give is just for the runtime alone, it doesn't include any class libraries. The Mono runtime is in the same ballpark.
There are many edge cases you need to consider, so a seemingly simple language feature can become hard to get right quickly.
I highly recommend reading through https://roslyn.codeplex.com/discussions/570551 and the other four revisions of the nameof() spec, they do a very good job at explaining the tradeoffs of each design.
If you look below the repository title on GitHub, it says "mirrored from..". This means GitHub handles the synchronization (they set this up on request for some projects).
For me the advantage is being able to use GitHub's nice UI to browse the source code.
Have you thought about opening this up for more than just commit messages?
Many projects need to check a number of things on PRs, e.g. enforce coding style, bugfix has a corresponding test, user signed the CLA, owner of %{scope} is notified for review, etc. That would obviously need a way to tie into external/custom tools as everybody validates these things differently.
I think there are several avenues that could be explored with this. I wanted to stay away from explicitly checking the code initially, as there are other tools aimed at that specific task, however there is no reason something like this couldn't be added into GitCop at a later date.
I had the idea of checking that the user exists in a list of users by specifying a JSON list of users. This means that it could be used to check if a CLA has been signed, but there are other applications too. Does this seem like a reasonable way to do it?
I like the idea of ensuring a test has been added, not sure how to tackle it, but it is certainly worth keeping in mind.
I think what I was aiming at is integration with other tools, rather than adding those checks directly into GitCop (as you said, there are already services that check code, validate CLA etc).
Or maybe provide me with a Travis-like sandbox where I can run my checks with whatever linter/validator/custom code I want and report the results back?
Can the bot comment include an example of a good commit message?
Telling users that "Commits must be in the following format: %{type}(%{scope}): %{description}" requires them to mentally parse and figure out what this means. Giving an example along the lines of "perf(backend): optimized db access" would make this easier.
I agree with him, we already have a bunch of popular .NET build tools other than MSBuild like FAKE, basing one off of MSBuild doesn't seem to add a lot of value imho.