On Wed, 2017-05-17 at 13:54 +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet <swil...@gnome.org> > wrote: > > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: > > > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > > > > > > <snip> > > > > Most developers are more familiar with the GitHub workflow, I > > > > think > > > > it's > > > > an easier workflow than attaching a patch to a bugtracker > > > > ticket. > > > > Once > > > > the contributor has pushed a branch on the fork repo, all the > > > > rest > > > > can > > > > be done from the web interface by clicking on some buttons. > > > > > > I absolutely hate this workflow, fwiw. I prefer being able to run > > > "git- > > > bz" to both create and apply patches, rather than keeping a clone > > > with > > > a bunch of patches in my own org, or remembering the commands to > > > push a > > > repo to my own repo from the upstream clone. > > > > > > I hope there will be a git-bz equivalent available. > > > > By attaching a patch to a bugtracker ticket, we loose the > > information of > > the parent commit: where the commit has been initially created in > > the > > git history. > > > > I've already had the problem that git-bz apply fails (there was a > > conflict), while git was able to resolve automatically the conflict > > when > > rebasing the branch. > > Right. Patches are not a perfect workflow either. It's just nice and > simple. > > Another problem of patches is that the email in it is not validated > (it's just a text file). I don't think this has ever been a problem > for us, but still theoretically: will gitlab validate contributor's > email and make sure the email in the commit are the same as the one > they validated in their profile? I assume it will do this, just > checking. Because it would be good for minimal author check.
That'd be broken. I wouldn't want to use the same email for the bug/issue tracker and the code I commit. It also wouldn't work for folks who want to use personal/work mail depending on the area of contribution, or file pull requests with non-GNOME contributors. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
