|
|
Log in / Subscribe / Register

Debian discusses principles for package maintenance

By Joe Brockmeier
August 28, 2024

Achieving consensus among Debian Developers on technical topics and procedures can be, to put it mildly, challenging. Nevertheless, that is exactly what Otto Kekäläinen has tried to do with a proposal that would set up "principles all Debian packages should follow to be open for collaboration in package maintenance". In the near term, it seems unlikely that the proposal will be accepted, but the discussion may be effective at improving collaboration nonetheless.

Ending single-developer maintainership of Debian packages has been a popular topic of discussion this year. Current Debian Project Leader (DPL) Andreas Tille made building redundancy, "whether it's maintaining infrastructure or managing non-leaf packages", part of his platform during the 2024 DPL election. He also spoke about this in his "Bits from the DPL" talk at DebConf 2024 in Busan, South Korea. Video of the talk is available on the DebConf site.

Tille wrote in his platform that he envisioned a future where "every crucial task in Debian" is handled by at least two people to "ensure comprehensive backup and support". He would also like to see adoption of packaging standards, make it mandatory to maintain packages on Debian's GitLab instance, called Salsa, and to use its continuous-integration tools. If voters were attached to single-maintainership of packages, he suggested that they should "probably rank me below 'None of the above'".

Discussion part one

Ending single-person maintainership, and packaging practices in general, were a major topic of discussion on the debian-devel mailing list during the run-up to the election in April. The conversation started on a non-public mailing list, presumably debian-private, but it was moved to debian-devel and then re-titled "finally end single-person maintainership".

In the first message, Pierre-Elliott Bécue is quoted as saying that "this whole situation is a plea to finally end single-person maintainership of packages", and that all packages should be collaboratively or team-maintained. What that situation was remains unclear, but that did not hinder the ensuing discussion. Tille quoted another message from Wouter Verhelst, in which Verhelst expresses skepticism that mandating multiple maintainers is the way to ensure that Debian packages are well-maintained. He says that Debian should not try to fix packaging problems "by introducing a rule that is, at best, affecting something only very weakly related to the problem that we are trying to solve". Tille then asks whether mandating use of Salsa, would be a step in the right direction.

Bernd Zeimetz replied that mandating Salsa was absolutely a sensible step. He upped the ante to say that Debian should also require a common Git layout for packages, and prefer merge requests to sending patches. He also called for packagers to use recent versions of debhelper, presumably a reference to its compatibility levels that reflect changes in Debian policy. Developers can choose which level to target, to avoid breaking changes, but that means that those packages do not comply with more recent versions of Debian policy. In Zeimetz's estimation, adopting those policies would make it easier for contributors to send merge requests to maintainers, or for others to pick up maintenance of a package in the event that its maintainer is unavailable or unresponsive.

Top-down imposition

Philip Hands balked at the idea of requiring Debian developers to adopt specific workflows. He said that top-down imposition of practices struck him as "unlikely to induce joy in anyone involved". After all, Debian's contributors are "a self-selecting group of people who are prone to repeatedly walking the road less traveled". He also pointed out that there is no consensus on which Git layout would be best, despite a proposal that has been in the works for almost a decade.

Raphaël Hertzog first proposed a Debian Enhancement Proposal (DEP) to "harmonize the layout of Git repositories used to maintain Debian packages" in 2014. DEPs are similar to RFCs or Python Enhancement Proposals (PEPs). An enhancement can be any change to a Debian process, such as clarifying policies and workflows for non-maintainer uploads (NMUs), guidelines for tagging patches, or providing machine-readable copyright information. The idea behind DEPs is to help organize discussions, indicate their current status, and provide a record of decisions. According to the initial DEP proposal a DEP is accepted when there is consensus among the "affected parties", those who would do the implementation or have their work affected by it.

Hertzog's proposal, DEP-14, is currently in "candidate" status, which means it is considered to be in the implementation and testing stage, but is not yet accepted as part of any authoritative texts such as Debian's policy manual or developer's reference.

Wookey wrote that he was in favor of changing Debian's culture to make it easier to just fix things, but that mandating use of Salsa or team maintenance would be a mistake:

Because so far as I can tell 'use salsa' actually means 'maintain your packages in git'. So far as I can see it is not possible to use our existing 'uscan, patch, sbuild, dupload' type workflows with Salsa. And that's why I'm not using it, and don't want to be made to use it.

Johannes Schauer Marin Rodrigues said that he had mixed feelings about using Salsa. He described it as a "big beast with tons of javascript" that does not play well with his computer. But, he said, it gave him confidence in what he uploads and he liked that it would run tests for him while he did other work. He also liked that he could receive contributions through Salsa which, unlike Debian's bug-tracking system, would let him know whether a change broke something or not. At the same time, "I've also cursed at it enough times to understand the dislike". He was not comfortable making it mandatory just because he liked it.

The discussion continued for quite a while without making much headway. On May 19, Jonas Smedegaard suggested that the discussion should focus on specific requirements rather than focusing the discussion on "a single catch-all code forge". For example, should Debian mandate VCS-tracking or not, and should it mandate a specific VCS? If yes, should Debian require a specific workflow with that VCS, and so on.

Paul Gevers asked if people thought that "mandate" would mean a "should" or a "must" in policy. He was against the idea of requiring specific policies for packagers, and said the discussion was "going to be moot" if the policy was simply that packagers "should" maintain things a certain way. He noted that 93% of packages in Debian testing were already in Git, and 86% of the packages were maintained on Salsa "so I propose we stop the discussion". (This information can be found on the Debian Trends site.) The discussion did not stop at that point, but it did wind down over the course of the next few days.

DEP-18

On July 27, Kekäläinen started it up again by sending a message to the debian-devel list about a draft titled "DEP-18: Enable true open collaboration on all Debian packages". DEP-18 has five principles that Debian Developers should follow "in order to lower the barrier for others to contribute". The first is that a package's source code should be stored in version control, using Git. The second is that the source code should be on Salsa. The third is that developers should run Salsa CI on the package at least once before every upload to the Debian archive to ensure a minimum level of quality.

The fourth principle is that developers should allow merge requests (or pull requests, in GitHub parlance) to be submitted. In some cases, developers do host their packages on Salsa using Git, but they have not enabled merge requests through the platform because they do not want to deal with non-email-based workflows. Finally, the fifth principle in DEP-18 is that maintainers should allow changes to be reviewed before packages are uploaded to the archive.

DEP-18 suggests that these principles not be subject to strict enforcement. Rather, the idea is that the existence of a DEP with these principles "should alone be enough to drive social agreement" According to the FAQ in the draft, Debian will see benefits as long as most packages follow the principles. In a later message, he pointed out that he had chosen a DEP rather than a General Resolution because he wanted it to be a "fairly soft mechanism" that encourages consensus rather than forcing maintainers to adhere to strict rules.

Web vs. email

One of the objections often raised against adopting a Salsa-based workflow is the shift from email-based conversations to web-based conversations hosted in Salsa. Smedegaard objected to DEP-18's recommendation that developers should enable Salsa's discussion and review of merge requests via the web interface. "Where are my options to mirror the data at Salsa, as I can do with mailinglists and Debbugs, to work with it also offline?"

In his reply, Kekäläinen thanked Smedegaard for maintaining more than 650 packages. "You have for sure developed an optimal workflow for yourself." He reiterated that the draft does not recommend strict enforcement and said, "I would not expect you to move away from what you are doing now". He acknowledged that following principles 3,4, and 5 would probably not benefit Smedegaard or his packages, but said DEP-18 was still useful as a general guideline.

Smedegaard replied that "ideally" all of the packages that list him as a maintainer would be team-maintained. He invited people to get in touch if they would like to help with their maintenance. He said that he had failed if the workflow for maintaining those packages was optimal for him only, and that he had tried for a collaborative workflow—just not a web-centered collaborative workflow. Using GitLab might ensure collaboration, but "mono-cultural collaboration is not the only form of collaboration, and I find it a problematic one".

Subset of packages

Schauer floated the idea of reducing the scope of DEP-18 to a subset of its principles and a smaller set of Debian packages, such as those packages marked as essential. He reasoned that the essential packages are relevant to all Debian packagers, so they should be used to "set an example of how collaborative maintenance in Debian is supposed to work". Luca Boccassi said this was a great idea.

After much more discussion, Kekäläinen followed up with the idea of having the top 150 packages run Salsa CI at least once before upload. The impetus for this was a bug in the python3-pkg-resources package that affected a large number of other Python packages. According to Kekäläinen, the bug would have been caught by Salsa CI before it had been uploaded to unstable and causing "everyone to suffer". Tille suggested making CI opt-out instead of opt-in for packages in Salsa.

One blocker to this, of course, is that not all of the top 150 are even hosted on Salsa to begin with. Currently, 29 of the packages out of the 150 are not on Salsa at all or using it as their primary source control. Ted Ts'o said that he maintains one of those packages (e2fsprogs); so he looked into enabling Salsa CI, but searching for more information turned up little of use. He had several questions that needed to be answered to make Salsa more accessible to maintainers, such as the benefits of using Salsa CI, what tests it runs, and how to get a simple recipe for enabling it. Kekäläinen said he would update the pipeline information page based on the discussions to make it clearer.

Discussion continues

On August 27, Kekäläinen posted a summary of the discussion on DEP-18 so far for the benefit of contributors who didn't want to wade through the more than 140 messages (so far). One benefit of the conversation mentioned in the summary is that it brought to light some actionable complaints about Salsa's performance and reliability "which deterred contribution". He noted that a hardware upgrade was underway to improve its performance.

He noted that the discussion had surfaced "the shared pain points in the packaging workflow beyond just collaboration struggles":

Work should also continue on DEP-14, git-buildpackage, Salsa CI and other tools to decrease the general friction, and in many places simple documentation updates/overhaul is due to avoid unnecessary fragmentation in workflows that isn't intentional so that we later can more clearly focus on discussion the pros and cons of the intentionally different workflows.

While the conversations have not reached anything like consensus, it seems they have been productive exercises nonetheless. Despite a few small flare-ups, the discussions have largely been genial and informative, with package maintainers interested in ways they can improve collaboration—ideally without giving up their preferred workflows.

Someday, Debian may settle on one true method of maintaining packages, but it would be unwise to wager a large sum of money on that happening anytime soon. In the meantime, though, the project has identified many areas for improvement that may make life better for packagers even if DEP-18 never reaches accepted status.


to post comments

Well written

Posted Aug 28, 2024 18:54 UTC (Wed) by ottok (subscriber, #168740) [Link]

Thanks for summarizing a discussion that has been ongoing for many months and in many threads. I think this covers all the main viewpoints and in general is very well written.

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 1:43 UTC (Thu) by intelfx (subscriber, #130118) [Link] (31 responses)

It's 2024. Basically the entire free software world has made it the top priority to push towards SBOM accountability, transparent maintenance and clean, reproducible, verifiable builds.

And only Debian thinks that "mandating use of Salsa or team maintenance would be a mistake" and holds "uscan, patch, sbuild, dupload type workflows" as a sacrosanct ritual.

This would have been hilarious if it wasn't tragic.

Debian is an early adopter of many of these practices, before there were standards

Posted Aug 29, 2024 2:16 UTC (Thu) by pmc (guest, #133391) [Link] (1 responses)

Debian does have clean, reproducible, verifiable builds - that's the purpose of buildd and reproducible-builds. Maintainers upload source packages to the archive (binary uploads are no longer allowed), then buildd nodes build the binary packages and upload those packages to the archive. There are continuous reproducible build tests running on all Debian packages, which build every source package from time to time and ensures that the binary outputs are bit-by-bit equal to what's in the archive from the buildds.

Many Debian maintainers feel that the archive and snapshots are sufficient version control, and that a VCS repo is redundant.

Debian is an early adopter of many of these practices, before there were standards

Posted Aug 29, 2024 5:26 UTC (Thu) by gioele (subscriber, #61675) [Link]

> Many Debian maintainers feel that the archive and snapshots are sufficient version control, and that a VCS repo is redundant.

And that is an ironic take because most of the programs that make the Debian infrastructure are not packaged nor installed from packages. DAK, debbugs, the key-set script... They are all developed collaboratively in VCS repos and installed on the official machines by checking out those repos. No archive, no snapshots for them.

BTW, "Many Debian maintainers": Not many, but a vocal minority. trends.debian.net [1] says that about 93% of the packages are maintained in git, and about 89% of the packages are stored on salsa.debian.org.

[1] https://trends.debian.net/vcs-hosting_testing-percent-sta...

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 8:09 UTC (Thu) by taladar (subscriber, #68407) [Link] (26 responses)

It is not just Debian. The "e-mail based workflow" crowd is also a vocal crowd holding back other projects from adopting standardized workflows, e.g the Linux kernel.

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 9:59 UTC (Thu) by Karellen (subscriber, #67644) [Link] (25 responses)

You make it sound like email-based workflows cannot themselves be a standardized workflow.

Maybe the people wanting to impose web-based workflows on the people already using a standardized email-based workflow should take a look in the mirror sometime, and consider how annoying it might be to have someone else claim that some other workflow is the One True Way, and that they should just conform to that, rather than being able to use whatever system works best for them.

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 15:57 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

The best workflow is a distributed workflow.

You need a central, curated reference point from which you set up your own preferred workflow, and it shouldn't matter a damn how you pull that in to your system.

Then you need a push mechanism, where you interact with the curators (on their terms), but that should be absolutely minimal. Be it a pull request in GitLab / GitHub, an email to Linus, whatever.

Sounds rather like something based on git, to me - the whole point of git was that it was distributed. The only problem I can see is where you have a CI testing and stuff, where you're expected to log in to see results, but WHY? Surely it's not beyond the wit of man to set up a "fire and forget" system that notifies you if action is needed.

The whole point of email is that it's a *push* notification system - it can tell you if something's wrong. The problem with the web is it's a *poll* notification system, and busy people don't want to waste time checking only to be mostly told "nothing's wrong".

A psychologist will tell you, a poll system is addictive, and will waste LOTS of time ... that's why sensible people hate it.

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 16:10 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> The whole point of email is that it's a *push* notification system - it can tell you if something's wrong. The problem with the web is it's a *poll* notification system, and busy people don't want to waste time checking only to be mostly told "nothing's wrong".

You do realize, right, that exactly all forges have email notifications (and most of them have means of _ingesting_ email replies as well)?

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 18:03 UTC (Thu) by atai (subscriber, #10977) [Link] (1 responses)

>The best workflow is a distributed workflow.

>You need a central, curated reference point from which you set up your own preferred workflow, and it shouldn't matter a damn how you pull that in to your system.

Talk about contradicting yourself, in two sentences!

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 21:23 UTC (Thu) by Wol (subscriber, #4433) [Link]

If you don't have a central reference point, isn't that called a fork?

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 16:00 UTC (Thu) by intelfx (subscriber, #130118) [Link] (20 responses)

You're missing the fact that collaboration is inherently a two-sided exercise. If nobody else wants to use a collaboration method that you are so fond of, you cannot claim "it's everyone else's problem".

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 16:41 UTC (Thu) by pizza (subscriber, #46) [Link] (16 responses)

> If nobody else wants to use a collaboration method that you are so fond of, you cannot claim "it's everyone else's problem".

Let me rephrase that:

"I want you to change everything about the way you've been working for literally decades because it's too _haaaaard_ for me to adapt."

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 16:58 UTC (Thu) by intelfx (subscriber, #130118) [Link] (9 responses)

Stripping the personal attack flamebait, the obvious irony is that this works both ways.

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 17:08 UTC (Thu) by pizza (subscriber, #46) [Link] (8 responses)

> Stripping the personal attack flamebait, the obvious irony is that this works both ways.

Sure, it does go both ways.. except that in most professions/disciplines, it's the _newcomers_ that are expected to learn and adapt to the way things are already being done, not the other way around.

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 2:19 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (4 responses)

That's not how the economics work out in the case of FOSS. Most projects are chronically short of person-hours, which tends to imply that there are not enough person-hours to go around. So in the FOSS gift economy, the market conditions currently favor the newcomers - that is, they have their choice of projects to work on, whereas the average project certainly does not have its choice of developers. You can either try to entice the newcomers, or you can accept that you will not receive as many person-hours of labor as you think you need in the long run. Or you can pay for the extra person-hours, which is de facto what Linux has done (I would assume one or two people on LKML are not being paid to be there... but everybody else is, albeit mostly by third parties and not by the Linux Foundation).

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 3:41 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> Most projects are chronically short of person-hours,

So the solution is to make them perform even _more_ work?

Some changes *may* be worth doing if they make life better for the current/active contributors, but in my experience, stuff performed primarily to become more "attractive" has resulted in *zero* additional contributions, while producing the perverse disincentive of an even greater expectation of solving other folks' problems for free.

Making things harder for (and/or pissing off the) folks doing most (if not all) of the actual work rarely leads to better outcomes.

Meanwhile. Developers (and projects!) are not freely interchangeable. It takes time to learn a codebase or even the general problem space a project exists within. That only ever happens if there is genuine interest (or a paycheck) involved.

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 9:12 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> > Most projects are chronically short of person-hours,

> So the solution is to make them perform even _more_ work?

No. The solution is to make them work more efficiently. The problem is (as so often) that so much time is spent fire-fighting, there's no time left to remove the causes of fires.

If the new guy can achieve the same stuff (using his tools of choice) in one hour, as opposed to the old guy taking two or three with his tools, the obvious solution is to move over to using the new tools, not force the new guy to use the old tools. OF COURSE that's going to make the old guy feel uncomfortable, and it's probably going to cost him a lot of hours to learn the new tools (and if he really is an old guy he will take far longer to learn them!)

But not using the new tools is simply propagating technical debt and making the fire-fighting problem worse. Rust claims to remove memory safety from the list of fire-fighting jobs. That's a BIG win. So the question is "how do we get old and new guys to work together", as if things work as claimed then the long term gains are huge.

Banging on MV again, I'm staking my reputation at work on exactly this. I'm planning to move our Excel-based database into OpenQM. In the process, it will expose massive holes in the data we hold, it will replace a huge number of hundred-liner SQL scripts with one-line MV queries, it will massively speed up data retrieval, and it will hopefully also facilitate the changeover from Excel to Google Suite (which is a corporate aim). Imho the gains are massive, if I don't spend so much time fire-fighting.

SQL leads to too many cockups - certainly in our business. We're just waiting for a data feed fix to be deployed - "select cust-orders-planned-data cfc_id spoke_id" returns the same value for cfc and spoke even when my section, LGV, are trunking orders 100 miles or so between the two! The same problem also afflicts cust-orders-actual-data, and is messing up reporting something chronic - most of our goods are currently being picked in non-existent warehouses! :-) I want to remove writing/debugging/fixing SQL from our list of fire-fighting tasks, and imho that is also a BIG win.

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 13:17 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> No. The solution is to make them work more efficiently.

That's an ironically hilarious statement given the context of this discussion (ie the Linux kernel)

> If the new guy can achieve the same stuff (using his tools of choice) in one hour, as opposed to the old guy taking two or three with his tools, the obvious solution is to move over to using the new tools, not force the new guy to use the old tools.

That supposition is based on a _really_ big "If" that relies on facts not in evidence.

(And please don't forget that one of these "same stuffs" is "support/maintain this code for over a decade in environments that have requirements that are fundamentally incompatible with how RustCulture(tm) does things"

> But not using the new tools is simply propagating technical debt and making the fire-fighting problem worse.

...that statement relies on facts not in evidence. (and don't forget that "using the new tools" starts a whole bunch of fires that also have to be dealt with)

> Rust claims to remove memory safety from the list of fire-fighting jobs. That's a BIG win. So the question is "how do we get old and new guys to work together", as if things work as claimed then the long term gains are huge.

Again, that's a _huge_ "if" that relies on facts not in evidence. Indeed, the opposite appears to still be the case.

Meanwhile, it's not "old and new guys working together" -- it's "Old guys, change everything about how you've been developing the single most successful collaborative software project in history, and any objections you have about regressions in functionality or workflows are dismissed as not important because they just aren't"

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 15:37 UTC (Fri) by Wol (subscriber, #4433) [Link]

> > If the new guy can achieve the same stuff (using his tools of choice) in one hour, as opposed to the old guy taking two or three with his tools, the obvious solution is to move over to using the new tools, not force the new guy to use the old tools.

> That supposition is based on a _really_ big "If" that relies on facts not in evidence.

Aren't you forgetting the video driver that was written - in Rust - in a couple of weeks? I don't remember the details, but it was something along the lines of they had experience of doing it in traditional C, and using Rust took a MAHOUSIVE chunk of debug time out of the equation. Something along the lines of "debugging memory issues took maybe 90% of the time in C", versus "the actual development was the same in C and Rust. We just didn't have to debug the Rust afterwards".

That's at least one fact in evidence, and I was under the impression that driver is in (maybe out-of-tree) linux already.

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 4:05 UTC (Fri) by intelfx (subscriber, #130118) [Link] (2 responses)

> Sure, it does go both ways.. except that in most professions/disciplines, it's the _newcomers_ that are expected to learn and adapt to the way things are already being done, not the other way around.

Okay, if we are pulling out this kind of argumentation, then I kindly refer you to my first posting in this subthread: collaboration is inherently a bidirectional process. Of course you can tell the newcomers to get off the lawn, but in the end it's the self-righteous old farts who are going to find out that nobody wants to play with them.

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 12:03 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Okay, if we are pulling out this kind of argumentation, then I kindly refer you to my first posting in this subthread: collaboration is inherently a bidirectional process. Of course you can tell the newcomers to get off the lawn, but in the end it's the self-righteous old farts who are going to find out that nobody wants to play with them.

Of course collaboration is bi-directional, yet... what you're _actually_ saying is that the old farts should be doing all of the accommodating.

That's not collaboration. It's entitlement.

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 13:08 UTC (Fri) by Wol (subscriber, #4433) [Link]

> That's not collaboration. It's entitlement.

No. It's the new guys saying "I can't be bothered to learn old tech that's going to make my life harder". The laugh, of course, comes when they try to get their new tech to work and hey - actually the new tech isn't up to the job!

That's the thing with linux, raw git is the denominator, and it's got lots of porcelain on top. Use that!

The problem is when people - on either side of the divide - say "I'm not budging". That was my point about the central repo should be as agnostic as possible about the developer's work flow. The central repo does things its way. The developers do things their way. And you try and thrash out a simple API that "just works" by getting in everybody's way as little as possible.

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Sep 2, 2024 10:58 UTC (Mon) by taladar (subscriber, #68407) [Link] (5 responses)

In the whole email vs. forges discussion what is often forgotten is that the tools are not the same objectively.

Email might be amazing if you are completely task-saturated and every time you finish something you just want something else to pick up to fill your time.

What email is not so great at is to keep all the tasks around that nobody happened to pick up in the moment and that still need doing. It is also not great at prioritizing tasks by either objective (e.g. subsystem x has a major bug that will corrupt random other subsystems) or subjective criteria (anything from 'this fits my particular skillset' to 'I would like to work on this').

The collaboration method might be a big part of why everyone who already works in the community is so busy in the first place. It certainly is a big part of why it is hard to find new people who want to join and find them appropriate tasks.

This would have been hilarious if it wasn't tragic

Posted Sep 2, 2024 12:53 UTC (Mon) by pizza (subscriber, #46) [Link] (4 responses)

> Email might be amazing if you are completely task-saturated and every time you finish something you just want something else to pick up to fill your time.

.... Isn't that the entire point? Email scales (if only by virtue of allowing the _user_ to filter/set the priorities of what they care about) and the others universally consider themselves to be the ONLY THING THAT MATTERS?

> The collaboration method might be a big part of why everyone who already works in the community is so busy in the first place. It certainly is a big part of why it is hard to find new people who want to join and find them appropriate tasks.

Everyone is super busy, regardless of the collaboration method. The quesstion is how do you scale/manage your own efforts,

Scaling e-mail

Posted Sep 2, 2024 15:30 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

There's a generational divide, here, too (and I fall both sides of this divide). Us older folk have an e-mail system with filtering rules etc that we know how to drive, and that just works; my home e-mail setup fits this model. In this setup, it's trivial for me to take part in one more e-mail-driven workflow, because I just add more rules for it.

But my work e-mail setup, with workplace-driven lockdowns, is not like this. I don't have access to a set of filtering rules I understand, but instead have everything sorted for me into "Spam" and "Inbox"; all onwards filtering is manual, as far as I can find easily. There may be a filtering system, but I don't do enough with my work e-mail to find it and to be bothered setting it up, because I simply don't get enough e-mail there to make the time investment in learning yet another mail filtering system worthwhile.

So, for work stuff, my bias is towards web workflows, like GitHub and GitLab, because they work within the systems I use for work. For personal stuff, I'm happy either way - I've learnt to drive web workflows thanks to work (and there's CLI tools for things like GitHub, it's not just "use the damnable browser"), and I can drive e-mail workflows because I've been doing that for decades.

But for someone who's not set up a "traditional" e-mail system, there's a breakpoint; setting one up for a single project is a daunting investment into new processes, and if it's easier for me to just go "nope, not doing that" for work things (when I could use my home e-mail setup), it's almost certainly easier for many people to just use the default GMail or Outlook.com setup and not care about e-mail workflows.

Scaling e-mail

Posted Sep 5, 2024 12:38 UTC (Thu) by taladar (subscriber, #68407) [Link]

E-mail is just so local, limited to the one user. That might be fine if you are the only maintainer on some project but as soon as you work with others something like an issue tracker just makes both the things you work on and the things that fall by the wayside so much more visible. Not to mention the bug you just discovered that someone else already reported two years ago.

This would have been hilarious if it wasn't tragic

Posted Sep 5, 2024 12:36 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

You are talking about filtering and prioritizing just for you personally. I am talking about it in the broader scope of the project. Your personal email filtering rules are completely useless to anyone else in the project and the emails you filter out certainly won't be obvious to others who want to pick a task you aren't already working on.

This would have been hilarious if it wasn't tragic

Posted Sep 5, 2024 14:16 UTC (Thu) by pizza (subscriber, #46) [Link]

> You are talking about filtering and prioritizing just for you personally. I am talking about it in the broader scope of the project.

...From any given project's perspective, nothing outside its little bubble matters.

Meanwhile, I'm talking about the overwhelmingly-common case where a given individual is involved with more than one project. (notably including the one called "real life")

> Your personal email filtering rules are completely useless to anyone else in the project

Yes and no -- my _priorities_ are useless for anyone else, but the filtering _system_ is completely generic and universally available, which is far more than can be said for most systems. (Whether or not a given user can be arsed to set it up is another matter, but that applies to _any_ tool)

> and the emails you filter out certainly won't be obvious to others who want to pick a task you aren't already working on.

If you want to work with others you need to find a way to coordinate/synchronize your efforts.

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 18:50 UTC (Thu) by gioele (subscriber, #61675) [Link] (2 responses)

> If nobody else wants to use a collaboration method that you are so fond of, you cannot claim "it's everyone else's problem".

This statement is true in general, but it does not apply to the very case being discussed in this LWN article.

In the context discussed in this LWN article (Debian), there is a majority that uses a collaboration method (git, in almost all cases Salsa and with the default Salsa CI enabled) and a minority that refuses that (in particular, no git).

Some in the majority would like to raise the baseline for everybody, including for the minority. There is on the side of the majority disagreement about how much to raise the baseline (VCS mandatory? Salsa mandatory? Salsa CI mandatory?).

At the same time, on the side of the minority there is a clear desire to not change the status quo (in particular no VCS).

Personally, I'd be happy if Debian could settle at mandating the use of a VCS (whatever VCS, hosted wherever) kept in sync with the archive (dgit would be suboptimal but good enough). Other discussions related to how Debian collaborates (like where to host the VCS, whether to standardize on Git, which packaging workflow to use, whether to use a CI) could be discussed later.

PS: It's 2024 and people are discussing whether to use a VCS...

This would have been hilarious if it wasn't tragic

Posted Aug 29, 2024 21:29 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Personally, I'd be happy if Debian could settle at mandating the use of a VCS (whatever VCS, hosted wherever) kept in sync with the archive (dgit would be suboptimal but good enough).

Istm that the obvious next step is just to say "New packages must meet the standard of git, salsa and CI".

Existing packages can move over as and when, typically when the maintainer changes, I would expect.

Cheers,
Wol

This would have been hilarious if it wasn't tragic

Posted Aug 30, 2024 4:20 UTC (Fri) by intelfx (subscriber, #130118) [Link]

> In the context discussed in this LWN article (Debian), there is a majority that uses a collaboration method (git, in almost all cases Salsa and with the default Salsa CI enabled) and a minority that refuses that (in particular, no git).
>
> Some in the majority would like to raise the baseline for everybody, including for the minority. There is on the side of the majority disagreement about how much to raise the baseline (VCS mandatory? Salsa mandatory? Salsa CI mandatory?).
>
> At the same time, on the side of the minority there is a clear desire to not change the status quo (in particular no VCS).

I don't see how is this different from what I was saying? We have a majority that wants to use modern collaboration and automation methods and prefers them to ye olde ways, and a minority that rejects the former and only recognizes the latter.

What I was responding to was the "look in the mirror" retort laden with loaded language, and I was saying that there's no "one true way" claims or any "imposition" going on, there's just collaboration — and if the minority doesn't want to (gasp!) adapt, that's perfectly fine. The minority will simply eventually discover that nobody else wants to collaborate with them.

This would have been hilarious if it wasn't tragic

Posted Sep 2, 2024 21:25 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

Debian does not have the manpower to maintain salsa after gitlab eventually stop supporting it, so it is better not to invest too much on it. We already lost alioth.

This would have been hilarious if it wasn't tragic

Posted Sep 5, 2024 3:46 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I wouldn't worry too much about that kind of thing because future Debian maintainers of Salsa are fully capable of making a plan if Gitlab is no longer maintained by it's current company, which is dependant on the circumstances if that comes to pass. They could migrate to something else, other forges exist, fork the source and maintain it on life support sufficient for Debian needs, form a larger dev group with GNOME and other Gitlab customers to take over development more fully, like Terraform, or some other situation specific plan. Without any specific reason to believe that Gitlab is at risk of imminent collapse I don't think the existence of solvable problems should they fail is a reason not to use it if it fills a need, and is currently part of Debian infrastructure.


Copyright © 2024, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds