[Telepathy] Telepathy 1.0 and moving to Github

[Gergely Polonkai]

On Mon, Oct 31, 2016, 21:13 George Barrett <bob at bob131.so> wrote:

> 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.
>

Not really, especially if you are the sole owner of a feature branch.
GitHub handles it very well, too. And if the workflow (ie. the CONTRIBUTING
file) clearly states you must rebase, then core devs can instantly reject a
patch that hasn’t been rebased.

>
> > 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 ;)
>

Then let’s set up code review rules. You can’t press the Big Tempting
Button of Merge until at least two people (and perhaps the CI) said it’s
OK. It can be done in GitHub for a few months now.

>
> > >  * 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.
>

I can’t argue with that, it must become a part of the individual
developers’ work. I personally have a pretty good workflow for this, but I
must admit it can be tedious sometimes.

>
> > >  * 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 ;)
>

I think we all should forget about ideal BZ/GH/whatever workflows, and
concentrate on what the ideal Tp workflow is. I just went through a year of
discussions on the same topic (with different systems) that could have been
skipped if the devs would have told what they really wanted.

Again, I’m sorry for getting into this argument without a name in the
community. But I have seen where such transitions and arguments can go, and
it can do pretty big damage to any product, and I aim to use Tp 1.0 in the
future :)

Best,
Gergely

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/telepathy/attachments/20161101/1779ad70/attachment-0001.html>