How do I unsubscribe from these emails?
On Wed, May 1, 2024 at 11:15 PM Andreas Tille <tille@debian.org> wrote:
Hi,
keeping my promise for monthly bits, here's a quick snapshot of my first ten days as DPL.
Special thanks to Jonathan for an insightful introduction that left less room for questions. His introduction covered my first tasks like expense approval and CTTE member appointments thoroughly. Although I made a
visible oversight by forgetting to exclude Simon McVittie <smcv> from
the list, whose term has ended[0], I'm committed to learning from this mistake. In future I'll prioritize thorough proofreading to ensure accuracy.
Part of my "work" was learning what channels I need to subscribe and
adjust my .procmailrc and .muttrc took some time.
Recently I had my first press interview. I had to answer a couple of prepared questions for Business IT News[1]. It seems journalists are always on the lookout for unique angles. When asked if humility is a new trait for DPLs, my response would be a resounding "No." In my
experience, humility is a common quality among DPLs I've encountered, including Jonathan.
One of my top priorities is reaching out to all our dedicated and
appointed teams, including those managing critical infrastructure. I've begun with the CTTE, Salsa Admins and Debian Snapshot. Everything
appears to be in order with the CTTE team. I'm waiting for response
from Salsa and Snapshot, which is fine given the recent contact.
I was pointed out to the fact that lintian is in an unfortunate state as Axel Beckert confirmed on the lintian maintainers list[2]. It turns out that bug #1069745 of magics-python should not have been undetected for
a long time if lintian bug #677078[3] would have been fixed. It seems obvious to me that lintian needs more work to fulfill its role as
reliably policy checker to ensure our high level of packaging quality.
In any case thanks a lot to Axel who is doing his best but it seems
urgent to me to find some more person-power for this task. Any volunteer to lend some helping hand in the lintian maintainers team?
On 2024-04-30 I gave my first talk "Bits from greenhorn DPL" online
at MiniDebConf Brasil in Belo Horizonte. The Q&A afterwards stired
some flavours of the question: "What can Debian Brasil do better?"
My answer was always in a way: Given your great activity in now
organising the fifth MiniDebConf you are doing pretty well and I have
no additional hints for the moment.
Kind regards
Andreas.
[0] https://lists.debian.org/debian-devel-announce/2024/04/msg00010.html [1] https://itwire.com/business-it-news/open-source/new-debian-leader-brings-an-unusual-trait-to-the-job-humility.html
[2] https://lists.debian.org/debian-lint-maint/2024/04/msg00010.html
[3] https://bugs.debian.org/677078
lintian: Check for Architecture: all in Perl, Python, Ruby etc. packages
Date: Mon, 11 Jun 2012 16:15:53 +0300
in connection with MiniDebConf Berlin there was some discussion about
what expense per attendee of some in person meeting is OK. Quoting
Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:
Debian is willing to reimburse up to 100 USD for expenses to attend Bug
Squashing Parties (BSPs). If there are no BSPs near to you, please help
organise one!
On Sat, Jun 01, 2024 at 09:52:32AM +0200, Andreas Tille wrote:
in connection with MiniDebConf Berlin there was some discussion about
what expense per attendee of some in person meeting is OK. Quoting
Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:
Debian is willing to reimburse up to 100 USD for expenses to attend Bug
Squashing Parties (BSPs). If there are no BSPs near to you, please help
organise one!
however, "costs to attend" are not the same as "costs while attending"...
On Mon, 03 Jun 2024 11:00:34 +0000, Holger Levsen wrote:
however, "costs to attend" are not the same as "costs while attending"...
Also & related, https://wiki.debian.org/HostingBSP#Sponsorships says (emphasis mine):
participants to a BSP can get a reimbursement of up to 100 USD for their
*travel fees*.
whereas the discussions around the MiniDebConf Berlin were about
sponsored food, IIRC.
Note that I'm not saying "Debian must pay for food for a week for
all people at any price, no matter what", just that "100 USD for
expenses" is not the same as "100 USD for their travel fees".
No big deal, just maybe a chance for clarification before the next
Debian event :)
Remove my email from all lists.
On Mon, Sep 2, 2024 at 9:24 AM Andreas Tille <tille@debian.org> wrote:
Dear Debian community,
this are my bits from DPL for August.
Happy Birthday Debian
---------------------
On 16th of August Debian celebrated its 31th birthday. Since I'm
unable to write a better text than our great publicity team I'm
simply linking to their article for those who might have missed it:
https://bits.debian.org/tag/birthday.html
Removing more packages from unstable
------------------------------------
Helmut Grohne argued for more aggressive package removal and sought
consensus on a way forward[ru1]. He provided six examples of processes
where packages that are candidates for removal are consuming valuable
person-power. I’d like to add that the Bug of the Day initiative (see
below) also frequently encounters long-unmaintained packages with popcon
votes sometimes as low as zero, and often fewer than ten.
Helmut's email included a list of packages that would meet the suggested
removal criteria. There was some discussion about whether a popcon vote
should be included in these criteria, with arguments both for[ru2] and
against[ru3] it. Although I support including popcon, I acknowledge that
Helmut has a valid point in suggesting it be left out.
While I’ve read several emails in agreement, Scott Kitterman made a
valid point[ru4]: "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn’t lead
to unwanted removals. However, I don’t see "someone" stepping up to file
RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
In this aspect the opinion of Niels Thykier[ru5] is interesting: "As
much as I want automation, I do not mind the prototype starting as a
semi-automatic process if that is what it takes to get started."
The urgency of the problem to remove packages was put by Charles
Plessy[ru6] into the words: "So as of today, it is much less work to
keep a package rotting than removing it." My observation when trying to
fix the Bug of the Day exactly fits this statement.
I would love for this discussion to lead to more aggressive removals
that we can agree upon, whether they are automated, semi-automated, or
managed by a person processing an automatically generated list
(supported by an objective procedure). To use an analogy: I’ve found
that every image collection improves with aggressive pruning. Similarly,
I’m convinced that Debian will improve if we remove packages that no
longer serve our users well.
[ru1] https://lists.debian.org/debian-devel/2024/08/msg00298.html
[ru2] https://lists.debian.org/debian-devel/2024/08/msg00362.html
[ru3] https://lists.debian.org/debian-devel/2024/08/msg00354.html
[ru4] https://lists.debian.org/debian-devel/2024/08/msg00314.html
[ru5] https://lists.debian.org/debian-devel/2024/08/msg00306.html
[ru6] https://lists.debian.org/debian-devel/2024/08/msg00320.html
DEP14 / DEP18
-------------
There are two DEPs that affect our workflow for maintaining
packages—particularly for those who agree on using Git for Debian
packages. DEP-14 recommends a standardized layout for Git packaging
repositories, which benefits maintainers working across teams and makes
it easier for newcomers to learn a consistent repository structure.
DEP-14 stalled for various reasons. Sam Hartman suspected[de2] it might
be because 'it doesn't bring sufficient value.' However, the assumption
that git-buildpackage is incompatible with DEP-14 is incorrect, as
confirmed by its author, Guido Günther[de3]. As one of the two key tools
for Debian Git repositories (besides dgit) fully supports DEP-14, though
the migration from the previous default is somewhat complex.
Some investigation into mass-converting older formats to DEP-14 was
conducted by the Perl team, as Gregor Hermann pointed out.[de4].
The discussion about DEP-14 resurfaced with the suggestion of DEP-18.
Guido Günther proposed the title[de5] 'Encourage Continuous Integration
and Merge Request-Based Collaboration for Debian Packages,' which more
accurately reflects the DEP's technical intent.
Otto Kekäläinen, who initiated DEP-18 (thank you, Otto), provided a good
summary of the current status[de6]. He also assembled a very helpful
overview of Git and GitLab usage in other Linux distros[de7].
[de1] https://dep-team.pages.debian.net/deps/dep14/
[de2] https://lists.debian.org/debian-devel/2024/08/msg00229.html
[de3] https://lists.debian.org/debian-devel/2024/08/msg00212.html
[de4] https://lists.debian.org/debian-devel/2024/08/msg00232.html
[de5] https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_520426
[de6] https://lists.debian.org/debian-devel/2024/08/msg00433.html
[de7] https://lists.debian.org/debian-devel/2024/08/msg00419.html
More Salsa CI
-------------
As a result of the DEP-18 discussion, Otto Kekäläinen suggested
implementing Salsa CI for our top popcon packages[ci1].
I believe it would be a good idea to enable CI by default across Salsa
whenever a new repository is created.[ci2]
[ci1] https://lists.debian.org/debian-devel/2024/08/msg00318.html
[ci2] https://lists.debian.org/debian-devel/2024/08/msg00370.html
Progress in Salsa migration
---------------------------
In my campaign, I stated[sm1] that I aim to reduce the number of
packages maintained outside Salsa to below 2,000. As of March 28, 2024,
the count was 2,368. Today, it stands at 2,187[sm2].
After a third of my DPL term (OMG), we've made significant progress,
reducing the amount in question (369 packages) by nearly half. I'm
pleased with the support from the DDs who moved their packages to Salsa.
Some packages were transferred as part of the Bug of the Day initiative
(see below).
[s1] https://lists.debian.org/debian-vote/2024/03/msg00057.html
[sm2] UDD query:
SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;
Bug of the Day
--------------
As announced in my 'Bits from the DPL' talk at DebConf[bd1], I started
an initiative called Bug of the Day[bd2]. The goal is to train newcomers
in bug triaging by enabling them to tackle small, self-contained QA
tasks. We have consistently identified target packages and resolved at
least one bug per day, often addressing multiple bugs in a single
package.
In several cases, we followed the Package Salvaging procedure outlined
in the Developers Reference[bd3]. Most instances were either welcomed by
the maintainer or did not elicit a response. Unfortunately, there was
one exception where the recipient of the Package Salvage bug expressed
significant dissatisfaction. The takeaway is to balance formal
procedures with consideration for the recipient’s perspective.
I'm pleased to confirm that the Matrix channel[bd4] has seen an increase
in active contributors. This aligns with my hope that our efforts would
attract individuals interested in QA work. I’m particularly pleased
that, within just one month, we have had help with both fixing bugs and
improving the code that aids in bug selection.
As I aim to introduce newcomers to various teams within Debian, I also
take the opportunity to learn about each team's specific policies
myself. I rely on team members' assistance to adapt to these policies. I
find that gaining this practical insight into team dynamics is an
effective way to understand the different teams within Debian as DPL.
Another finding from this initiative, which aligns with my goal as DPL,
is that many of the packages we addressed are already on Salsa but have
not been uploaded, meaning their VCS fields are not published. This
suggests that maintainers are generally open to managing their packages
on Salsa. For packages that were not yet on Salsa, the move was
generally welcomed.
[bd1] https://debconf24.debconf.org/talks/20-bits-from-the-dpl/
[bd2] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[bd3] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[bd4] https://matrix.to/#/#debian-tiny-tasks:matrix.org
Publicity team wants you
------------------------
The publicity team has decided to resume regular meetings to coordinate
their efforts. Given my high regard for their work, I plan to attend
their meetings as frequently as possible, which I began doing with the
first IRC meeting.
During discussions with some team members, I learned that the team could
use additional help. If anyone interested in supporting Debian with
non-packaging tasks reads this, please consider introducing yourself to
debian-publicity@lists.debian.org. Note that this is a publicly archived
mailing list, so it's not the best place for sharing private
information.
Kind regards
Andreas.
--
https://fam-tille.de
While I’ve read several emails in agreement, Scott Kitterman made a...
valid point[ru4]: "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn’t lead
to unwanted removals. However, I don’t see "someone" stepping up to file
RM bugs against other maintainers' packages. As long as we have strict ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received. Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote:
...
While I’ve read several emails in agreement, Scott Kitterman made a...
valid point[ru4]: "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn’t lead
to unwanted removals. However, I don’t see "someone" stepping up to file >> RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
Interesting perspective. This you?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816
Scott Kitterman <debian@kitterman.com> wrote on 04/09/2024 at 06:23:50+0200:
On Monday, September 2, 2024 11:23:30 AM EDT Andreas Tille wrote:
...
While I’ve read several emails in agreement, Scott Kitterman made a
valid point[ru4]: "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn’t lead >> to unwanted removals. However, I don’t see "someone" stepping up to file >> RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even >> for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
...
Interesting perspective. This you?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816
OoC, what is your point, especially considering the quote of your own
opinion Andreas made?
This just seems passive-aggressive, and the fact he stepped up once
doesn't mean he has the time or will to step up hundreds of times.
On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote:
OoC, what is your point, especially considering the quote of your own opinion Andreas made?
This just seems passive-aggressive, and the fact he stepped up once
doesn't mean he has the time or will to step up hundreds of times.
I think it's odd that he would talk about how hesitant people are to touch other packages when he in fact does it himself. I'm not sure who he thinks he's speaking for, clearly not himself.
I don't have statistics, but maintainer filed RM requests a pretty rare. My impression is it's only a small fraction of the total. I processed a lot of requests last night and almost none of the requests for package removal were from maintainers.
It probably was a little passive aggressive, but I don't appreciate the DPL using the Bits from DPL message to punch down like that. If he has a point to
make to further the discussion, it should be made as part of the discussion.
If he's only trying to bring the issue to the wider project's attention, then I don't think picking one person's opinion to disagree with in Bits is very appropriate.
FWIW, all an automated process would do is create work for the FTP Team. Those I would feel I have to scrutinize even more closely than ones filed by a
human since no one has given it a sanity check before it gets to the FTP Team to process.
Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman:
On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: >> >
OoC, what is your point, especially considering the quote of your own
opinion Andreas made?
This just seems passive-aggressive, and the fact he stepped up once
doesn't mean he has the time or will to step up hundreds of times.
I think it's odd that he would talk about how hesitant people are to touch >> other packages when he in fact does it himself. I'm not sure who he thinks >> he's speaking for, clearly not himself.
I did it *after* someone with insight into the topic gave the according hint[1].
So the sequence was:
1. I filed ITS
2. Someone with insight suggested removal
3. Reassigned ITS to RM
I personally see some difference between this sequence and a straight asking for
removal.
I don't have statistics, but maintainer filed RM requests a pretty rare. My
impression is it's only a small fraction of the total. I processed a lot of
requests last night and almost none of the requests for package removal were
from maintainers.
You are definitely the expert about package removals.
It probably was a little passive aggressive, but I don't appreciate the DPL >> using the Bits from DPL message to punch down like that. If he has a point to
make to further the discussion, it should be made as part of the discussion.
My intention was to highlight interesting contributions to the entire >discussion. If phrases like 'Scott Kitterman made a valid point' and 'I >agree' came across as dismissive, I sincerely apologize—that was not my >intent. I genuinely valued your point, and I added my own suggestion
"based on defined criteria, it could help reduce some of the social >pressure."
Item 2. above could possibly be such a criterion, since you pointed to
this actual example.
If he's only trying to bring the issue to the wider project's attention, then
I don't think picking one person's opinion to disagree with in Bits is very >> appropriate.
I'm sorry if there was any misunderstanding, but I'm unsure how my
message gave the impression that I disagreed. Could you clarify which
part led you to this conclusion? Also, just to clarify, I avoid using
sarcasm in electronic communication, especially in Bits from the DPL, as
it often doesn't translate well.
FWIW, all an automated process would do is create work for the FTP Team. >> Those I would feel I have to scrutinize even more closely than ones filed by a
human since no one has given it a sanity check before it gets to the FTP Team
to process.
I need to trust you here as the one who is doing the work. The
discussion also was about a semi-automatic process which. Do you have
some opinion about this?
Attracting newcomerseven just a DM, in a situation where I only maintain a handful of
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my apologies for this. However, I want to revisit the sole question raised, which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first place.
My personal impression is that we sometimes fail to convey that Debian
is not just a product to download for free but also a technical
challenge that warmly invites participation. Everyone who respects our
Code of Conduct will find that Debian is a highly diverse community,
where joining the project offers not only opportunities for technical contributions but also meaningful social interactions that can make the effort and time truly rewarding.
In several of my previous talks (you can find them on my talks page[mt4]--just search for "team," and don't be deterred if you see
"Debian Med" in the title; it's simply an example), I emphasized that
the interaction between a mentor and a mentee often plays a far more significant role than the documentation the mentee has to read. The key
to success has always been finding a way to spark the mentee's interest
in a specific topic that resonates with their own passions.
From personal experience, jumping through hoops to become a DD, or
(non-subscriber; please keep me in CC whenever reply to this)[...]
ma 2.12.2024 klo 18.33 Andreas Tille (tille@debian.org) kirjoitti:
Attracting newcomers
From personal experience, jumping through hoops to become a DD, or[...]
even just a DM, in a situation where I only maintain a handful of
packages and randomly contribute patches to other packages (or
overhaul the packaging before handing the package over to its next maintainer) simply hasn't been worth the troubles.
Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my apologies for this. However, I want to revisit the sole question raised, which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first place.
Would I bother to go through NM now if the process were more simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people with upload permissions who are happy to help on the occasions it's needed.
The fallacy is to assume that just because someone contributed a
patch, their next step is to quit their dayjob and become a full-time contributor.
On 2024-12-02 19:09:33 +0200 (+0200), Martin-Éric Racine wrote:
(non-subscriber; please keep me in CC whenever reply to this)
ma 2.12.2024 klo 18.33 Andreas Tille (tille@debian.org) kirjoitti:[...]
Attracting newcomers
From personal experience, jumping through hoops to become a DD, or[...]
even just a DM, in a situation where I only maintain a handful of
packages and randomly contribute patches to other packages (or
overhaul the packaging before handing the package over to its next maintainer) simply hasn't been worth the troubles.
I'll just say you're not alone. I've been around the Debian
community since pre-Y2K and, if I'd cared, could probably have been
a DD rather easily when the requirements were little more than say
'hi' and have enough DD signatures on your key.
Would I bother to go through NM now if the process were more simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people with upload permissions who are happy to help on the occasions it's needed.
On Monday, December 2, 2024 9:32:27 AM MST Andreas Tille wrote:
Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.
I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian Maintainers, and those who are current Debian Maintainers to become Debian Developers would be to create an official DPL Mentors Delegation.
Soren Stoutner <soren@debian.org> writes:and
On Monday, December 2, 2024 9:32:27 AM MST Andreas Tille wrote:
Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised, >> which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in >> the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining >> up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first >> place.
I think one of the best things we could do to attract new contributors,
Debianto encourage those who are currently Sponsored Maintainers to become
Maintainers, and those who are current Debian Maintainers to become Debian Developers would be to create an official DPL Mentors Delegation.
I dont disagree with anything you wrote, but i think people are looking
at "Needs a DD to make the process work" and assuming that the only
solution is to increase the number of DDs. But the process itself can
also be changed.
at least some of the feedback so far is that people want to contribute without having to be a DD
Number of packages not on Salsa
-------------------------------
In my campaign, I stated [os1] that I aimed to reduce the number of
packages maintained outside Salsa to below 2,000. As of March 28, 2024,
the count was 2,368. As of this writing, the count stands at 1,928
[os2], so I consider this promise fulfilled. My thanks go out to
everyone who contributed to this effort. Moving forward, I’d like to set
a more ambitious goal for the remainder of my term and hope we can
reduce the number to below 1,800.
[os1] https://lists.debian.org/debian-vote/2024/03/msg00057.html
[os2] UDD query:
SELECT DISTINCT count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;
Without seeking to rain on the parade, that query is only the packages that list a non-salsa VCS. That's not counting the packages that don't list a VCS at all and therefore are also maintained outside salsa:
udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND vcs_url IS NULL;
count
-------
2008
(both SQL "LIKE" and "NOT LIKE" don't match NULL values; there 2030 source packages in UDD that match but only 2008 distinct ones)
So for completeness:
udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND (vcs_url IS NULL OR vcs_url NOT LIKE '%salsa%');
count
-------
3906
While I'd love to see all packages on Salsa
Le 2025-01-07 20:03, Andreas Tille a écrit :
While I'd love to see all packages on Salsa
I think that being able to host the primary git repository of packages elsewhere is a freedom worth maintaining for many reasons.
What the Debian Project could (and probably should) do in these cases is to host a read-only mirror of the repository with most features disabled by default (no issues, no merge requests, no CI unless the maintainers switch them on), just keeping the possibility to fork the repository. This would mitigate the risk that the repository just vanishes, maybe help to alleviate some scaling issues like API rate limits on some platforms, and make it easier for would-be contributors to maintain a public fork for the platforms that make it complicated or impossible or have unreasonable ToS.
Le 2025-01-07 20:03, Andreas Tille a écrit :
While I'd love to see all packages on Salsa
I think that being able to host the primary git repository of packages elsewhere is a freedom worth maintaining for many reasons.
I don't think we should continue to allow the "freedom" to be
annoying for every other contributors. Even if there may be some
"technical excuses" to do so.
I think that being able to host the primary git repository of packages elsewhere is a freedom worth maintaining for many reasons.
I don't think we should continue to allow the "freedom" to be annoying for every other contributors. Even if there may be some "technical excuses" to do so.
That's fair. I maintain a package of a project where I eventually
moved the upstream codebase into revision control but have been too lazy/distracted to do the same for the debian directory (which I realistically only update once every year or two). I'm committed to
importing that into Salsa eventually, it's just a question of when
I'll find the time.
While I'd love to see all packages on Salsa
I think that being able to host the primary git repository of packages elsewhere is a freedom worth maintaining for many reasons.
No, I don't think this is a good idea, and at my first thought, I
personally don't see any practical reasons.
You can always keep _another_ copy on another git repository, either by client-side push to both salsa and your server, or by making salsa push automatically to your server - your choice. But having the main
repository on Salsa for all packages gives tremendous advantages.
Hm. That sounds interesting, but I think the Debian project cannot
protect such a mirror from automatically bringing in non-DFSG content
that appears in the remote repository. One might even take this one
step
further and go to content forbidden by law in various jurisdictions.
Le 2025-01-07 21:52, Peter Pentchev a écrit :
Hm. That sounds interesting, but I think the Debian project cannot
protect such a mirror from automatically bringing in non-DFSG content
that appears in the remote repository. One might even take this one step further and go to content forbidden by law in various jurisdictions.
Then we are going to have the same issue implementing automated upstream release imports in packaging repositories, e.g. with the Janitor, and this
is a service I would very much like to have.
I would worry more about malicious content getting automatically pulled in. But anyway this can probably be mitigated the way large platforms do: make
it possible to easily report abuse and being diligent in investigating them, eventually putting the repository offline until the issue is cleared.
Additional automated checks could be implemented to suspend updates and require human review e.g. with LICENSE changes unless the file contents matches a whitelist.
Alternatively the mirroring could be implemented to pull only the release tags after a package is uploaded to the archive (which means that someone reviewed the changes), and dealt with on a case-by-case basis for non-free packages or packages that have +dfsg repacking.
On Wed, Jan 08, 2025 at 10:19:34AM +0100, Julien Plissonneau Duquène wrote:
Le 2025-01-07 21:52, Peter Pentchev a écrit :
Hm. That sounds interesting, but I think the Debian project cannot protect such a mirror from automatically bringing in non-DFSG content that appears in the remote repository. One might even take this one step further and go to content forbidden by law in various jurisdictions.
Then we are going to have the same issue implementing automated upstream release imports in packaging repositories, e.g. with the Janitor, and this is a service I would very much like to have.
Unfortunately you are correct that the same problem would arise.
Lets think about some better fine tuning. "NOT LIKE '%salsa%'" might
catch also Vcs URLs that are intentionally somewhere else. While I'd
love to see all packages on Salsa, it might be sensible to start with packages that are unintentionally not in Salsa so
udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND (vcs_url IS NULL OR vcs_url like '%alioth%' OR vcs_url like '%git.debian.org%' OR vcs_url like '%svn.debian.org%') ;
count
-------
2213
That might make a real challenge to bring that number below 2000 until
end of my term. Any help to approach this is welcome.
Well, let's look at some of these other d.o URLs.
- Not our alioth: There are 16 vcs URLs in there that have 'alioth'
in them but aren't alioth.debian.org; they are git hosted but not
on Debian infrastructure (and perhaps not in a place that facilitates
collaboration in the way being discussed)
- dgit.debian.org: There are 30 in there that are dgit.debian.org.
That surprised me, maybe I don't know enough about dgit.
- git.debian.org: There are 146 with git.debian.org - none of these VCS
URLs work any more
- svn.debian.org: !4 list svn.d.o but like git.d.o that's dead. svn.d.o
doesn't even exist as a hostname any more.
There's 161 packages in sid with old d.o URLs pointing to alioth. There's a reasonable chance that a good portion of them are also not maintained.
- 11% of them list their maintainer as Debian QA Group
- 13% of them have a current O bug (another 1 with an RFA)
- who knows how many are otherwise abandoned with MIA maintainers or
maintainers who have just moved on to other things
There was a recent discussion about what to do with VCSes for orphaned packages. Maybe if it doesn't exist on salsa, it's worth creating one in the salsa.d.o/debian/ namespace as part of doing the QA upload?
(gbp import-dscs --debsnap) That would be a good outcome and a good little project for someone...
The vast majority of these packages have seen post-alioth uploads but with the broken Vcs fields still in place.
That's perhaps offering the opposite
of collaborative development? The question is whether the repo has actually moved to salsa but d/control hasn't been updated, or whether the repo has just vanished. An MBF that the VCS fields are out of date is easy, but checking and fixing is likely manual work.
year | count
-----+-------
2011 | 1
2012 | 4
2013 | 3
2014 | 4
2015 | 1
2016 | 1
2017 | 2
2018 | 2 (salsa.d.o general availability)
2019 | 1
2020 | 13
2021 | 95
2022 | 20
2023 | 7
2024 | 6
2025 | 1
I noticed that some teams have some lintian tags checking this from a team policy perspective - doing this more broadly for other teams would help provide teams with visibility via lintian.d.o reports.
lintian-explain-tags -t team/pkg-perl/vcs/no-git \
team/pkg-perl/vcs/no-team-url
(I accidentally found 2 python-team packages without Vcs URLs yesterday -
the repos were on salsa, just not listed in d/control)
Over half of these old alioth URLs can be addressed by Teams doing some data normalisation and uploads:
maintainer_name | count -------------------------------+-------
Debian Perl Group | 72
Debian Java Maintainers | 10
Debian X Strike Force | 7
Debian XML/SGML Group | 4
Debian Science Maintainers | 3
Debian CLI Applications Team | 2
Debian Ruby Extras Maintainers | 1
Debian Javascript Maintainers | 1
Debian Telepathy maintainers | 1
Debian Fonts Task Force | 1
Debian CLI Libraries Team | 1
Debian-IN Team | 1
Debichem Team | 1
NeuroDebian Team | 1
The Debian Lua Team | 1
So in terms of where to start... perhaps there's a couple of teams that
would like to do some data cleansing?
On Wed, 8 Jan 2025 at 14:35, Peter Pentchev <roam@ringlet.net> wrote:
On Wed, Jan 08, 2025 at 10:19:34AM +0100, Julien Plissonneau Duquène wrote:
Le 2025-01-07 21:52, Peter Pentchev a écrit :
Hm. That sounds interesting, but I think the Debian project cannot protect such a mirror from automatically bringing in non-DFSG content that appears in the remote repository. One might even take this one step
further and go to content forbidden by law in various jurisdictions.
Then we are going to have the same issue implementing automated upstream release imports in packaging repositories, e.g. with the Janitor, and this
is a service I would very much like to have.
Unfortunately you are correct that the same problem would arise.
Note that there aren't, and never were, rules concerning DFSG content
and git repositories. In Salsa (and also in its predecessor forge,
Alioth) you can find repositories for packages uploaded to non-free - firmwares, drivers, etc. And that makes sense, as the rules apply to
the 'main' section of the archive, which is what we ship to users, not
to development infrastructure, otherwise you couldn't upload non-free packages to buildds to get them built, or deb.debian.org to be
published in the non-free section, and so on.
So it's entirely ok if mirroring brings in non-DFSG content, as long
as packages are uploaded to the appropriate non-free or firmware
sections of the archive.
Hm, I would be really, really surprised if there was even one "large platform" that did not shift the responsibility to the user by having
them sign a terms of service document upon account registration.
Also, I'm not sure that some issues can really be cleared; see below.
in the context of "this was pulled in automatically, there was no
human being who initiated that action, so there is nobody but
the site admins to be held responsible".
It's great to see more packages being maintained on salsa. I've certainly noticed that it is making working on packages much simpler.
In my campaign, I stated [os1] that I aimed to reduce the number of packages maintained outside Salsa to below 2,000. As of March 28, 2024, the count was 2,368. As of this writing, the count stands at 1,928
[os2], so I consider this promise fulfilled. My thanks go out to
everyone who contributed to this effort. Moving forward, I’d like to set
a more ambitious goal for the remainder of my term and hope we can
reduce the number to below 1,800.
Without seeking to rain on the parade, that query is only the packages that list a non-salsa VCS. That's not counting the packages that don't list a VCS at all and therefore are also maintained outside salsa:
please be careful in your efforts to make contributing easier to not alienate those who already contribute, sometimes for decades. also: it's rather easy to
kill motivation but very hard to revive it, once killed.
Dear Debian community,
this is bits from DPL for February.
Ftpmaster team is seeking for new team members ==============================================
In December, Scott Kitterman announced his retirement from the project.
I personally regret this, as I vividly remember his invaluable support
during the Debian Med sprint at the start of the COVID-19 pandemic. He
even took time off to ensure new packages cleared the queue in under 24 hours. I want to take this opportunity to personally thank Scott for his contributions during that sprint and for all his work in Debian.
With one fewer FTP assistant, I am concerned about the increased
workload on the remaining team. I encourage anyone in the Debian
community who is interested to consider reaching out to the FTP masters
about joining their team.
If you're wondering about the role of the FTP masters, I'd like to share
a fellow developer's perspective:
"My read on the FTP masters is:
- In truth, they are the heart of the project.
- They know it.
- They do a fantastic job."
I fully agree and see it as part of my role as DPL to ensure this
remains true for Debian's future.
If you're looking for a way to support Debian in a critical role where
many developers will deeply appreciate your work, consider reaching out
to the team. It's a great opportunity for any Debian Developer to
contribute to a key part of the project.
[1] https://ftp-master.debian.org/
Project Status: Six Months of Bug of the Day ============================================
In my Bits from the DPL talk at DebConf24[1], I announced the Tiny Tasks effort, which I intended to start with a Bug of the Day project[2].
Another idea was an Autopkgtest of the Day, but this has been postponed
due to limited time resources-I cannot run both projects in parallel.
The original goal was to provide small, time-bound examples for
newcomers. To put it bluntly: in terms of attracting new contributors,
it has been a failure so far. My offer to explain individual bug-fixing commits in detail, if needed, received no response, and despite my
efforts to encourage questions, none were asked.
However, the project has several positive aspects: experienced
developers actively exchange ideas, collaborate on fixing bugs, assess whether packages are worth fixing or should be removed, and work
together to find technical solutions for non-trivial problems.
So far, the project has been engaging and rewarding every day, bringing
new discoveries and challenges-not just technical, but also social. Fortunately, in the vast majority of cases, I receive positive responses
and appreciation from maintainers. Even in the few instances where help
was declined, it was encouraging to see that in two cases, maintainers
used the ping as motivation to work on their packages themselves. This reflects the dedication and high standards of maintainers, whose work is essential to the project's success.
I once used the metaphor that this project is like wandering through a
dark basement with a lone flashlight-exploring aimlessly and discovering
a wide variety of things that have accumulated over the years. Among
them are true marvels with popcon >10,000, ingenious tools, and
delightful games that I only recently learned about. There are also some packages whose time may have come to an end-but each of them reflects
the dedication and effort of those who maintained them, and that
deserves the utmost respect.
Leaving aside the challenge of attracting newcomers, what have we
achieved since August 1st last year?
* Fixed more than one package per day, typically addressing multiple bugs.
* Added and corrected numerous Homepage fields and watch files.
* The most frequently patched issue was "Fails To Cross-Build From Source"
(all including patches).
* Migrated several packages from cdbs/debhelper to dh.
* Rewrote many d/copyright files to DEP5 format and thoroughly reviewed them.
* Integrated all affected packages into Salsa and enabled Salsa CI.
* Approximately half of the packages were moved to appropriate teams,
while the rest are maintained within the Debian or Salvage teams.
* Regularly performed team uploads, ITS, NMUs, or QA uploads.
* Filed several RoQA bugs to propose package removals where appropriate.
* Reported multiple maintainers to the MIA team when necessary.
With some goodwill, you can see a slight impact on the trends.debian.net graphs[3] (thank you Lucas for the graphs), but I would never claim that
this project alone is responsible for the progress. What I have also
observed is the steady stream of daily uploads to the delayed queue[4], demonstrating the continuous efforts of many contributors. This ongoing
work often remains unseen by most-including myself, if not for my
regular check-ins on this list. I would like to extend my sincere thanks
to everyone pushing fixes there, contributing to the overall quality and progress of Debian's QA efforts.
If you examine the graphs for "Version Control System" and "VCS Hosting"
with the goodwill mentioned above, you might notice a positive trend
since mid-last year. The "Package Smells" category has also seen
reductions in several areas: "no git", "no DEP5 copyright", "compat <9",
and "not salsa". I'd also like to acknowledge the NMUers who have been working hard to address the "format != 3.0" issue. Thanks to all their efforts, this specific issue never surfaced in the Bug of the Day
effort, but their contributions deserve recognition here.
The experience I gathered in this project taught me a lot and inspired
me to some followup we should discuss at a Sprint at DebCamp this year.
Finally, if any newcomer finds this information interesting, I'd be
happy to slow down and patiently explain individual steps as needed. All
it takes is asking questions on the Matrix channel[5] to turn this into
a "teaching by example" session.
By the way, for newcomers who are interested, I used quite a few abbreviations-all of which are explained in the Debian Glossary[6].
[1] https://debconf24.debconf.org/talks/20-bits-from-the-dpl/
[2] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day
[3] https://trends.debian.net/
[4] https://ftp-master.debian.org/deferred.html
[5] https://app.element.io/#/room/#debian-tiny-tasks:matrix.org
[6] https://wiki.debian.org/Glossary
Sneak Peek at Upcoming Conferences
==================================
I will join two conferences in March-feel free to talk to me if you spot
me there.
1. FOSSASIA Summit 2025 (March 13-15, Bangkok, Thailand)
Schedule: https://eventyay.com/e/4c0e0c27/schedule
2. Chemnitzer Linux-Tage (March 22-23, Chemnitz, Germany)
Schedule: https://chemnitzer.linux-tage.de/2025/de/programm/vortraege
Both events will have a Debian booth-come say hi!
Kind regards
Andreas.
Hello everyone,
On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
Dear Debian community,
this is bits from DPL for February.
Ftpmaster team is seeking for new team members ==============================================
No, we are not.
Andreas asked us whether we would like a call for volunteers included in Bits. Multiple team members explicitly told him that we now would not
be a good time for that, for us.
For the FTP team,
--
Sean Whitton
On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
Dear Debian community,
this is bits from DPL for February.
Ftpmaster team is seeking for new team members
==============================================
No, we are not.
Andreas asked us whether we would like a call for volunteers included in Bits. Multiple team members explicitly told him that we now would not
be a good time for that, for us.
Do you mind clarifying why that's the case, unless the reason is truly personal or undisclosable?
On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote:
Do you mind clarifying why that's the case, unless the reason is truly
personal or undisclosable?
It's pretty simple -- there is no-one with the free time to train them
right now, in which case trainees will simply burn out, because they
won't get enough feedback on their NEW reviews.
Hello,
On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote:
Do you mind clarifying why that's the case, unless the reason is truly
personal or undisclosable?
It's pretty simple -- there is no-one with the free time to train them
right now, in which case trainees will simply burn out, because they
won't get enough feedback on their NEW reviews.
We try to recruit only when there is someone who is able to dedicate
some time to training. That depends on what the other team members are
busy with, in and outside of Debian, at a given time.
This was made very clear to Andreas.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:00:21 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,509 |