On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@gmail.com wrote:
Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too.
GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways: * poor repository management (fun fact: GitHub does not even log force pushes, much less provides any ability to undo them) * noisy commit histories due to poor support of amend-based workflows, and also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that) * no way to mark patches which depend on each other * diff view works poorly for large patches * CR interface works poorly for large patches (no way to write draft comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity) * hard to keep track of cherry-picks
This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis).
That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means "amending patches" becomes "pushing another commit onto a branch." We've run into issues w/ rebasing & amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit.
On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@gmail.com wrote:
Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too.
GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways:
- poor repository management (fun fact: GitHub does not even log force
pushes, much less provides any ability to undo them)
- noisy commit histories due to poor support of amend-based workflows, and
also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that)
- no way to mark patches which depend on each other
- diff view works poorly for large patches
- CR interface works poorly for large patches (no way to write draft
comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity)
- hard to keep track of cherry-picks
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi Brian,
The arguments for/against GitHub etc. were discussed at length across all of our engineering staff & community, exactly 3 years ago, which reached consensus: https://www.mediawiki.org/wiki/Git/Gerrit_evaluation#GitHub
In my opinion, this is not something that should be addressed on a per-team basis (and especially not by making the decision first internally in the team and then announcing it to the wider audience as a done deal). Individual and team-wide preferences should be considered as input to the wider discussion but ultimately people should yield to the collective decision. A per-team decision for critical tooling like the one you just announced would be inappropriate in a corporate setting, and is even more so in a community-facing organization.
All this applies to both our Git tooling as well as CI, for which is worth noting that there are people in the foundation working on it full time. It's not very different than our issue tracking tooling either, for which we already know the huge pains that we've suffered in the past by having it fragmented across multiple different tools that each individual team picked.
We can always revisit past decisions and reopen past discussions (to some extent, it's a sign of health) but your way is not the way to do this, IMHO.
Best, Faidon
On Wed, Jul 22, 2015 at 05:43:07PM -0400, Brian Gerstle wrote:
This isn't really about Gerrit vs. GitHub. To be clear, we're mainly doing this for CI (i.e. Travis).
That said, we (the iOS team) plan for our workflow to play to GitHub's strengths—which also happen to be our personal preferences. In short, this means "amending patches" becomes "pushing another commit onto a branch." We've run into issues w/ rebasing & amending patches destroying our diff in Gerrit, and problems with multiple people collaborating on the same patch. We think GitHub will not only provide integrations for free CI, but, as an added bonus, also resolve some of the workflow deficiencies that we've personally encountered with Gerrit.
On Wed, Jul 22, 2015 at 5:14 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benapetr@gmail.com wrote:
Good job, you aren't the only one. Huggle team is using it for quite some time. To be honest I still feel that github is far superior to our gerrit installation and don't really understand why we don't use it for other projects too.
GitHub is focused on small projects; for a project with lots of patches and committers it is problematic in many ways:
- poor repository management (fun fact: GitHub does not even log force
pushes, much less provides any ability to undo them)
- noisy commit histories due to poor support of amend-based workflows, and
also because poor message generation of the editing interface (Linus wrote a famous rant https://github.com/torvalds/linux/pull/17#issuecomment-5654674 on that)
- no way to mark patches which depend on each other
- diff view works poorly for large patches
- CR interface works poorly for large patches (no way to write draft
comments so you need to do two passes; discussions can be marked as obsolete by unrelated code changes in their vicinity)
- hard to keep track of cherry-picks
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l