From this 40, 20 are patches at least one year old and probably require little work with them. I've scanned through activity page since last month an there are aprox. I have strong concerns that Redmine project is losing people attention and willingness to help and I thing switch to git/GH would prevent this. Yes I've read it and I raise this issue as a request to revise it :). I cannot understand benefit of moving Github than our Contributing guide. You could also use GitHub Enterprise in intranet - there is such option, but its costs more. Many centralized companies use own repositories in intranet, not use hosting services. They could be exactly the same as Linus ones, I'm fine with that.
That being said I think that Redmine project when moving to GitHub should also provide its set of rules of contribution. But he also accepts that other people decide to comply with other set of rules for their projects. He also thinks that those standards are objectively better so other people would benefit from adhering to them. Linux and Git projects have certain coding and commit standards, which Linus wants to keep.
I've read discussion in PR and I completly agree with Linus arguments. What do you mean by sample in comment 9 - that you can delete branch with name 'stable'? I don't get it. there will be many poor quality contributions and it would take more time to manage more attention means more 'noise' and more effort with managing/reviewing contributions move to GH forces on every people to change their habbits (changes many times are good things )) only certain group of maintainers have commit rights to direct commit main repo other people work is aproved or rejected with some meaningful comment. with good contribution standards it is clear what conditions should one's PR shold have git in general is easier to work with and more performant than svn as in Jenkins - GitHub PRs could be tied with issues in Issue tracker, and discussion could be managed only on people love attribution for their work - and with GH it is clear and open that someone worked with some part of project - which is awesome ego boost more people invlolved means more interesting ideas/use cases projects on GH gets more attention and generally more usage which provide more feedback/testing move to GH would involve much more people who are willing to help So here are some pros and cons (with my comment) of this move: What I ask is a little discussion about feature of Redmine project and evolution of its rules regarding opensource contributions. They are quite big projects and with developing them with GH works quite well. Great acknowledgement of that are many open source projects on GitHub: I think PRs works quite good with projects in all sizes and technologies. Pull request is not suitable for big well-maintained centralized project. Initialized empty Git repository in /REDMINE-1/git-workdir/chiliproject.git/ $ git clone -bare git:///chiliproject/chiliproject.git Rest API) and there are people wanting to help.Īnd I thing switch to GH would greatly ease way for more people to bring there fixes and again bring 'the hype' to the project ). So I've began this discussion mostly because I'd like to see something simillar with Redmine - there are many places it already should and could be better (ex. Jenkins CI is great example - as soon as project went GH and there was some maintainers group - the amount of features/plugins exploded and currently it is very powerfull tool.Īlso many centralized companies buy 'GitHub Enterprise' just because of this feature - the ability to easy share your fix with people.
GIT SVN CLIENT CODE
There are huge number of opensource projects hosted on GitHub where code is contributed in form of PRs. It could be even more awesome if more people were involved in improving it.Īt current state GitHub is de facto best way to share an opensource project and involve many people, beacause it is so easy to fix one thing and send Pull Request with the fix. What do you mean by "Git branch is not stable"? Please provide some details.
0 kommentar(er)
