MobileRead Forums - View Single Post

John Peterson · 01-05-2013, 03:43 PM

Requesting adequate reply

I request an adequate reply to this post as defined and advocated by the article efficient communication.

Requesting option to discuss patches at GitHub

I argue that

* there's no significant disadvantage or inconvenience with discussing a patch on GitHub compared to Launchpad
* manual monitoring is not necessary because there's a `Watch`option to receive mail notifications
* there's no significant disadvantage or inconvenience in applying a patch from GitHub because
** it can without significant effort be applied with `bzr git-apply` (and retrieved from a .patch suffix to the commit URL)
** if asked the author can upload to launchpad with `git bzr push`
* GitHub is popular and it's therefore within reasonable flexibility to allow discussion there
* Allowing code discussion on GitHub too encourage competition between the sites which is beneficial
* Allowing patch discussion on GitHub might bring more ideas and coding effort to the project because some users prefer to discuss patches there

GitHub advantage

I argue that some users see these differences as a significant disadvantage or inconvenience in discussing a patch on Launchpad compared to GitHub

* GitHub allow message editing to correct errors in spelling, clarity, or logic, and therefore doesn't force the user to accept the dissatisfaction of leaving such errors permanent (and other arguments in the Launchpad discussion about message editing)
* git is more efficient than bzr for patch discussion, primarily when (i) rebasing with commands such as `git commit --amend`, `git reset --soft HEAD^`, `git rebase -i` and (ii) diff editing because TortoiseGit's `TortoiseMerge.exe` allow editing (to easily fix accidental white space or remove temporary logging before commit) which bzr's `tbzrcommand.exe --command=diff` doesn't
* GitHub allow message markup which allow clearer messages
* Launchpad send notification for a change to the user that did the change which is an annoyance

Clarification

Prompted by discussion below I want to clarify that I'm not asking for anything more than

> discussing a patch on GitHub

I'm not asking for f.e.

* applying the patch from Github (with `bzr git-apply`) if there's an objection to that because if asked I can instead upload it to launchpad with `git bzr push`
* mirroring to GitHub
* moving to GitHub

If there's a concern that the patch base is outdated the committer can (instead of applying the patch from GitHub with `bzr git-apply`)

* ask the author to upload the patch to launchpad with `git bzr push`

(If there's an opinion in this thread that I've not replied to it might be because I found it unclear, similar to another argument, or non-meaningful.)

01-05-2013, 03:43 PM	#7
John Peterson Member Posts: 21 Karma: 10 Join Date: Jul 2011 Device: none	Requesting adequate reply I request an adequate reply to this post as defined and advocated by the article efficient communication. Requesting option to discuss patches at GitHub I argue that * there's no significant disadvantage or inconvenience with discussing a patch on GitHub compared to Launchpad * manual monitoring is not necessary because there's a `Watch`option to receive mail notifications * there's no significant disadvantage or inconvenience in applying a patch from GitHub because it can without significant effort be applied with `bzr git-apply` (and retrieved from a .patch suffix to the commit URL) if asked the author can upload to launchpad with `git bzr push` * GitHub is popular and it's therefore within reasonable flexibility to allow discussion there * Allowing code discussion on GitHub too encourage competition between the sites which is beneficial * Allowing patch discussion on GitHub might bring more ideas and coding effort to the project because some users prefer to discuss patches there GitHub advantage I argue that some users see these differences as a significant disadvantage or inconvenience in discussing a patch on Launchpad compared to GitHub * GitHub allow message editing to correct errors in spelling, clarity, or logic, and therefore doesn't force the user to accept the dissatisfaction of leaving such errors permanent (and other arguments in the Launchpad discussion about message editing) * git is more efficient than bzr for patch discussion, primarily when (i) rebasing with commands such as `git commit --amend`, `git reset --soft HEAD^`, `git rebase -i` and (ii) diff editing because TortoiseGit's `TortoiseMerge.exe` allow editing (to easily fix accidental white space or remove temporary logging before commit) which bzr's `tbzrcommand.exe --command=diff` doesn't * GitHub allow message markup which allow clearer messages * Launchpad send notification for a change to the user that did the change which is an annoyance Clarification Prompted by discussion below I want to clarify that I'm not asking for anything more than > discussing a patch on GitHub I'm not asking for f.e. * applying the patch from Github (with `bzr git-apply`) if there's an objection to that because if asked I can instead upload it to launchpad with `git bzr push` * mirroring to GitHub * moving to GitHub If there's a concern that the patch base is outdated the committer can (instead of applying the patch from GitHub with `bzr git-apply`) * ask the author to upload the patch to launchpad with `git bzr push` (If there's an opinion in this thread that I've not replied to it might be because I found it unclear, similar to another argument, or non-meaningful.) Last edited by John Peterson; 02-01-2013 at 04:04 PM.