This mail was sent as Message-ID: <
[email protected]> at
Date: Mon, 24 Mar 2025 17:15:10 +0100
but never reached the list. I'm sending from a different address now
I hope forwarding from my sent folder will not break the thread.
[Some people are in CC. If you wonder why just seek for your first name.]
Hi Tobias,
please let me say in advance that I highly appreciate your work in the
MIA team and on drafting and refining the ITS procedure. That's really
great work and its extremely helpful. Since I highly evaluate your
insight into these topics I'm happy about any comment of yours like the
mail I'm now answering here (while trying not to repeat what Otto wrote
in his response).
Am Sun, Mar 23, 2025 at 12:03:26PM +0100 schrieb Tobias Frost:
(this should probably go to vote as general questions for the candiates,
but I'm not having enought time right now to pursue this.)
I'm fine with answering on vote but I do not think that I should
actively move to this list. Anyone is kindly invited to quote me there
and ask specific questions.
On Thu, Mar 20, 2025 at 03:36:48PM +0100, Andreas Tille wrote:
I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.
How do you define "*uncoordinated*" NMUs?
For me uncoordinated means: Not informing the maintainer and giving a sufficient amount of time to respond.
What makes it "not uncoordinated" in your view?
Informing the maintainer by
1. Add the Maintainer ID in CC to every conversation
2. Follow the timing established in ITS procedure to enable
a sensible response time
I'd like to stir some constructive discussion about this-hopefully
leading to a procedure that is acceptable to everyone and can be
finalized for discussion at DebCamp.
Andreas, the this is the correct approach. First discuss changes and
then implement them when project consensus has been reached.
Do you agree on this principle on the how to work together in Debian?
I fully agree with this principle. At the same time, I think it's
important to acknowledge that, in practice, there have been cases-such
as NMUs adjusting source format to 3.0, Standards-Version updates,
debhelper compatibility level bumps, or migration from cdbs to dh-where
changes were made before a formal consensus was explicitly documented.
As we have discussed previously, NMUs have evolved beyond what is
currently reflected in the Developer's Reference, and I strongly support updating our documentation to clarify what is considered acceptable.
That said, I believe that practical experimentation can sometimes
provide valuable insights to initiate a well-informed discussion on
complex topics. In December, we had an initial exchange on this topic
[2], and I plan to prepare something for a more structured discussion at DebCamp. Mailing list discussions are valuable, but I think an in-person exchange may be more productive for refining our approach.
Of course, any such experiments should be well-communicated and remain harmless. In the case of migrating a package to a Salsa Git repository,
for example, the change is fully reversible-removing the Vcs fields is
all it takes to restore the previous state. The goal is not to impose
changes unilaterally but to explore practical steps that can lead to a
broader discussion based on existing cases.
We simply need to acknowledge that volunteer participation is fluid-some contributors may step away without explicitly announcing it. The MIA
team does an important job of identifying and reaching out to inactive maintainers, but this process naturally takes time. In the meantime, if
NMUs are difficult to apply, affected packages may remain blocked for
extended periods. This is not a shortcoming of the MIA team, but rather
an inherent challenge in a volunteer-driven project, where formal
transitions don't always happen in a predictable way.
Unfortunatly1 I have to ask this question, as this is not how you and (your|the) salvaging team is operating at the moment - IMHO.
We have addressed the concerns you raised about the use of the ITS
procedure in bug #1093192. In another bug report (#1094788), you
suggested using the NMU process to fix bugs. I consider the ITS
procedure to be well-crafted and highly appropriate in cases where a new
person is willing to take responsibility for maintaining a package.
The key question remains: What should be done with packages where no one
steps forward to take responsibility by adding themselves as Maintainer
or Uploader?
Please keep in mind that none of the participants in this discussion on debian-devel are directly affected by the problem at hand. There have
been valid arguments against using Salsa for certain packages-for
example, Wookey has expressed concerns, and his viewpoint is fully
respected. However, his packages are actively maintained and do not
appear as candidates for the kind of NMU we did in the examples you
named below.
The real issue is that the people participating in this discussion are,
by definition, highly responsive. They would never let an NMU warning
period pass without responding. However, the problem lies with those who
are unresponsive-those who do not reply even after being explicitly CCed
and given 21 days notice. This creates a situation where packages
remain stuck, even when a clear process for intervention exists.
I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.
This is only partly true. We continue to use the ITS procedure if (and
only if) someone volunteers to add themselves as an Uploader. You
pointed out a possible misinterpretation of the ITS procedure, and we
took that feedback into account.
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.
You actually picked a non-fitting example. The repository was moved to a
more accessible location for the package owner, but I did not perform
the NMU. While the intention was to send a coordination mail, Bastian
(in CC) was simply faster (thank you Bastian!) in proceeding with an
actual NMU. Please do not attribute to me something that I did not do.
Regarding the future of this package, there is an open bug requesting a
new upstream version. Given that this package has had only a single
upload in over ten years and is significantly outdated, I believe it is
in the interest of our users to package the latest upstream release and incorporate the changes already in Git[3]. If users encounter an
outdated package in Debian that has been stagnant for a decade, I wonder
where the priorities should lie. Either we acknowledge the state of such packages and take action, or we consider their removal from Debian. Of
course, informing the maintainer about these concerns is essential.
(Sebastian as owner of ddate in CC just in case.)
The move to the debian namespace changes (semantics of) maintainership,
which is bad and *not the purpose of NMUs*
I agree with your point in general, but I disagree that "maintainership"
is the right term for a package that is outdated, has open (partly RC)
bugs, and has seen only a single upload from the maintainer over ten
years ago. This seems to be a broader topic for discussion at DebCamp,
as I don't see much value in continuing this conversation here on
debian-devel.
The move to the debian namespace cannot be easily undone, as those repos
are protected and require an salsa admin to act on e.g for (re)moving
it.
Another upload, with the removal of the Vcs fields, would effectively
undo the move to Salsa from a package maintenance perspective. As far as
NMU rules are concerned, I would consider myself responsible for any
unintended consequences caused by my NMU and would take the necessary
actions to address them.
So, do you agree that such fudamental changes to our procedure should
be discussed before?
Yes, I agree that fundamental changes to our procedures should be
discussed beforehand. However, as I mentioned earlier, you've picked the
wrong example to make your point. I did not perform an NMU on that
package, and I would not have done so without prior coordination.
Do you think that the established rules should be
followed until then?
As I mentioned earlier, while our rules are generally very effective for
the vast majority of packages, there are cases where they don't fully
serve the best interests of our users. I believe these examples can be
valuable for constructive discussions. If you feel that any of my
actions before such a discussion have been harmful in any way, I am more
than willing to fix or revert them.
How do others suggest to handle this particular situation?
I support issuing a warning before performing an NMU. These NMUs should only apply to packages that have not been uploaded by their maintainer
for at least five years (more than two releases) and should meet
additional criteria, which I'd like to define together with your input.
If there is no response within 21 days (aligning with the ITS process timeline), an NMU to delayed=10 based on a repository on Salsa should be acceptable. The key rationale is to ensure that the history of NMUs is properly recorded.
The history of an NMU is recorded in the archives, this is the
canonical location.
Looking at nstream, currently in DELAYED/8, there is no bug report
against the package that you are NMUing, and there is no nmudiff filed against the project. And it also moves the repository to the debian and
many changes are not addressing (filed) bugs.
(IMHO this is not within the (current) NMU procedures we have.)
I wonder if you consider #1089721 (J�rg in CC of this mail) to be uncoordinated. The nmudiff you requested is actually the reason why
these packages should be moved to Salsa: There are complex changes
addressing several issues. These changes don't fit neatly into a
traditional nmudiff. It's the kind of work that requires Git to manage effectively. (I do not want to repeat what Otto said in [1])
And yes, I understand your point, and I appreciate you raising it.
You're right-this is not what we traditionally understand as an NMU. We
don't have a better name for it at the moment, but I hope we can work
together on developing a new process constructively.
The following example brought this to my mind: The package pccts[1] has been NMUed four times in a row, with the last maintainer upload dating
back to 2010.
I reported the maintainer to the MIA team, as this is their only package and I have seen no activity from them. So far, I have closed five bugs
and updated the packaging to the latest standards. However, there are
still unresolved issues, and I would like to invite others to contribute
to this effort. Maintaining the package in Git would be essential to continue this work effectively.
Do you think Debians approach to how being a member should be changed, especially in the light that there are inactive members.
You, as an active member of the MIA team (thank you for your volunteer
work!), know that tracking down inactive members is challenging.
However, I must admit that I see your question as somewhat unrelated to
the NMU process, as an NMU does not change the maintainership of a
package. I only mentioned the MIA process in my previous mail because,
when working on the package in question, it became clear that the MIA
team should be involved.
You might say, "Contact the MIA team first, wait for confirmation, and
act later." Are you concerned that the intended NMU process could
interfere with the MIA process?
What changes would you think are necessary? How would you reform the MIA procedures?
I believe this is a topic best discussed separately. At the moment, I
don't have any specific suggestions, but I would be interested in
hearing your thoughts on potential changes.
To address this, I opened a bug with the proposed warning[2]. What do
you think about this as a first experiment to determine what is
acceptable and what is not?
Why do you think the procedures we have for NMUs are not sufficient?
Thank you for the question which enables me to summarise:
1. It does not fit the situation where maintainers are clearly
inactive.
2. Some changes are sufficiently complex to warrant representation in
Git.
3. Some fixes for an NMU may benefit from the collaboration of
multiple contributors, which Git facilitates.
Why do you think that you can invent an ITN without prior discussion?
My aim was to experiment with a process that could stimulate a broader discussion on how we handle certain situations in Debian. I understand
that any changes to established procedures should be discussed, but
sometimes practical experimentation is necessary to explore ideas that
may not yet be fully articulated. I firmly believe that these types of experiments, when properly communicated and reversible, can be valuable
in generating sensible discussions about potential improvements.
Kind regards,
Andreas.
[1]
https://lists.debian.org/debian-devel/2025/03/msg00524.html
[2]
https://lists.debian.org/debian-devel/2024/12/msg00101.html
[3]
https://salsa.debian.org/debian/ddate
--
https://fam-tille.de
----- Ende weitergeleitete Nachricht -----
--
https://fam-tille.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)