Quoting Otto Kekäläinen (2024-08-01 07:30:18) > > > I have drafted a new DEP at > > > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > > > Enable true open collaboration on all Debian packages". > > > > > > Direct link to raw text: > > > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > .. > > Sorry, but I disagree that the only true collaboration is Salsa-rich > > collaboration. Where are my options to mirror the data at Salsa, as I > > can do with mailinglists and Debbugs, to work with it also offline? > > First of all, thanks for maintaining 650+ packages in Debian.
Ideally those are all team-maintained. Please get in touch if you (yes you reading this text) want to help with any of them. Here is the list: https://qa.debian.org/developer.php?email=dr%40jones.dk > You have for sure developed an optimal workflow for yourself. Then I have failed: I have strived towards a collaborative workflow. Just not a web-centered collaborative workflow, but an email- and chat- based one. > I also do a lot of email based stuff myself and often work offline. > Note that GitLab does allow responding by email to notifications and > to carry reviews by email. Depending on configuration, one could even > submit patches by email[1]. There are also command-line tools that > allow various actions without having to use the browser [2,3]. Non-web access to Gitlab is secondary. Unless you access via web, you see only fragments. > I do however understand that people who already have an optimal > workflow are probably not keen to change it unless the new workflow is > vastly superior, and GitLab/Salsa isn't always perfect in all regards. I do not agree with framing my criticism of Gitlab as me requiring it to be "vastly superior" to consider it. In fact, I find that framing offensive: I say that I want A and don't need B, you reframe that as I require B to be A+B which makes it look like my demand is unreasonable. To me, it is not a matter of inferior or superior, but instead different core designs: web-centric versus decentral and offline-first. Oh, and a side note: The concept of "offline-first" is most often used about offline-first *web* designs, which does not mean that they are "vastly superior" to e.g. mailinglists. And the concept of "decentral" is also used for blockchain-based designs. Complexity and bloat is both superior and inferior, depending on qualities viewed and who gets to pay the costs: Web-based systems have some costs at the server side which are "hidden" by the user (except indirectly through e.g. slow response times as we experience at the moment with Gitlab), and some costs offloaded to the client commonly through JavaScript (Gitlab is somewhat heavy here, but not the worst: I notice how the fan often kicks in when my friends open Facebook on their somewhat-aged laptop). This talk about systems being light or heavy (which eventually affects our environment) is sidestepping my core argument, however: Yes, I do prefer lightweight systems, but my main point in this discussion is only the ability for each maintainer to *choose* their poison. Because collaboration is still very much possible without mono-culture. Imagine that I argued that I prefer Emacs-ish keybindings, and you then rephrase that as I want collaboration to follow the GNU principles, so all tools must be GNU-compatible. That was not my point, my point was that each of us has a favorite set of keybindings and we need not all agree on a single set of keybindings - unless we choose to use systems that include user interfaces (like web-based ones). I want to be able to use emacs. But only as an example. I want each of my team members to be able to continue their personal optimized working style. Some of us use notmuch-related email, others use Evolution or Gmail. > I do however believe that in the grand scheme of things promoting the > five key principles outlined in DEP-18 would benefit Debian as a > whole. It benefits Debian as a whole to switch to Emacs. But is that the Debian we want? What I want for Debian, and what I assume is also what you want, is a more collaborative Debian. I don't say that collaboration requires a system vastly superior to Gitlab. I say that collaboration through Gitlab alienates workflows which I find problematic to discourage. I find it problematic to discourage workflows done by old farts. This is not a joke: Some in Debian have used Emacs so much in their life that it is truly difficult for them to switch, and (not mandating, yet, only) favoring another UI means that these folks are less efficient. Now, this is not an emacs-versus-vim debate (and I use neither of those myself), but the comparison seems apt, because Debian works fine with each of us using whatever UI we prefer, but moving to a web-centric UI we need to agree on a universal UI. Essentially I don't like the Gitlab UI. Maybe the majority of Debian are ok with the UI of Gitlab, but if it is sane for UI choice to be decided democratically, then why not have a vote on editor choice as well? and while at it, let's vote on KDE vs. GNOME (and not even waste time on snowflakes like Sway or Xfce). That would be a different community than the Debian I like to collaborate within. ...and I *do* mean "collaborate", not "cooperate". I do want collaboration, even if my too many packages can be seen as a "smell" that personally I have failed at collaborating. Yes, collaboration is likely ensured with a platform like Gitlab, but no, mono-cultural collaboration is not the only form of collaboration, and I find it a problematic one. > Also, I can see that you are already following principles 1 and 2 of > the proposal by having almost all of your packages in git and on > salsa.debian.org. As the DEP-18 draft text says, strict enforcement is > not a wise tactic in the context of fostering collaboration, and I > would not expect you to move away from what you are doing now, as it > works for you and benefits Debian with 650+ packages. In your case > following the principles 3, 4 and 5 would probably not be appropriate > in cost vs benefit. For example running Salsa CI or asking for code > reviews prior to upload would probably just slow things down too much > without the gain in your case. If you mean to say that my current contributions to Debian comply with DEP-18, then I am surprised, and I think the text need a heavy rewrite. In its current form, I would expect the next revision of codesmells to have me smelling badly of non-collaborative. You may find my ways of contributing to Debian perfectly fine, but I have a hard time not seeing this draft formalisation of what constitutes good collaborative manners in Debian as a strong tool for pressuring those collaborating differently into "getting in line" - conforming. Conforming on choice of editor is, I think, a repulsive thought to most if not all of us in Debian, but e.g. from a sustainability PoV I find it quite harmless compared to conforming on collaboration as web-based, as opposed to decentral and offline-first. > However, I would still argue that DEP-18 would be useful as a general > guideline in Debian and in particular for team maintained packages and > important packages (as discussed in the "end single maintainership > thread"). Having such principles published would help maintainers (at > least new maintainers) to align on a set of basic principles that help > drive more collaborative development. I agree that DEP-18 represent "principles that help drive more collaborative development", but I disagree that they are "basic", since 3 of 5 principles are strongly tied to a specific UI. Yes, that UI allows multiple workflows, and DEP-18 sensibly steers clear of promoting a specific workflow. But implicitly the text discrouages e.g. decentral and offline-first workflows that I find important. Thanks a lot for all the time you put into this. Despite my strong opinion, I do see the value of pushing this agenda, and of exploring the boundaries of the forge we have currently invested in using. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
