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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 339 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:14:03 |
| Calls: | 7,466 |
| Calls today: | 2 |
| Files: | 12,691 |
| Messages: | 5,627,862 |