[Telepathy] Telepathy 1.0 and moving to Github

[George Barrett]

On Tue, Nov 01, 2016 at 12:03:44AM +0500, Alexandr Akulich wrote:
> I can not agree. You can fit a trivial change into an individual patch, but
> it would be more clear and easier to review a branch with an implementation
> of a new feature, rather than a single patch for that.
> It is better when you *can* propose a commits series, than when you're
> limited by a patch. (I would like to say "hello" to reviewboard here).

Well, no-one said anything about a /single/ patch either. As I'm sure you
know, Bugzilla has no issue with attaching a set of patches to a bug. Feature
branches that are justifiably more than a handful of patches are quite the
edge case, but git has support for this baked-in with git-bz anyway.

> There is no problem to rebase your own branch and clear it before merging.

Well, except for it being a pain. Requiring a branch-in-review to be based on
the upstream tip before merge sounds like it just adds an extra round-trip
between reviewer and contributor.

> We didn't said any word about pull request.

I'm afraid I don't understand how GitHub's issues system is applicable to code
contributions, then.

> Oh, indeed? Let's start with any random feature. Can BZ expand a diff to
> show you a ten more lines of code before the change?

No, but that's hardly "any random feature". I'm not trying to say that BZ's
features are a superset of GitHub's, because that just isn't true. Nor is it
the case that GitHub's features are a superset of BZ's.

> >  * There's no big "MERGE NOW" button to be tempted by mid-review (I'm
> >    guilty of this)
>
> It is not a problem of github. You should be able to resist from clicking
> on buttons. :)

Perhaps, but I don't think code review UI should be steering a reviewer into
accepting code. You're probably right, though, the more I think about it the
more it seems like a non-issue; the Telepathy committers aren't me ;)

> >  * Poor commit messages are understood as valid grounds to reject a
> >    patch
>
> It is equally a valid point to reject a commit.
>
> > * editing a patch is easier than rewriting branch history
>
> No. Rewriting a branch is easier, if you use a proper tool (git rebase
> --interactive; git add --patch at the very least).

I meant that in the context of rewriting commit messages: You can change the
commit message without leaving the browser, you just edit the text. I think
people would be much less frustrated over commit message nitpicking if
rebase-then-push weren't involved; even more so since such nitpicking is part
of established convention on BZs.

Something else you lose with branches over patches is patch history. I seem to
recall hunk comments being clobbered by force pushes.

> >  * There's no argument over git merge vs git rebase, over a commit log
> >    full of merge commits or rewriting history
>
> In Telepathy we have a very reasonable merge/rebase convension for years.

Allow me to reword: There's no reason for someone to uselessly open a bug
linking a blogger's opinion on merge vs rebase ;)

> You're actually comparing a really bad github workflow vs an ideal BZ
> workflow.

My aim was more to compare the sort of workflow each tool seems to promote,
but it's true that I've never been exposed to discussion over the ideal GitHub
workflow. But it remains the case that I'm much more likely to submit code to
a BZ than to open a pull request on GitHub; I'm sure I'm not alone, but I
guess the question is whether I'm in the minority ;)