[Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hello George,

On Mon, Oct 31, 2016 at 11:18 PM, George Barrett <bob at bob131.so> wrote:

> On Sun, Oct 30, 2016 at 06:59:07PM +0200, George Kiagiadakis wrote:
> > 1) Where should we keep tickets? Right now they are also split between
> > bugzilla and github. No decision has been made yet. Our options seem
> > to be bugzilla, github and phabricator.freedesktop.org.
> >
> > -> github: most user friendly, very limited
> > -> bugzilla: less user friendly, more options, some basic ones are not
> > available though (they require admin access...); currently cluttered
> > with old & dead stuff
> > -> phabricator: even less user friendly (imho), but the most powerful
> > one
>
> My vote would be for keeping that stuff on the FD.O Bugzilla. I would
> argue that Bugzilla has an edge over GitHub in that the BZ workflow
> promotes patch nit-picking and a clean commit history:
>
>  * Individual patches are submitted instead of pull requests for
>    branches.
>
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).
There is no problem to comment any line of code in any commit of a branch.
There is no problem to rebase your own branch and clear it before merging.
We didn't said any word about pull request.


>  * BZ has a great system for patch review
>
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?


>  * Bug discussions and patches share the same thread
>
 * 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. :)

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

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

You're actually comparing a really bad github workflow vs an ideal BZ
workflow.
In fact, you can


> Particularly with a project with as many components as Telepathy, I feel
> like GitHub issues would be a definite step backward.
>
> I'd also recommend BZ over Phabricator, but admittedly this opinion is
> not particularly well informed. My previous impressions of it has been
> that it's in desperate need of a man page, not a good quality in a
> website. I wouldn't be the only one who is more comfortable with BZ.
> That said, I have no idea what additional features it provides; it may
> well be worth it for Killer Feature X.
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/telepathy/attachments/20161101/c231f212/attachment.html>