#**Gerrit vs GitHub** Since there's been an discussion about why we don't use GitHub instead of Gerrit on Twitter, i think it could be a good idea to start off with a collobartive collection of pros and cons of GitHub and Gerrit. Origin: \url{https://twitter.com/christianjul/status/269016828666318848} Please be so kind a make a short summary why a problem of accepting contributions is a matter of changing the toolset. How could the Problems be solved with the current tools and where do those tool exclude people. Are there any other alternatives then going the GITHUB way. Can someone remember why we do not use Sourceforge for this? :-) Isnt that a problem of culture instead? **Feel free to contribute!!!** Why do we have to pick one tool? - What is the purpose / subject discussed here? Extension repositories or the TYPO3 Core? (~tolleiv) * I guess the main discussion is about the Core Repositories * -looking at the pro and con sites it doesn't seem to be about the Core (e.g. when peopel compare costs) * I believe it is, though. The Core consists of a few smaller parts - Extbase and Fluid for example. There's good reason to keep splitting like this and there, Github becomes ideal. * This is already the case for Flow and Neos * so what's the point here? * That we will have a lot of smaller packages and that Gerrit doesn't do well with this sort of layout (i.e. one big list, only filters) * so this should be part of the header - statement - that this is not about the TYPO3 Core but about the "Core packages" --- btw. we're running out of indentations ;) hehe * I argue that if it is about the core packages, it is also about the core itself. At least, the two should not be separated imo * feel free to change the title as you like :) * added an explaination to the "voting" part ;) pic unrelated: \url{http://narf-archive.com/pix/6edc8ccb3ad4df2148a10afd830da9302e9ea3c8.png} ;) TYPO3: Inspiring people to share Let's try to make that happen, shall we? Totally support that, I am just not sure if Gerrit is the main factor here... ##What about "it should not matter where the code is"? Wouldn't that be cool? Imagine… * The "official" stuff stays on Gerrit, with forced reviews and all that, Jenkins, Travis CI, … * Extension Z is on github, pull requests FTW, Travis CI does the testing * Package X is on bitbucket, fork and pull here as well * Remmeber: Composer pulls code from wherever it is * Our own "packagist" / TER hides the various sources under a common "directory frontend" to search for packages ~kdambekalnsWhat a clutter! Please don't ever do that! * Why? As long as there is *one* place to find and download "extensions" I don't care about where they are developed. Such a solution would be better than what we currently have - extensions in our git or elsewhere and no way to import them via the EM because that only supports the TER but a lot of developers do no upload T3X packages anymore… So we have that situation already, although not "officially" ~kdambekalns * +2 For that, you are not a dreamer ;) But I think the discussion started about the contributions and there Gerrit of course has a role * True. What I'm saying is, we should not force everyone into the same solution (and be responsible for the infrastructure needed - see the requests for git hosting for extensions…). Of course we must say how the CMS core and core Neos/Flow packages are developed, how system extensions are developed (for that I really think we should stay with gerrit). But everyone should be free to choose, without suffering through that - and without anyone having to suffer (again, users having to use tools outside the EM!) ~kdambekalns ##Gerrit ###Pro * safe and strict review workflow * data is in our hands * free and opensource * Already integrated with typo3.org accounts \& redmine + others * Hosted by T3A under control of the server team * Integrated into forge (soon with owner/member seperation) * same is possible on github though * they have T3o SSO? ;) * No, but you will have user identity recognition and linking to Redmine * Besides, there's trackers on Github that would also make sense to use at least for ext projects * I am fine with extension projects on github * *irony* Yes, let us have plenty more trackers for the 5000 different extensions! */irony* We are just closing bugs.typo3.org to *reduce *the number of issue trackers we have. Now please don't begin adding new ones. * And if the EM had a tracker link for every extension? ~kdambekalns * used by many big projects, e.g. eclipse, android, Qt-project, mediawiki, openstack, * Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git. \url{http://code.google.com/p/gerrit/} * Well, it is just like Github. There you merge pull requests nearly the same way ~dmitry. * it is controlable by SSH (e.g. command line for release Scripts) * reports can be generated via command-line interface * it has IDE voting integration * we can follow the same bug in different branches (also true for github) * it's made for "Code Review" and it does that job good IMHO ~StGebert ###Con * Unresolvable conflicts may occur - with no option to rewrite history * how can that happen? base a change on another change that gets abandoned * so just rebase them (tech details irrelevant, but rebase was impossible) * tell me the irrelevant details and i could even believe you ~kdambekalns * 1: create commit A * 2: base commit B on A but don't rebase * well, if B depends on A, then this is the right way. if not, don't do it. ~kdambekalns * Basing commit B on A mostly will be a mistake. This is my point though - the dependency problem, having to rebase every * single path in the history rebase the patch or work with local branches and everything will be fine. * see below argument about impracticality of local branches in relation to Gerrit * works for me * merging patches does not become easier, but in fact becomes harder * Gerrit starting from ~2.3 has a rebase button that everyone can hit. No need for manual rebase ~StGebert * 3: create patch set 2 for A * 4: abandon A * 5: attempt to merge B * gerrit will tell you to rebase. just do it. why should that not work? ~kdambekalns * I am not saying this isn't just because I couldn't figure it out - but Gerrit was zero help and the problem stems from the changes already being committed before review. * might happen with GitHub as well * complicated for Beginners - yes * Github is not much simpler IMO, although more people know it * from my experience it is much easier for beginners. I could get into Github workflow much faster than to Gerrit's in approximately the same time ~dmitry * if he knows git there are only 2-3 steps more - therefore how can you assume, that the code is well thought enough to be merged into core, if the coder is not able to configure his working environment correctly - with just 3 steps more * So Github is even *more *complicated * what is complicated about Gerrit? I agree that understanding Git and the basic setup might seem daunting, but Gerrit itself is as easy as it gets!? * diff-views seem cluttered and unclear * works for me (as soon as you are logged in you can configure that) * diff-views are much easier and flexible IMO * matter of taste I think * uhm? depends - it's fine for me * Huge, single-list style interface * I doubt that a list of 100(0) pull requests will end up in a nicer list * Requires continous maintenance from server team * done with opscode chef (still requires work and monitoring) * <- maybe Stucki or SteffenG could comment that - it's their pain / maybe they like it ;) * I like it. Spent 100hours for a gerrit cookbook recently ~StGebert * Has a long workflow duration * same for github ... the workflow duration has nothing to do with the tool (but there is a difference still, in that you have an own forked remote repository with better branch control w/o using a special client) * you can use the same local repo to push to gerrit and github I know, the disadvantage was that it is local, not remote. Many people like remote repos - I'm one such person as I have many, many dev envs * Exactly, Gerrit makes reviewing easier (if you think github does, well.. feel free to think so), but it nevertheless won't add more review power esp. for core projects * Still requires Github for travis (only for travis, check sry) * If most extension devs already use Github but never Gerrit, you require a completely new world of concepts * many TYPO3 agencies use Gerrit on their own, making many extension devs known to Gerrit already * But TYPO3 is not just for TYPO3 agencies and Github is still more widely known * Every contributor starts as a casual contributor, Gerrit discourages this(Why? Can you be more specific?) * I admit: making a tiny tweak in e.g. documentation is super easy with github, it can be done completely in the browser (click edit, edit, save and it'll fork and put in the PR creation form). anything more involved: gerrit wins ~kdambekalns * I don't think so. In contrast to e.g. the Core List, Gerrit allows people to directly submit patches and has a way nicer interface. ;-) * You should try to ask some of the potential contributors, for example through a poll. Which would they prefer - not already knowing and being used to all the intricate workings of Gerrit? Which would you prefer to learn from scratch - using GitHub or using Gerrit? I am of course assuming here, that we're at all interested in what potential contributors have to say. * They will tell you Github, because it looks 2.0 and thus easier. I only work with gerrit and never used github pull requests and I don't intend to switch :-) ~foertel * Requires a lot of additional Git config * commit hook <<-- this is on purpose and is a pro - commit hook should be installed on every git think for basic checks - so called Quality!(I am with you) +1 * pushInsteadOf * push to branch * Configured author (the always needs to be done, but github will ask and apply - well ok, maybe the git commandline can too, don't know) * SSH key that's added in Gerrit (yes, github too, but this is auto there) * all in all it only needs the commit hook (compared to github). everything else is just configuration to make it easier to use over an over again ~kdambekalns * \url{http://www.mediawiki.org/wiki/Git/Gerrit\_evaluation#The\_case\_against\_Gerrit} (especially the first section, notably argument related to the impracticality of using local branches with multiple commits) * Gerrit does not have an official API. Existing tools work by reverse-engineering Gerrit's internal APIs, which are largely undocumented. * Who says this? That's wrong. Gerrit has an ssh api since ages and a modern REST api since 2.5 ~StGebert ##GitHub ## ###Pro ### * well-known fork and pull-request workflow * I am not sure that the people that complain about the complexity of our setup and that you want attract with the change know github really. I guess many don't code that much and have only seen the name, so that wouldn't make it easier for them. * I think pull-requests look nice if you look at one of them. As mentioned above, fun will stop as soon as you have a hundred pull requests with three changes and six comments each ~foertel * good overview over pull-requests, especially diff-views - the quality of the diff-views is IMHO a question of taste, I like gerrits more, so that's not really an argument. * might create more contributions * might or might not, might be done in gerrit as well. ;-) please specify ~foertel * hosted service equals no drain on server team * any user can have a remote repo under their own control (should read: integrated "fork" - is nice for noobs I like forks. Kind regards, Noob (2 commands on top of a Github repo isn't that hard) (invalid argument, you can do that independent on the way the master is managed!) An argument that *could* be valid here is that many forks can lead to problems if someone searches for something (aka the real thing) forks are clearly marked with origin, always * not really a github pro: a fork is just a push to some other remote. you can "fork" any git repo to any git server, also git.typo3.org stuff to github ~kdambekalns * already in use because of travis * don't know of i would call that "in use" :) ~kdambekalns * every contributor starts as a casual contributor, Github promotes this * extremely widely used - almost defacto standard - That is a non argument, just because something is widely in use doesn't mean anything about it. It does mean that more people know it. Sure but it can still be total crap (not saying that Github is). Absolutely, but imo Github has proven itself. I for example dislike it, it is for me not so intuitive as it seems to be for everyone else (maybe I am too stupid). * free as a service * for now ~foertel * it has already paid services. it does not seem likely to become fully paid ~dmitry * gerrit is free to use also. server resources are sponsored (and don't cost much), so not really a point. ~foertel * Github is social. Gerrit is most definitely not. (We are talking about code reviews here, right? Not about a social network) - about contribution motivation, and code review. * github is social because…? and gerrit is not because…? ~kdambekalns * Github can bring TYPO3 out of the closed inner circle --- objection (+1), this is just plain assumption, instead of just contributing, people love to endlessily discuss why they cannot contribute ;) and to disregard that is wise? Please. If everybody whines why they can't contribute then that really, really should tell you something about the contribution process. Or you can of course assume people are just idiots. People who want to contribute get help (even if they are as stupid with git as I am); others just keep complaining no matter what is available. There will be always more people complaining than working. So people who complain are just wrong and should be disregarded. Not a healthy attitude. No, but there are most probably a lot more people that are happy with it, and why should you change things for them? ~kdambekalns * If you want to contribute you **can **do so. But sadly it is a fact that some people also love to "produce themselves"; changing a technical detail (like changing to another platform) would not truely change this * Has official API and many, many app integrations * gerrit also has an official API, over SSH and (in 2.5) also REST ~kdambekalns, ACK ~StGebert * Repository, docs and issues are all in one place ~dmitry * More intuitive than Redmine+Gerrit+MediaWiki, which are three totally separate products, located in three different places ~dmitry * Easy to create new remote branches and work with them for your own fixes or enhancements or projects ~dmitry### ###Con ### * not as strict as Gerrit (no option to define review workflow/rules) * No local hosting (edit: removed this option since Enterprise terms disallow public repos) * **underlinehosting is not under our controlunderline** (is this even required?) - Oh yes, history teached its lesson * history told us not to leave our stuff in one external service only ... git should cut this problem anyway ~foertel * how do we expose our user accounts and group permissions to github? * (edit: removed argument about Github Enterprise - terms disallow public repos on licensed enterprise installs) * a switch would cost money in form of time spent on migration * one-time cost compared to running maintaining your own service ~foertel * you can circumvent the pull-request and push directly to master, eg: no way to **enforce **reviewing * This is only true for collaborators and owners * This is also possible directly to git.typo3.org afaik * only if allowed or admins so the same as Github (no since most people aren't admins, but more people would be collaborators AFAIK) * for community extensions there will be the possibility to push directly (as team member) * you can change pull-request after they have been merged * Not as far as I am aware; but you can change them up until the point when they are merged. * We had some stuff on Github before Gerrit - and nobody really used it * I for one never once saw this advertised - but I did see heavy advertisement for Gerrit. This does make a difference! * all the existing integration would have to be rewritten and might not be possible the way they are today * ouch, really? No undo possible? Better hope we made the right choice then! ;) * please specify ~foertel * you have to make a fork in order to push a pull request (please confirm/disprove this!) * true AFAIK ~kdambekalns * yes, true ~dmitry * pull requests are cumulative - if you need to revise, another commit is made, and another, and… for review fixes the "patch set" approach is way nicer IMHO ~kdambekalns * \url{http://www.mediawiki.org/wiki/Git/Gerrit\_evaluation#The\_case\_against\_Github} * LEGAL RISKS! DMCA Takedown Notes * why can't this happen to us now? ~foertel * because it's "our" server * Who is taking care of responsabiltity for Infracture? * don't get the question. server team? ~foertel * => if the server is not available ;) * How to create a new version of a pull request and compare it against the previous one? Locally via git only I guess. ##What would be your choice? (As a basic measurement of who is for what in general) general => for Core + Core package (extbase / fluid / ...) management bottom line: * be prepared to take the heat *any* change will result in * be prepared to spend a lot of time running things in parallel * no solution is the silver bullet ###**Gerrit:** * Christian Müller @daskitsunet -> I am a big fan of Gerrit for my part, this pull request stuff feels for me always as something for small projects (eg. 1 person "core") * Philipp Gampe @pgampe -> IMHO github is more for smaller projects with looser rules * Tolleiv Nietsch @tolleiv - great tool - doesn't make sense in every case - perfect fit for the TYPO3 Core * Steffen Ritter @sritterkh - Quality Gate which is completely under our control, not for extensions but CoreProjects!! * Thomas Maroschik @tom\_noise - Redmine and Gerrit are two tools that are joined at GitHub in a single view. Discussion and review occur in a single thread like in former mailing list days. Maybe there is something like that for redmine. (Your statement reads as if you are more on the pro GitHub side?) * Aske Ertmann @notontwitter * Karsten Dambekalns @kdambekalns * Christian Kuhn @lolli42 - Very good workflow and perfect tool, esp. for core * Sebastian Kurfürst @skurfuerst -- great quality assurance tool for core, which we can customize to our needs and which helps to maintain our high qaulity standard * Felix Oertel @foertel - ugly as hell and not themable. besides that very good workflow and offers anything you need. used it in freelancing projects and will use it in the agency as well ... * Mattias Nilsson @MattiasDev - Great tool for keeping up the quality because of the possibility to review, test and comment on really complex solutions. Also a very good overview for handling multiple projects. * Steffen Gebert - Gerrit is made for Code Review and it does that job well. * Georg Ringer @georg\_ringer: code review is needed and not possible with github * Oliver Hader @ohader: Since we need properr reviews I'm for Gerrit for the Core. Besides that we have some private repositories and an automated workflow for security changes in Gerrit. Besides that, every extension can use Gerrit or GitHub, no obligations there... ###**GitHub:** * Marc Neuhaus @apocalip * Claus Due @NamelessCoder, because the benefits hugely outweigh the potential contribution diminishment and getting causual contribs involved
{}