3 ms·

I'm also curious how many newer contributors would see friction in simply "firing up a web browser." edit: I may have read that part of the post uncharitably,

I'm also curious how many newer contributors would see friction in simply "firing up a web browser." edit: I may have read that part of the post uncharitably, if what the author meant was continually switching between the browser and the command line. Still, the sentence stuck out to me.

blihp 8y ago
I suspect that for many of the existing developers, it's deeper than that. A subset of the devs work a significant fraction of their time offline so firing up a web browser isn't going to work for them at all. Also, another subset of the devs would find adding a dependency to github or any other non-free[1] service antithetical to the Debian ethos. Realistically, I don't see them switching away from text based files with at least the option of an offline workflow on the back-end, which makes sense to me. That said, I really do wish they'd understand that to people who don't live and breath the Debian workflow, the existing front-end tooling is painful to use and antiquated and prioritize updating it. It is possible to create a much nicer front-end user experience on top of what currently exists. [1] From the FSF/Debian perspective, no-cost is not free https://en.wikipedia.org/wiki/Gratis_versus_Libre https://en.wikipedia.org/wiki/Gratis_versus_Libre
- Conan_Kudo 8y ago
  This is actually the case in Fedora, too. That's why we created Pagure[1] and HyperKitty[2]. Pagure provides a service similar to GitHub and GitLab, while also supporting mostly offline workflows. Pull request metadata, issues, documentation, and of course the code, are stored as Git repos. You can clone them, do work, and push them back, and Pagure will act on them appropriately. Or you can operate from the web UI if you prefer, and ignore the fact that the data is stored as Git repositories internally. HyperKitty adds web forum-style conversation views and functionality to a mailing list, allowing people who are uncomfortable with handling everything by mail to still follow and respond to threads and be part of the conversation. Both of these show it's possible to support the old guard while making it possible to welcome fresh blood and adapt to their preferences. For better or worse, it's an "adapt or die" situation. Debian isn't adapting, which is not good. As an aside, Debian nearly did deploy Pagure. The community voted for it, and then the DSAs (Debian System Administrators) decided on using GitLab using GitLab Omnibus (not even the GitLab packaged in Debian!) anyway, which upset a fair number of friends I have who are Debian Developers. But all of them said that they were powerless to influence change, which seriously speaks to some kind of broken process here, where the "most powerful" group of people in Debian feel powerless about stuff like this. [1]: https://pagure.io/pagure https://pagure.io/pagure [2]: https://hyperkitty.readthedocs.io/en/latest/ https://hyperkitty.readthedocs.io/en/latest/
JohnFen 8y ago
I find web-based workflows to be high in friction. Not because it's hard to start up a browser, but because nearly all web-based solutions that I've used are clunkier, slower, and more in-my-way than what they're intended to replace. It's also annoying to have to be on the internet just to do development work, but that's a lesser complaint.

blihp 8y ago

I suspect that for many of the existing developers, it's deeper than that. A subset of the devs work a significant fraction of their time offline so firing up a web browser isn't going to work for them at all. Also, another subset of the devs would find adding a dependency to github or any other non-free[1] service antithetical to the Debian ethos. Realistically, I don't see them switching away from text based files with at least the option of an offline workflow on the back-end, which makes sense to me. That said, I really do wish they'd understand that to people who don't live and breath the Debian workflow, the existing front-end tooling is painful to use and antiquated and prioritize updating it. It is possible to create a much nicer front-end user experience on top of what currently exists. [1] From the FSF/Debian perspective, no-cost is not free https://en.wikipedia.org/wiki/Gratis_versus_Libre https://en.wikipedia.org/wiki/Gratis_versus_Libre

Conan_Kudo 8y ago
This is actually the case in Fedora, too. That's why we created Pagure[1] and HyperKitty[2]. Pagure provides a service similar to GitHub and GitLab, while also supporting mostly offline workflows. Pull request metadata, issues, documentation, and of course the code, are stored as Git repos. You can clone them, do work, and push them back, and Pagure will act on them appropriately. Or you can operate from the web UI if you prefer, and ignore the fact that the data is stored as Git repositories internally. HyperKitty adds web forum-style conversation views and functionality to a mailing list, allowing people who are uncomfortable with handling everything by mail to still follow and respond to threads and be part of the conversation. Both of these show it's possible to support the old guard while making it possible to welcome fresh blood and adapt to their preferences. For better or worse, it's an "adapt or die" situation. Debian isn't adapting, which is not good. As an aside, Debian nearly did deploy Pagure. The community voted for it, and then the DSAs (Debian System Administrators) decided on using GitLab using GitLab Omnibus (not even the GitLab packaged in Debian!) anyway, which upset a fair number of friends I have who are Debian Developers. But all of them said that they were powerless to influence change, which seriously speaks to some kind of broken process here, where the "most powerful" group of people in Debian feel powerless about stuff like this. [1]: https://pagure.io/pagure https://pagure.io/pagure [2]: https://hyperkitty.readthedocs.io/en/latest/ https://hyperkitty.readthedocs.io/en/latest/

JohnFen 8y ago

I find web-based workflows to be high in friction. Not because it's hard to start up a browser, but because nearly all web-based solutions that I've used are clunkier, slower, and more in-my-way than what they're intended to replace. It's also annoying to have to be on the internet just to do development work, but that's a lesser complaint.