Hello George, On Mon, Oct 31, 2016 at 11:18 PM, George Barrett <b...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/telepathy >
_______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/telepathy
