3 ms·

> If it’s Github, it’s going to look like this: > Go to the website for the thing, click fork > Now clone that fork or add it to my .git/config, hack, a

> If it’s Github, it’s going to look like this: > Go to the website for the thing, click fork > Now clone that fork or add it to my .git/config, hack, and commit > Push the commit, go back to the website, and submit a PR > Github’s email integration is so poor that I basically have to go back to the website for most parts of the conversation. I can do little from the comfort of mu4e. > Remember to clean up my fork after the patch is accepted or rejected. > Compare that to how I’d contribute with Debian: > Hack (and commit if I feel like it) > Type “reportbug foo”, attach my patch > Followup conversation happens directly in email where it’s convenient to reply I've actually seen this type of thing quite often in criticisms of GH/web-based workflows, etc. And frankly, they're all complete madness. The leaps of logic made in the above bullets are so enormous they can't not be wilful. The author is really stretching. 1. The equivalents of "going to the website", forking, adding to local git config, are all skipped for the Debian workflow; it is assumed one has already set the project up locally. For a new project, these steps are 100% guaranteed to be more complex for Debian (or any project not on a website with fork-like features). 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? 3. Pointing out that you should clean up branches in your fork is superfluous. 4. The second step in the Debian workflow leaves out two things: you haven't included the setup of the reportbug cli, and—since we're clearly more comfortable with a cli than with a browser—ignores the fact that there are equivalents for interacting with the GH API without ever going near a browser.

irishsultan 8y ago
> 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? That feels like an unfair remark, creating a pull request is only the first step in either workflow, having good email integration is still important for every other step
tracker1 8y ago
Beyond all of that, if it's a trivial change, click edit on the upstream repository, edit the file, save+Pr and you're done... the fork is all inline. I submit docs changes all the time right in the github web ui. Cleanup for forks isn't always great, I can admit that, but you can create an org for temporary stuff, and just nuke everything there on occassion and put your forks there for temps.
IronBacon 8y ago
> 1. The equivalents of "going to the website", forking, adding to local git config, are all skipped for the Debian workflow; it is assumed one has already set the project up locally. For a new project, these steps are 100% guaranteed to be more complex for Debian (or any project not on a website with fork-like features). Naah, you only need to know the URL of the Debian package's .dsc file that you want to patch, and pass it to the dget command, it will download the application tarball, the Debian patches and the dsc file. You can find the dsc URLs on the Debian packages tracker site: tracker.debian.org
- lucideer 8y ago
  How do I get to the Debian packages tracker site? Do I need to open a browser? On a more serious note: you open with "Naah", but then you do go on to describe steps that the author neglected to include in the bullet points. My only point was: the author goes out of their way to make the comparison imbalanced.
  - IronBacon 8y ago
    I was objecting the "Debian workflow is more complex than a forking" part. In reality it's even simpler than what I described (if you don't remove the deb-src lines from your apt source config like I do). If you want to modify a Debian package you only need to use "source" instead of "install" for the package you need, for example "apt source curl" will download the tarball, diff and dsc file for the curl package in the working directory, no browser involved. ^__^; I use the tracker site when I need to build some packages from unstable or experimental, usually recent libraries that I couldn't find on backports.debian.org.

irishsultan 8y ago

> 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? That feels like an unfair remark, creating a pull request is only the first step in either workflow, having good email integration is still important for every other step

tracker1 8y ago

Beyond all of that, if it's a trivial change, click edit on the upstream repository, edit the file, save+Pr and you're done... the fork is all inline. I submit docs changes all the time right in the github web ui. Cleanup for forks isn't always great, I can admit that, but you can create an org for temporary stuff, and just nuke everything there on occassion and put your forks there for temps.

IronBacon 8y ago

> 1. The equivalents of "going to the website", forking, adding to local git config, are all skipped for the Debian workflow; it is assumed one has already set the project up locally. For a new project, these steps are 100% guaranteed to be more complex for Debian (or any project not on a website with fork-like features). Naah, you only need to know the URL of the Debian package's .dsc file that you want to patch, and pass it to the dget command, it will download the application tarball, the Debian patches and the dsc file. You can find the dsc URLs on the Debian packages tracker site: tracker.debian.org

lucideer 8y ago
How do I get to the Debian packages tracker site? Do I need to open a browser? On a more serious note: you open with "Naah", but then you do go on to describe steps that the author neglected to include in the bullet points. My only point was: the author goes out of their way to make the comparison imbalanced.
- IronBacon 8y ago
  I was objecting the "Debian workflow is more complex than a forking" part. In reality it's even simpler than what I described (if you don't remove the deb-src lines from your apt source config like I do). If you want to modify a Debian package you only need to use "source" instead of "install" for the package you need, for example "apt source curl" will download the tarball, diff and dsc file for the curl package in the working directory, no browser involved. ^__^; I use the tracker site when I need to build some packages from unstable or experimental, usually recent libraries that I couldn't find on backports.debian.org.