Hallo Andreas, (this should probably go to vote as general questions for the candiates, but I'm not having enought time right now to pursue this.)
On Thu, Mar 20, 2025 at 03:36:48PM +0100, Andreas Tille wrote:
> Hi Robert,
>
> Am Sat, Mar 15, 2025 at 04:34:09PM -0400 schrieb Roberto C. Sánchez:
> > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> > for a package?
>
> I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.
How do you define "*uncoordinated*" NMUs?
What makes it "not uncoordinated" in your view?
> > * Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
> > wishlist bugs for packaging a new upstream version, but care should
> > be taken to minimize the impact to the maintainer.) Fixing cosmetic
> > issues or changing the packaging style in NMUs is discouraged.
> >
> > I had thought of possibly suggesting an update to the documentation, but
> > I'm not sure that adding more words would make the matter any more
> > clear.
>
> 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?
Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.
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.
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.
The move to the debian namespace changes (semantics of) maintainership,
which is bad and *not the purpose of NMUs*
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.
So, do you agree that such fudamental changes to our procedure should
be discussed before? Do you think that the established rules should be
followed until then?
> > 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.)
>
> 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.
What changes would you think are necessary? How would you reform the MIA
procedures?
> 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?
Why do you think that you can invent an ITN without prior discussion?
> What do you think?
> Kind regards
> Andreas.
>
>
> [1] https://tracker.debian.org/pkg/pccts
> [2] https://bugs.debian.org/1100859
>
> --
> https://fam-tille.de
>
signature.asc
Description: PGP signature
