Am Tue, Dec 03, 2024 at 01:49:33PM +0500 schrieb Andrey Rakhmatullin:

raise certain
barriers between the package and other people.

The current barrier appears to be the ITS procedure[1], which I now
engage with nearly daily through the "Bug of the Day"[2] workflow.
Previously, the requirement to wait 21+10 days (ITS waiting period +
delayed upload) deterred me from using this procedure. This delay
necessitates revisiting the issue multiple times and managing related
calendar entries, which can be burdensome. However, in the context of
"Bug of the Day", the regularity of the work has made it practical to
develop a workflow that accommodates these requirements, so it's now manageable.

In my experience, more than 50% of ITS requests receive no response from maintainers at any stage of the salvaging process. As a result, we have effectively raised barriers for cases where maintainers have stopped
caring about their packages and failed to communicate this before
stepping away.

I wonder if we should reconsider the default assumption of package
ownership. Instead, we could introduce a file, such as debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.

We could introduce this change starting with Debian Policy version X. Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the
absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

Do you think this would lower the barrier between a package and other
people?

Kind regards
Andreas.

[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Tille <andreas@an3as.eu> writes:

I wonder if we should reconsider the default assumption of package
ownership.

(This is a reas objective, but) i wasnt sure how the following text would achieve the above)

Instead, we could introduce a file, such as
debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.

Do you think this would lower the barrier between a package and other
people?

(I dont see why it would be any different than today -- people who write
the file can still lose interest/time and you will stil have to manage
your calendar).

Isnt the issue that debian's whole processes assume a "heroic"
maintainer who does all the work alone. That has advantages, but also disadvantages if the hero disappears.

Maybe start with: how does a company/other distros organise its coding
teams? are there perhaps some things debian could learn?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Dec 04, 2024 at 06:08:00PM +0100, Andreas Tille wrote:

I wonder if we should reconsider the default assumption of package
ownership. Instead, we could introduce a file, such as debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.

We could introduce this change starting with Debian Policy version X. Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

Do you think this would lower the barrier between a package and other
people?

This sounds like a basis for an actual solution but I don't think it can
work by itself, unless the timeframe is something like "you cannot touch
this in the next 2 weeks" and it's possible to refresh it without an
upload.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdRUc8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh AUQP/jaM/VMzeXx3z1R9DiYWa/o0pF8g5QgjhuvrT7285RmBodkpUS9p465wjyZW bsgd0aGgtGbhwxGAjO4CDjSsOuZMMVke4piBRNzQd46yJA5mRSvwBq0FqzYzjWmJ q1ZGhbVFNRfK3jB+aMfCP3lEe78mMYwVGZ23d/ghsl3j6IwiR4OhrxyVpTIgLBLb 3f1Klou02V7lkX2WPhdrZUUoqbP+oCqOSm8F8yD/AXu/DQu+aPxrxYobCkfz3uz/ H9+ZAaRKxprTdv+LjLB4oJf1I3KwbGFKH25U5Q+0D/kRjQY79V8FUFcNIX1NiJ4K X3Z9Xpke37CVufZLvZwqamEblSpiS5wpG7fO2L4FK0NXhD10R+HMOamFh5vy1YFs Ll7iXey2IzKRaGma6PvY7m/m9G6s4qKRbatOSr2/3oGmbGwGLHbyVgUBu9/v2TnE q8WOUSojiJ6NPFENrmroxMxjddg5hho2jfoZqtgaFvLG8ivq+EsgggPOcaK+cjZT rx58WHOCCjKymgPHNl0Mmk8B8eF30lqx2B6FoohS6/dSega6NaUe7LGjJkqTFNT9 26ao+YjU3iMoLNEVEUjVWyjl79W+3T8mWHp3DCd3beYCLNh9W8xBzha0a/9PJMSD y5SqknZnkjwUVkh0HncnSElEdJmmXpYyvJ6o0f5YUTW2v+sE
=bKVr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0cdGaQVKkmeiK1HC800YV0wR
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMDQuMTIuMjQgMTg6MDgsIEFuZHJlYXMgVGlsbGUgd3JvdGU6DQo+IGluIHRoZQ0KPiBh YnNlbmNlIG9mIGEgZGViaWFuL2RvbnRfdG91Y2hfbXlfcGFja2FnZSBmaWxlLCBhbnkgRGVi aWFuIERldmVsb3BlciBpcw0KPiBwZXJtaXR0ZWQgdG8gdXBsb2FkIHRoZSBwYWNrYWdlLg0K DQpJIGxpa2UgdGhpcyBpZGVhLg0KDQpUaGUgbmV4dCBzdGVwOiBhZ3JlZSBvbiBhICJzdGFu ZGFyZCIgRGViaWFuIHdvcmtmbG93IGFuZCBhbGxvdyANCihlbmNvdXJhZ2U/KSBwZW9wbGUg dG8gY29udmVydCBleGlzdGluZyBwYWNrYWdlcyB0byBpdCAoYXNzdW1pbmcgdGhhdCANCnRo ZSBkb24ndCB0b3VjaCB0YWcgZmlsZSBpcyBhYnNlbnQpID8NCg0KLS0gDQotLSByZWdhcmRz DQotLSANCi0tIE1hdHRoaWFzIFVybGljaHMNCg0K

--------------0cdGaQVKkmeiK1HC800YV0wR--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmdal4YFAwAAAAAACgkQcs+OXiW0wpOr RhAApnteeW+duMB/eIeELM3RyAKBrZ2zlU9N0tP8Dnx5p5bmurxLLZ6VcEtZOIKrA3Tt5fkhQrJB ABg4aiVLYaU8EfYxlr3DhcN3bh6brNMQ7r0/lUE2P1D3hf0wWcsDo6WOvaufF87Nnghl5P2U9csh 9FJ5PKvp8cymeYYl7nVS80hhY8IpV/0xbaL22jjn3D1Z+ly/gr2LU1ZwFS0n6IaMRR15gnUowpx+ 54K63hRm/qr5CrzA7Yvu/uXNd5ju+MFG5ZX2+/rpQHebvvkmrKMQXqGfA/0H38ns7CdP8ZbgqTTy bMr7nIjXv/I/APxKJ//fvEAO22Di7QYnLqsGOA68Bif0u6/OJw92JCbGycaJrYr5sZJrtBe7/7ac m3NpJug3PwEkMXCvtzM4gNpzj+mq4IE/v4U7IuEIUPpv/tQM/d466k2zX8ZfCQxEln7ceivrO22i xyeectxRccOiZGwbmkp9tZTvS/XlUglcxC455bitV80Z8ipp7q1rsd0RYUu++B5z5p4hL0d956II n1VtmWLVkB5lBy+lkaJ5XDiorlqvCm7y81dVNqWh2QmfEeGPkcGQLGGoiEv0DdE/JDCXica0p8Z4 4jCmNyr1LzCzn0tXzJmaPDVgRZjI/ERXP83PRHyiSoUpO2XTHDC3T7hWOzvD+VO4pwiu4oG+KL5r 8n4=
=h0zW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Matthias Urlichs (2024-12-12 08:57:57)

On 04.12.24 18:08, Andreas Tille wrote:

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

I like this idea.

The next step: agree on a "standard" Debian workflow and allow
(encourage?) people to convert existing packages to it (assuming that
the don't touch tag file is absent) ?

Uhm, maybe that is implied by "next step", but just to be clear:

The proposal was to switch anyone-can-upload from opt-in to opt-out,
right?

Currently we have opt-in of anyone-can-upload for packages in the
collaborative debian section of salsa, but that does not imply that
anyone can do major restructuring of a package, which changes to
packaging workflow is.

Whichever step includes the new more aggressive attitude of permitting
major changes to a package without collaboration (or phrased nicer: with
only a system-wide "collaboration" of a standardization regime), please
state such evelation explicitly, so that when discussing we all agree on
what we are in fact discussing.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/12/24 18:08, Andreas Tille wrote:

We could introduce this change starting with Debian Policy version X. Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

Hi,

an alternative that I was thinking of, is making this "everybody is
onboard" policy more explicit by having a special email to use for the Maintainer field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it
currently happens with team-maintained packages.

Lintian would then raise an error (not overridable for uploads) if the Maintainer field is not set to a @{lists,tracker}.debian.org email AND debian/dont_touch_my_package is not present with some text in it.

This would mimic what some maintainers are already doing today:
orphaning a package (i.e., setting its Maintainer address to packages@qa.debian.org), moving themselves to the Uploaders field and
then carrying on maintaining the package as part of the "QA Team"
(everybody is part of the QA Team...).

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 12, 2024 at 09:36:01AM +0100, Jonas Smedegaard wrote:

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

I like this idea.

The next step: agree on a "standard" Debian workflow and allow (encourage?) people to convert existing packages to it (assuming that
the don't touch tag file is absent) ?

Uhm, maybe that is implied by "next step", but just to be clear:

The proposal was to switch anyone-can-upload from opt-in to opt-out,
right?

Currently we have opt-in of anyone-can-upload for packages in the collaborative debian section of salsa

(Which, to my knowledge, is not codified anywhere except some wiki page,
so it looks debatable to me how true is this)

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdaqTAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 7mEP/3qONJFfgmD29WechOk/RNPbc84gRiGt19f3nsPaZUzUzbap0hcxsxOG9S/X 6xQywDwP+inhLY2eRSTfm6PUv0+bQ4v1OG8j11RkftZTnm89FmZa8Y/v+ylyeIkr znf9Ss07fIHClQN8IMJcuDjqCkvdfRx5Lil31TZ/PX53fZ63lQ+dA/MYyEYgZwuR eOlM4T1qH4U+Olly4HEN73balq7GfuvAo/GArnDQg4nZUkoMDpFPL0tHnX/tH3mG TW/B1Cfaoj78IJ1p6FD0HX5CVPLzaEofT+uFMJX6ZIp6jclH3snq5j4mOp65EYlc h7lTDYhGYqMHjfb8n6UtC217O43t09O1WwMCMFJT4r/K4Lgz5f51zsf8w1dlskqS eBNYIQlP0IxPWwLtkYu56TlvJSORJT7R/okh5nWVMD7FReyUZX0Q1dJh13j6AILB 8pa8Q32hZdmGNdss6EHGZs3hg2WVDtl0IidoeYB7192XEGvr7SKLTYcc5p9yI8BB BAns8244pbnu8dQK2RrC0bLSkl65t5kZyRl/d+eBZNFaJfje+YhYfTNGV/K+ABjs tZ3HetIp+MsXznNkDqRDmYjD2G/JG+LrTJcAErhJMZwfbwene7H9lKqv0X+VExWh m7iT7z7Oc7c50PuQfu7NljbR9y4EK9PNI58Ag4arKJJcGwrE
=vbPC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:

On 04.12.24 18:08, Andreas Tille wrote:

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.

I like this idea.

so you like reality. good.



--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Reporter: You're the first person ever to win two Olympic tennis gold medals. That's an extraordinary feat, isn't it?
Andy Murray: I think Venus and Serena have won about four each.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmdazacACgkQCRq4Vgaa qhwaKg/9H+IlH87mkdf9Rana6mdvlGAEbK0bMmQYcVVijMiDZXciT+mK2g5PK9tF N73yHra/43ZrPe1/8dmIsXlV9U+qYSTch84/t2PKhftT2rkoXkMzOv72mwqjCxmr IwJSA2ZmfD3+7DCU/5I1xCq0sc15pI743QJFCAzc+tqG6luLU70Ltuc/JxKLX7Ed G/rLKyeS24eMg7oNPIAnHDgie3RugXAC8z55yCx8M1onrBcjFgrN4AVpZmkN4rba aWUA6SjEtr6wPjfzKjZb63rpxprmj003AYiwrNUCWIWQcc1DIOv8/zpkcNWiD5OH ivvP3qBhjXb7T9pagrxKgJLHIF1KvxLwZQQyNEJZ2Z4pvI9AZqKFRwn3LsCK8pwl QZnl7nPTmVFoizP5ky6mz2Z3XEvw/l8vKent7N0bLr9nfYBU0+25xCIY+mcZhWjJ WfshxWA0hE47/FYdEe0Z+kQLmgTcATgRKNzX6EOk5qpaL8cjv4lQ/O983VDtP

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Ua6g0VuJTDrCYkVu8aNJCDF9
Content-Type: multipart/alternative;
boundary="------------2GKo0ikK03yI4NnI5omxlK0l"

--------------2GKo0ikK03yI4NnI5omxlK0l
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTIuMTIuMjQgMTI6NDgsIEhvbGdlciBMZXZzZW4gd3JvdGU6DQo+IE9uIFRodSwgRGVj IDEyLCAyMDI0IGF0IDA4OjU3OjU3QU0gKzAxMDAsIE1hdHRoaWFzIFVybGljaHMgd3JvdGU6 DQo+PiBPbiAwNC4xMi4yNCAxODowOCwgQW5kcmVhcyBUaWxsZSB3cm90ZToNCj4+PiBpbiB0 aGUNCj4+PiBhYnNlbmNlIG9mIGEgZGViaWFuL2RvbnRfdG91Y2hfbXlfcGFja2FnZSBmaWxl LCBhbnkgRGViaWFuIERldmVsb3BlciBpcw0KPj4+IHBlcm1pdHRlZCB0byB1cGxvYWQgdGhl IHBhY2thZ2UuDQo+PiBJIGxpa2UgdGhpcyBpZGVhLg0KPiBzbyB5b3UgbGlrZSByZWFsaXR5 LiBnb29kLg0KPg0KRGlkIHlvdSBldmVyIHNlZSBhIGJ1ZyAob3IgcmVxdWlyZSBhIGZlYXR1 cmUpLCBmaXgvYWRkIGl0LCB1cGxvYWQgdG8gDQp1bnN0YWJsZSwgYW5kIGltbWVkaWF0ZWx5 IGdvdCByZXZlcnRlZCBiZWNhdXNlIHRoZSBtYWludGFpbmVyIGJhc2ljYWxseSANCmRpZG4n dCBsaWtlIGl0PyAoQXNzdW1lIGZvciB0aGUgc2FrZSBvZiBkaXNjdXNzaW9uIHRoYXQgdGhl IGlzc3VlIGluIA0KcXVlc3Rpb24gaXMgb2xkZXIgdGhhbiBhIG1vbnRoIG9yIHNvLCBhbmQg aGFzIG5vdCBnb3R0ZW4gYW55IGZlZWRiYWNrIG9uIA0KdGhlIGJ1ZyB0cmFja2VyLikNCg0K Tm8/DQoNCkx1Y2t5IHlvdSwgdGhlbi4NCg0KLS0gDQotLSByZWdhcmRzDQotLSANCi0tIE1h dHRoaWFzIFVybGljaHMNCg0K
--------------2GKo0ikK03yI4NnI5omxlK0l
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12.12.24 12:48, Holger Levsen wrote:<br>
</div>
<blockquote type="cite" cite="mid:Z1rNpyc9Msw9EUgX@layer-acht.org">
<pre class="moz-quote-pre" wrap=""><pre wrap=""
class="moz-quote-pre">On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
class="moz-quote-pre">On 04.12.24 18:08, Andreas Tille wrote: </pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
class="moz-quote-pre">in the
absence of a debian/dont_touch_my_package file, any Debian Developer is permitted to upload the package.
</pre></blockquote><pre wrap="" class="moz-quote-pre">I like this idea. </pre></blockquote><pre wrap="" class="moz-quote-pre">so you like reality. good.

</pre></pre>
</blockquote>
<p>Did you ever see a bug (or require a feature), fix/add it, upload
to unstable, and immediately got reverted because the maintainer
basically didn't like it? (Assume for the sake of discussion that
the issue in question is older than a month or so, and has not
gotten any feedback on the bug tracker.)<br>
</p>
<p>No?</p>
<p>Lucky you, then.</p>
<pre class="moz-signature" cols="72">--
-- regards
--
-- Matthias Urlichs</pre>
</body>
</html>

--------------2GKo0ikK03yI4NnI5omxlK0l--

--------------Ua6g0VuJTDrCYkVu8aNJCDF9--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmdeajAFAwAAAAAACgkQcs+OXiW0wpN0 vRAArLKgU/iJxPAWqA0S+9D1xUxDwSCn75Q98a4aN9mXDyyDfWW7gS4V4BiiexDz8O9Ce8sWqpEo IaZ98BHJFM0r9OBDE2lb59udipSRnal74OGrtfKNcJYQqCrKCrozp9VG++VzorIGNSjljwFT7Na1 W29PUFyl+S1hZtcdcjhxtrMRaY0dWwas8nDnobyJTjIZXyT15pMDoZp40fawbI3PxIhor17MPILe M3jxaW0lLLi6eLWG4oyZL8+QWYKcCmLJIjILgZYCZiQSz3Rs9SOXYULqVbz8TwmpHxBhnOELqoOg hp/UtMJG6NPFv7YSw69mS9utqrjjCutlW4g4oOR2fhE1FwpYNCvKiJnSyKLEhTcFN3N0RNeYm/Lb bcv5zdgZLgmXyEzCjh5QxjMPjWA24L7g1OBm/c9V+NdNorjbo9vZnw4rlznPDNfv7E+jKQ51idDW R9HJmiaMUx38Bcq5wON6iiixMRM13muV46bDz12NKCeeqWEzchANO6JpDtIqReI99dSw9KrJ9fI8 j0V1nXpxcNpLEkRujnGANzGdgK9+dlEn4w0LqkNlRam2oiRvqKA/+ZszB3Shyij9s8YOyxreq3GM /hBOeK7pf88gKQjvfhuKFarSq/IrLoiSV9eJ5Mb2zhGevyufR13u7V0JOD8DGOR8chAmBvawDrIL aMU=
=7gPR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05

Hi Matthias,

Quoting Matthias Urlichs (2024-12-15 06:33:35)

On 12.12.24 12:48, Holger Levsen wrote:

On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:

On 04.12.24 18:08, Andreas Tille wrote:

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is >>> permitted to upload the package.

I like this idea.

so you like reality. good.

Did you ever see a bug (or require a feature), fix/add it, upload to unstable, and immediately got reverted because the maintainer basically didn't like it? (Assume for the sake of discussion that the issue in question is older than a month or so, and has not gotten any feedback on
the bug tracker.)

If you mean making an NMU that I felt so confident about that I released
it *without* prior warning in a bugreport - e.g. because I interpreted
older conversations in a bugreport as being in support of my (surprise)
move? Yes, I have experienced that, and after dusting off my immediate
reaction of self-rightousness, I felt foolish that I hadn't spent just a minimal time probing ahead, instead of assuming that silence was in
indication of negligence.

If you mean first informing, then issuing an NMU, and then getting
reversal, then I cannot remember such incident - do you call that luck?
Do you mean to imply that overly silent maintainers are generally non-cooperative, or what are you trying to say with your remark - which
I have trouble reading other than snarky (and I apologize ahead for
that, which in good faith gotta be a misreading).

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Thu 12 Dec 2024 at 08:57am +01, Matthias Urlichs wrote:

On 04.12.24 18:08, Andreas Tille wrote:

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.

The next step: agree on a "standard" Debian workflow and allow (encourage?) people to convert existing packages to it (assuming that the don't touch tag file is absent) ?

Let's discuss just one of these two highly controversial changes at
once.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdmI/4ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQNxpD/4yZ7DmUYUPkqo1gXdZAI72 FdcmHSdYzS7t32xPmTZelQiKZnyNL0Dk2TV64O5aaBKYc/I/g0/1eWdgaP6UBKHj jGNtZpcJxCAFzTCXx/JrAwB1p4hAaxnOpIre1kBAFuR6zHfSa3epS2YWNVyRNt26 jvDOE8Z5YR75WeRMcKzovVwCkAQFOaJcVya3BZYiiMDOaVirwKgBZBCHcqzVhqk6 7VjTIFjL/VUiT0oEhixhGOTjadFozn54+XqZobRmpXrUMCOhQiVqnrvRvpR0MtWT oD1ZUXqH8qB4JdjF6mZ+Z7NW9Y6J2kly659e4QHapGif/8aFjsd21GikoZBr9GPL bJ5iptuJeIw5qVreI+KEvpzuQxtpHqiaaacXa8CIexfxnw8LKpAgJYTzYfakSx3d NwX9OnUAXW2nX7WcH87Dm6VEMG7MeRD9AR+8OMg6utDnrM0p+QNCgl5KS6Gmlg/0 Ddzz4U03GYwhjJeqFTOVmhnyY9D5bEVvZHz85S7eAfZ0ynl7dG50k3rQXGImKsZa ULd2DlMnK1G1xLqRF4AHcLsBgjS0sDoS/6t41vpQIM8dwusg5Ddmrz6o3e8hXonU tTGQZc5owVCANXk4tFEkp24fbqcl8/fVXcwrjrk41IN/rYXT2L5aG0g7202wBqbs J2euA4rdVmh55OIcJnWJCQ=▄RY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usen

Hello,

On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:

an alternative that I was thinking of, is making this "everybody is onboard" policy more explicit by having a special email to use for the Maintainer field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it currently happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:

Maintainer: Debian developers <debian-devel@lists.debian.org>

Maintainer: Debian contributors <debian-devel@lists.debian.org>

(lowercase 'd' deliberate)

We could replace the LowNMU wiki list with this, right now.

It's the same as "Debian QA team" but it signals active maintainance by
at least one of the named uploaders.

We could do this independently of any other ideas about
dont_touch_my_package. Incremental steps.

Who's with me?

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdmI+sZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQOCsD/9dKST3h8HziJAw1cfrBEIz AbTOcNDfYJ9xeiXprV2511x9tV8RJpX9FdFnMECTG3eO1tNj9rjmTs8XMKieZ03u 0/8SDA1yRyNxoBzpB8YhbIcoW7RpnmbJhaIsaz2Xgse1kvahfwEcTwi/Y8Y5wQ8K BpgM9tB+hVD9ksamJW5uqzLrDxa4+mm4buR/Aknlcx9xchY1E0/L/2TtnPNk+U+A 8Fkc7e0mD+QUAZXCF1S3yGBWuSmA9Hw/1f/xIp3geppa7EETMYGGE7P2OyknlPic J7c9MaCkKzzb8A0oT2w7xuiDWSeD4SlVmdjjghBUe0bHf4hFIWT6cbeKRRsX7vDr P+xPimW9bKw8i5lKfez9BLD8ZQF5opP+BcY7qlWz6UIdV8TtjtY/0jAi1xzkg8dm Qo/dmb0GfXNCwHwO5PG7Do+fD0jAWPTYJ7myOQ9t84oc2dr3olKGRDGnBAU6mRQR OrrVAYXYopng7QeNHf8yIyZwosvcvDx6GcrGhjE6Hhn3IEmYVOw5xJOL46uBS/po seuKbOqg8wQm0X1LJiCXtKtPqQVot/XUv5NuFHPy8YbZ1LvS6b4vzGRxAF+XUryy gkQEweM5TWMig/F8uRX/JS1W2RUImNofTnyjExzMxMCgkfWnsgq0jkTjOzvNCBs9 Eefn+anwxqTjDMCyVCBQNg==HyN3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On 21/12/24 03:11, Sean Whitton wrote:

an alternative that I was thinking of, is making this "everybody is onboard" >> policy more explicit by having a special email to use for the Maintainer
field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it currently
happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:

Maintainer: Debian developers <debian-devel@lists.debian.org>

Maintainer: Debian contributors <debian-devel@lists.debian.org>

(lowercase 'd' deliberate)

We could replace the LowNMU wiki list with this, right now.

That would be great!

Wouldn't this however require instructing reportbug and BTS not to send
bug reports to debian-devel@?

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sean,

Am Sat, Dec 21, 2024 at 10:11:55AM +0800 schrieb Sean Whitton:

We don't need new vocabulary and a new mailing list for this.
Let's use:

Maintainer: Debian developers <debian-devel@lists.debian.org>

Maintainer: Debian contributors <debian-devel@lists.debian.org>

(lowercase 'd' deliberate)

I really like this suggestion in principle. The only drawback might be
that this mailing list will become quite heavy volume due to receiving
lots ot bug reports. While it might be easy to deal with by using
procmail or other tools there might be people who do not like it.

We could replace the LowNMU wiki list with this, right now.

It's the same as "Debian QA team" but it signals active maintainance by
at least one of the named uploaders.

+1

We could do this independently of any other ideas about dont_touch_my_package. Incremental steps.

Who's with me?

I'm with you with the small doubt about a heavy volume list which might
scare away people who want to discuss development issues as we do now.

Thank you for this suggestion
Andreas.

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gioele Barabucci <gioele@svario.it> writes:

Hi,

an alternative that I was thinking of, is making this "everybody is
onboard" policy more explicit by having a special email to use for the Maintainer field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it
currently happens with team-maintained packages.

Lintian would then raise an error (not overridable for uploads) if the Maintainer field is not set to a @{lists,tracker}.debian.org email AND debian/dont_touch_my_package is not present with some text in it.

This would mimic what some maintainers are already doing today:
orphaning a package (i.e., setting its Maintainer address to packages@qa.debian.org), moving themselves to the Uploaders field and
then carrying on maintaining the package as part of the "QA Team"
(everybody is part of the QA Team...).

I like universally maintained packages, the collaborate athmosphere in
the Go team has been a nice change of working on packaging for me, and
it seems there are other groups in Debian that work like that too.

I've long though about changing maintainer to QA for my packages like
you suggest, but there has been at least on reason I haven't done so:
lack of clear effective written down team policy in what the conventions
are. I don't know what the packaging and upload policies are for
'Maintainer: Debian QA Team'. It seems some people orphan their
packages to use the QA team, which I find a strange approach.

The https://go-team.pages.debian.net/ pages may have some flaws, but one
key social function is that it establishes the group as a team effort.
That goal is something to take after. I'm trying migrate my pkg-auth-maintainers packages to pkg-security just because https://wiki.debian.org/Teams/pkg-security establish the same social
function, that we never managed to create within pkg-auth-maintainers.

I'm now learning Python team conventions -- https://wiki.debian.org/Python/LibraryStyleGuide -- too, and find
similar elements.

These policies are mutually incompatible and each is opinonated about
its own technical choices, but I find adapting to a set of consistency
rules helps collaborative work, regardless of what those technical
choices are.

So what I'm trying to say is: I'm +1 on using a "global" Debian
developer Maintainer: field as a way of signalling that the people
working on that package are open for any developer to make changes to
the Salsa git repository and make package uploads, as a way to help the
package forward -- but that this messaging is combined with some written
down conventions that may evolve over time. Referring to the DEP
standards may be sufficient for now. I see problems with GitLab but
today I don't really see any alternative to using salsa.debian.org for
all such joint development work. Having packaging on Salsa and
accepting contributions via Salsa is desirable. That doesn't mean you
cannot have it elsewhere too, even a master git repository, but the
social function of having packages available for contributions on Salsa
is a good one.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2Z+UhQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFotHsAQD4JYHOwsx7oWrqEUpmiyH9IQG6J4PZ PoQP5VAm+jyipAEAmyYJpvBu0ZDs9S/vxpswkbDOHFEU91666OJfg3hdOgY=wc4Y
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:

On 21/12/24 03:11, Sean Whitton wrote:

an alternative that I was thinking of, is making this "everybody is onboard"
policy more explicit by having a special email to use for the Maintainer >>> field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it currently >>> happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:
Maintainer: Debian developers <debian-devel@lists.debian.org>
Maintainer: Debian contributors <debian-devel@lists.debian.org>
(lowercase 'd' deliberate)
We could replace the LowNMU wiki list with this, right now.

That would be great!

Wouldn't this however require instructing reportbug and BTS not to send bug reports to debian-devel@?

Hmm. I wouldn't mind the bug reports hitting -devel; it doesn't seem
any different from all the ITPs?

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 21 décembre 2024 10:15:35 GMT+01:00, Pirate Praveen <praveen@onenetbeyond.org> a écrit :

Please don't. We did the opposite for javascript team, we created a dedicated discussion list since the volume of mails were too huge, go and ruby teams do this too. All accepted, processed mails come to this list.

+1

We did the same for the Qt/KDE team.


--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 21, 2024 at 10:11:55AM +0800, Sean Whitton wrote:

Hello,

On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:

an alternative that I was thinking of, is making this "everybody is onboard"
policy more explicit by having a special email to use for the Maintainer field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it currently happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:

Maintainer: Debian developers <debian-devel@lists.debian.org>

Maintainer: Debian contributors <debian-devel@lists.debian.org>

(lowercase 'd' deliberate)

We could replace the LowNMU wiki list with this, right now.

It's the same as "Debian QA team" but it signals active maintainance by
at least one of the named uploaders.

We could do this independently of any other ideas about dont_touch_my_package. Incremental steps.

Who's with me?

We DO already have the debian namespace on salsa, everything in this
namespace is "team maintained by everyone.", so putting the package
there already declares that.

(Of course, this is orthogonal to a discussion where e.g bug reports
for the debian-namespace packages should be mailed too.)

--
tobi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 21, 2024 at 02:09:28PM +0100, Gioele Barabucci wrote:

On 21/12/24 10:15, Pirate Praveen wrote:

We could use collab maint list, which was specifically created for this https://wiki.debian.org/CollaborativeMaintenance

Good idea.

To sum up all suggestions until now:

Some packages will be maintained in a default-open way and outside a
specific team, with an ethos similar to that of https://wiki.debian.org/LowThresholdNmu (= feel free to fix bugs and imperfections, but talk with the others before big changes).

Technical aspects:

* Maintainer: Debian contributors <collab-maint-devel@lists.debian.org> [1]
* Uploaders: the DD and DMs that have more experience with this package (but not "responsible")

The "not responsible" part... IMHO The people in Uploaders should feel responsible for the package, otherwise noone will be feeling reponsible,
and then the package is just like an orphaned package pretendig to be maintained. (This is some life experience out of MIA work.)

* The Git repo will live under https://salsa.debian.org/debian/
* Changelog entries will start with "Team upload"

The packaging layout and workflow are open questions. And perhaps they are best left open for the foreseeable future. For the moment, let the first packager decide; changes can be done later after discussion with others who participate.

What is needed to make this a reality:

* Some sort of consensus (but not much, given that this is a fully voluntary effort).
* A new mailing list [1].
* Maybe lintian must be somehow adapted?
* Maybe tracker.d.o and DDPO should explicitly know about this?

[1] The collab-maint-devel@alioth-lists.debian.net referred by https://wiki.debian.org/CollaborativeMaintenance no longer exists (or it never existed), so a new one is needed to avoid flooding d-devel@.

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On ശ, ഡിസം 21 2024 at 04:44:01 വൈകു +08:00:00
+08:00:00, Sean Whitton <spwhitton@spwhitton.name> wrote:

Hello,

On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:

On 21/12/24 03:11, Sean Whitton wrote:

an alternative that I was thinking of, is making this "everybody
is onboard"
policy more explicit by having a special email to use for the
Maintainer
field. For example:

Maintainer: Debian community
<debian-community@lists.debian.org
<mailto:debian-community@lists.debian.org>>

The stewards of the package could be listed as Uploaders, as it
currently
happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:
Maintainer: Debian developers <debian-devel@lists.debian.org
<mailto:debian-devel@lists.debian.org>>
Maintainer: Debian contributors
<debian-devel@lists.debian.org
<mailto:debian-devel@lists.debian.org>>
(lowercase 'd' deliberate)
We could replace the LowNMU wiki list with this, right now.

That would be great!

Wouldn't this however require instructing reportbug and BTS not to
send bug
reports to debian-devel@?

Hmm. I wouldn't mind the bug reports hitting -devel; it doesn't seem
any different from all the ITPs?

Please don't. We did the opposite for javascript team, we created a
dedicated discussion list since the volume of mails were too huge, go
and ruby teams do this too. All accepted, processed mails come to this
list.

We could use collab maint list, which was specifically created for this https://wiki.debian.org/CollaborativeMaintenance

--
Sean Whitton

<div id="geary-body" dir="auto"><div><br></div></div><div id="geary-quote" dir="auto"><br>On ശ, ഡിസം 21 2024 at 04:44:01 വൈകു +08:00:00 +08:00:00, Sean Whitton &lt;spwhitton@spwhitton.name&gt; wrote:<br><blockquote type="cite"><div
class="plaintext" style="white-space: break-spaces;">Hello,

On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:

<blockquote> On 21/12/24 03:11, Sean Whitton wrote:
<blockquote><blockquote> an alternative that I was thinking of, is making this "everybody is onboard"
policy more explicit by having a special email to use for the Maintainer
field. For example:

Maintainer: Debian community &lt;<a href="mailto:debian-community@lists.debian.org">debian-community@lists.debian.org</a>&gt;

The stewards of the package could be listed as Uploaders, as it currently
happens with team-maintained packages.
</blockquote> We don't need new vocabulary and a new mailing list for this.
Let's use:
Maintainer: Debian developers &lt;<a href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>&gt;
Maintainer: Debian contributors &lt;<a href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>&gt;
(lowercase 'd' deliberate)
We could replace the LowNMU wiki list with this, right now.
</blockquote>
That would be great!

Wouldn't this however require instructing reportbug and BTS not to send bug
reports to debian-devel@?
</blockquote>
Hmm. I wouldn't mind the bug reports hitting -devel; it doesn't seem
any different from all the ITPs?</div></blockquote><span style="white-space-collapse: break-spaces;"><div><span style="white-space-collapse: break-spaces;"><br></span></div>Please don't. We did the opposite for javascript team, we created a dedicated
discussion list since the volume of mails were too huge, go and ruby teams do this too. All accepted, processed mails come to this list.</span><div><span style="white-space-collapse: break-spaces;"><br></span></div><div><span style="white-space-collapse:
break-spaces;">We could use collab maint list, which was specifically created for this https://wiki.debian.org/CollaborativeMaintenance</span><br><blockquote type="cite"><div class="plaintext" style="white-space: break-spaces;">
<div>--
</div>Sean Whitton

</div></blockquote></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Em 20 de dezembro de 2024 23:11:55 GMT-03:00, Sean Whitton <spwhitton@spwhitton.name> escreveu:

Hello,

On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:

an alternative that I was thinking of, is making this "everybody is onboard" >> policy more explicit by having a special email to use for the Maintainer
field. For example:

Maintainer: Debian community <debian-community@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it currently
happens with team-maintained packages.

We don't need new vocabulary and a new mailing list for this.
Let's use:

Maintainer: Debian developers <debian-devel@lists.debian.org>

Maintainer: Debian contributors <debian-devel@lists.debian.org>

(lowercase 'd' deliberate)

We could replace the LowNMU wiki list with this, right now.

It's the same as "Debian QA team" but it signals active maintainance by
at least one of the named uploaders.

We could do this independently of any other ideas about >dont_touch_my_package. Incremental steps.

Who's with me?

<3

I like this idea, and will apply it for e.g. grep and bzip2.

Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:

On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:

We DO already have the debian namespace on salsa, everything in this namespace is "team maintained by everyone.",

Is that so? I know that I agree that anybody can commit to my
repositories that are in Salsa's debian namespace, but I actually like
it when people commit to branches and leave the branches that are
released from to myself, and I also expect that I am at least asked (informed) before somebody uploads from one of "my" repos inside the
Debian namespace.

so putting the package there already declares that.

I surely hope that is not true. I'd have to move my packages so a
different place then.

From https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:

The debian group is for CollaborativeMaintenance (the old collab-maint
on Alioth).

The group is accessible to all Debian developers upon linking their
SSO Account, and are granted Maintainer access levels. Direct commits
to repositories in the Debian group by any Debian developer are
implicitly welcome. No pre-commit coordination (e.g. merge-request or
mail) is expected.

J.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmdm9KQACgkQKYasCr3x BA2PyBAAsINIbdqeqJBw9sWEVh397jYZCsCdWOK4+41E2BD8wYkmNrlIJ+bZ6tkS aNisq8sExoDWEwiKqKtuuWRU6WLPzjS949magitzcl4hidqoBM0+7aLHTitYkpBr zgAhFSvxG6pMISlFw2NErMRqREbEHkcB8ozflac6pYTC0/iYgDWGiwUPRk8BVn1v EhtwhWHSuPlo44Vh46UAXFKkM0xRaxiFhV17HRFAe/B45TuUm5cnrGHnLOvyRP/j zm9EUOV/GiELCkMvtEIq+J8RAvuDrjK0obIFbGyovOI7z1WLfDyuPboVsJcJxXeJ 1MACzDR4hI+faTB/OJ+mJdQUhM9DzLehb0jXy+oX0GweTw0wEQRU1yBHieav8XJq C0QVMeF+qN75GlEaDodIqVdnOnPi/etilsZSvKCffeBVubphs93h9RKSakcRYUko xsQZjondSN6o3Lz1GfdRzU83zcGUztwrINfmMdisE0uyMpq8BQd4f0XaEldMngl3 OLOier9uhy9Kqi+jFgQP7uffLegi90+bSkLpZdJ7nBP/BTFBFvBo3DVSH6o7IInx C3ccHLYbJ26qWH9BHjrQfG9W3OyuGh56OFhz4VjcrH6ob++YXshwY1PwN4l0hS/L iW1lVIrMiSceiGyEcwK5v05wdJXZQniyOZUMfY9HFhGrgfhzRls=
=7iED
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost <tobi@debian.org>
wrote:

We DO already have the debian namespace on salsa, everything in this >namespace is "team maintained by everyone.",

Is that so? I know that I agree that anybody can commit to my
repositories that are in Salsa's debian namespace, but I actually like
it when people commit to branches and leave the branches that are
released from to myself, and I also expect that I am at least asked
(informed) before somebody uploads from one of "my" repos inside the
Debian namespace.

so putting the package there already declares that.

I surely hope that is not true. I'd have to move my packages so a
different place then.

Greetings
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Boyuan Yang <byang@debian.org> [241221 18:10]:

在 12/21/2024 12:02 PM, Jeremy Sowden 写道:

On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:

On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:

We DO already have the debian namespace on salsa, everything in this namespace is "team maintained by everyone.",

Is that so?

[..]

From https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:

The debian group is for CollaborativeMaintenance (the old collab-maint
on Alioth).

The group is accessible to all Debian developers upon linking their
SSO Account, and are granted Maintainer access levels. Direct commits
to repositories in the Debian group by any Debian developer are
implicitly welcome. No pre-commit coordination (e.g. merge-request or
mail) is expected.

Obviously the words are only about git commits and nothing more.

Commits onto a git repo can be reversed easily (via `git revert`
or forced push, if one really wants to), but problematic uploaded
packages to the archive are irreversible and might cause broader
damages.

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 21, 2024 at 12:09:57PM -0500, Boyuan Yang wrote:

Commits onto a git repo can be reversed easily (via `git revert`
or forced push, if one really wants to), but problematic uploaded
packages to the archive are irreversible and might cause broader
damages. That is why people are okay with allowing random git commits
to Debian group but are not okay with uncoordinated uploads.

Yes, I fully agree with that.

Greetings
Marc


-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/12/24 15:32, Tobias Frost wrote:

On Sat, Dec 21, 2024 at 02:09:28PM +0100, Gioele Barabucci wrote:

On 21/12/24 10:15, Pirate Praveen wrote:

We could use collab maint list, which was specifically created for this
https://wiki.debian.org/CollaborativeMaintenance

Good idea.

To sum up all suggestions until now:

Some packages will be maintained in a default-open way and outside a
specific team, with an ethos similar to that of
https://wiki.debian.org/LowThresholdNmu (= feel free to fix bugs and
imperfections, but talk with the others before big changes).

Technical aspects:

* Maintainer: Debian contributors <collab-maint-devel@lists.debian.org> [1] >> * Uploaders: the DD and DMs that have more experience with this package (but >> not "responsible")

The "not responsible" part... IMHO The people in Uploaders should feel responsible for the package, otherwise noone will be feeling reponsible,
and then the package is just like an orphaned package pretendig to be maintained.

This branch of the discussion started by pointing out the fact that some maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintaining these packages.

It also makes sense to remove pretty much all responsibilities from the
listed uploaders. If someone is uploading a package with changes that I
have not reviewed, why should I be held (or feel) responsible for it?

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective,
diffused responsibility: "If this package is in bad shape, the whole
Debian project should be held responsible. Either it gets fixed by
someone or it gets RM'd by someone."

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Another thought I had was just to use the packages.d.o address.

E.g.

Maintainer: Debian developers <libfoo@packages.debian.org>

It would be invalid to use this in maintainers without any human
uploaders. Only qa@packages.debian.org is valid without human
uploaders.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat 21 Dec 2024 at 09:37am +01, Simon Josefsson wrote:

I've long though about changing maintainer to QA for my packages like
you suggest, but there has been at least on reason I haven't done so:
lack of clear effective written down team policy in what the conventions
are. I don't know what the packaging and upload policies are for 'Maintainer: Debian QA Team'. It seems some people orphan their
packages to use the QA team, which I find a strange approach.

I think that if workflow questions arose that couldn't be determined by
looking at the git history, it would be appropriate to write to the
people in Uploaders and ask how they'd like it to be handled.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdncMAZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQN18D/97hOddEPbKKm2F9kM+hQ7S yhwOwdmiThbeZ0zzHsnM5cc8Y15ucN3SeNG0FMLaRZLwJjUYgm0rdNf0/VgfBi+H 0PUDSu9WItmlJ/vvhmIb7aqP2cxTMLTiyAG4mHlSwxni7X7/wQbD3gpt/JIuq43p 8LPEsgPfu92PaRNRQ0n8LX+pFrHKtsytVtEvmPCLUvvoQNBtYOVkYDkmIDeLAss6 0ygMc5pyvVkc9Zv5R89vKgnTiXO4qSLPb7iCz6cwPBgnx8ELMRasQDlJoFZ+L+Jp Nm6nIWSDQSwtjX0At6dKEerN29hIg35lVddz9ZugQK3dUmJ4Cobf8hBpiC1gm1Rp BJ0/CDIuKUhIZrg2j3jHClDCrAZI6nCwBW6a+TsUaTGBoX2jlYRpr7kXRA0hlqXD h3tR+LkamDtGUp6MJYwsJQBByiCDKVOde0xeSnOr0ue7Mit958EnUp13gybjB6st r+IPzeP/3IxMXjFcssxLfjapA7w57zK5J7CrKwuzmY0sAx8H1w6hFo0bqwbpQKGj ZOkfnbcqMILijo181KW/IgD2wWOVoSWLo2Wx3+EQ23gXbOu+gFNnqPY4TN3PxlYT 48Yw0DonrADVThZ7MZembkEIncTEiPkDQYXo9zTuzYb4RKeawFMe5CTTm4bkue04 DhKXtteBXV/VWOVeFlbK6g==jiVk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hello,

On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective, diffused responsibility: "If this package is in bad shape, the whole Debian project should be held responsible. Either it gets fixed by someone or it gets RM'd by
someone."

Hmm, what you describe seems more like an orphaned package.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdncU8ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAq4D/9Mclai9XSrZqhcechfJJcY 2jJHyKhn0tYQC7KJOblmAE1px0D3UTebODOWCJaFbKCz2xoYJTa/Xeh0J8brpw4u II30LE2UYwXW64pFD1zCHJ44WsjEWI3Tpg2Y8tg3seItes1XeT5TjUmJeuSAlUfN mwWwkgTVFnsal3M22alwIKQh6KEKZH7vFRmk8O97m/96bX9s7abcOm3QFgWV9XcY fK4H1W42lQhdxEd2/7OjGpv6Z+YqvpDhacj0uJrKsHzPELBNP8VwulE/wRTnyjkt ZlnTuYXJzpoX4krPGDZbYUc/Bgbb7XKQVDyrRP3L0e8TSqdiPNOggdJZVKMgq9he XDStLsV7QCN0HeLFPC9qYoVz7WW2579SB7O3m5F4f33bmQx8G0ET4EiVL3O5Kesw YfARpj7r0JzCi+ZGgQOP/PX2BllA7xa39Ir9SrP8f1cr/rWMBMv/fnrtOyzZe9+x p+ct2tkd1stcRpXuQonC7rZQYmI2So7sXCs6hLnLP/Xo1OOWqlpyiyNPb3FdYzK0 TU0T4KRNxVrArY9Tcr1jBuKW5fs6giiwBUub02WsEDPoDf7wXTkqBTYjnRkxE3dj yz078BuBC2Buea89IWe+UF6sXnmdLA2vsrY9QKMyINb+4j6BwWMDm3+wFH6k0gJM NDiw+lfy4iXLfmh8cTDpIg==ui1J
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hello,

On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.

Yes, quite. Integers are cheap, and these are not uploads directly to
stable. We can always just upload again.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdncREZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQJXED/9ho70zFzwlXZ+bPzao9Na5 uT56DmPWgiDKaoThKSAmmD6+/jkoHlgq4zGrYxjQjOuEa9bdptzzyCGSe/bQa7rh uaEjjA8PrJT4ZmJSFyh06lpQ3RmlTVtbpRJjD50KChXUXpr44+9vYxhg8910Or9x zYndxD3kp7ZK1rZRd4KrjkNy3VsQpKWE4P/HOU1xMe5aQEauvJL8l+/bS0CBCyYc blSP4w+QK/2ozi8JhnPpsGTHJdXZF43pYugdRdX8gNU79HjEmlfPF/MisF/QbxTF 0HIKnFbGuDVUTTkbyhP5zAS7kteI6Ok07jJGul6vxp6/cqkXUSSIFweOlqG2NI9E Pce81dvgLQZWP45e8MzJf8/DbmbkRviJp68fFwUEbhQVO0unsofAoD0bRMoBapeN 3o011LiZTeTHrdXxt9AuaKREVRsD7QtYb1MWQvqfuWe2qolCBO5nYhsddz+DyZok vrOalvwXnW8xcV2C5kMmAoMus2D2lbXAzKlcIWvEi/CSQe2/OyZuFfUX0SEvvTlQ 3MVZGRI8BWet0jmLY+IV+d2YdcJYp7A4KDk2lgByaAGmdgHpL7Nl2IymOm4sMa2M Sqkb0hqRfy5LaDMUS4DxKweesiTTrHmh8tiyHf6NFVE3mazevV1pxWsErn8A+gnT aXQ0h1j+Vepd5NJTQpVirw==W3VM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

The https://go-team.pages.debian.net/ pages may have some flaws, but one
key social function is that it establishes the group as a team effort.
That goal is something to take after. I'm trying migrate my

+1

pkg-auth-maintainers packages to pkg-security just because https://wiki.debian.org/Teams/pkg-security establish the same social function, that we never managed to create within pkg-auth-maintainers.

I'm now learning Python team conventions -- https://wiki.debian.org/Python/LibraryStyleGuide -- too, and find
similar elements.

These policies are mutually incompatible and each is opinonated about
its own technical choices, but I find adapting to a set of consistency
rules helps collaborative work, regardless of what those technical
choices are.

I am active both in the Python and Go teams, and both teams work
relatively well and efficiently thanks to having certain minimum
common denominator in the packaging workflows.

While preparing DEP-18 I reviewed all packaging team policies I could
find, and the majority seems to be converging on using git, hosted on salsa.debian.org, built with with git-buildpackage, most of the time
also using pristine-tar, and branches and tags following DEP-14. Many
also advocate using gbp pq instead of quilt. The Go and Python teams
have all these in common, although they adopted DEP-14 at a different
time, so one ended up using `debian/master`[1] and the other
`debian/sid`[2] as the branch, which in DEP-14 nowadays should be
called `debian/latest`[3].

The places these teams diverge I think are *not* actually intentional
design decisions, but just a function of when the team had momentum to
renew and agree on workflows.

Hopefully these discussions will lead to elevated interest and
agreement among DDs that we should project-wide a recommended base
workflow, and support teams to each update their workflows at the same
time to have the same generation of advice in their docs.

[1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id5
[2] https://go-team.pages.debian.net/workflow-changes.html#wf-2017-11-dep14
[3] https://github.com/Debian/dh-make-golang/pull/225

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Commits onto a git repo can be reversed easily (via `git revert`
or forced push, if one really wants to), but problematic uploaded
packages to the archive are irreversible and might cause broader
damages. That is why people are okay with allowing random git commits
to Debian group but are not okay with uncoordinated uploads.

Yes, I fully agree with that.

++1

Please don't suggest that people should lower their mental barrier to
upload to Debian archives. Not only is it likely to cause extra work
to the package's original maintainer, it is also more likely to break
stuff in e.g. unstable and then cause extra work to everyone doing
Debian packaging. For example, if apt or grep has a regression, a
massive amount of builds and installs of other packages will
immediately stop working.

What if we had a culture that people file Merge Requests on Salsa
against the package with whatever improvements they have to suggest
and then wait to see if the maintainer is a) active b) in agreement
with the change.?

The reviewer/+1 does not even have to be the original maintainer, it
can be anyone in with Salsa access who discovers the MR and has
interest in it. As an added benefit the MR should also run Salsa CI to
show that there are no testable regressions. If there is no response
for multiple weeks, then the people who have open MRs against that
package could coordinate and do the upload instead of the (absent)
original maintainer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:

The debian group is for CollaborativeMaintenance (the old collab-maint
on Alioth).

The group is accessible to all Debian developers upon linking their
SSO Account, and are granted Maintainer access levels. Direct commits
to repositories in the Debian group by any Debian developer are
implicitly welcome. No pre-commit coordination (e.g. merge-request or
mail) is expected.

I think the shared https://salsa.debian.org/debian is great for
collaboration in many ways, but I think that coordination is still
useful to avoid duplicate or conflicting work in general. And as
Boyuan pointed out, that sentence is about 'pre-commit', not
'pre-upload'.

Please note that the page you reference, or the page https://wiki.debian.org/CollaborativeMaintenance referenced earlier
are not actually normative documents. The latter isn't even maintained
(still talks about Subversion). I would look at https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-maintainer and https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
as the only reliable source of truth and agreement/policy.

If the Maintainer field says something, it will anyway always triumph
whatever the git hosting location was. Actually, past week I started
helping a mentee package Godot, which at the time was in the debian
namespace on salsa, but mid-week somebody else (not me) moved it to
the games-team namespace. I didn't revert it as the Maintainer field
was indeed Games Team, which triumphs any rules and principles of
lower normative status than the policy.

Hence, Sean's suggestion to do something about the Maintainer field makes sense.

I am fine using debian-devel@lists.debian.org for packages people
don't want to feel responsible for if we can avoid having a flood of
emails to this list from automated bug email or even end users asking
for support because they saw this list is the "maintainer".

Maybe another option would be to remove the Maintainer field in
packages that don't have a maintainer, but that would not be a
backwards compatible change. Occasionally, it irritates me that we
have both a Maintainer and Uploaders field, but let's leave
simplifying that to another thread..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective,
diffused responsibility: "If this package is in bad shape, the whole
Debian project should be held responsible. Either it gets fixed by
someone or it gets RM'd by someone."

Hmm, what you describe seems more like an orphaned package.

+1 on that. The proposed scheme is exactly how "Maintainer: Debian QA
Group" works.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.

Yes, quite. Integers are cheap, and these are not uploads directly to stable. We can always just upload again.

Good morning,
Uploading to unstable makes changes user-visible, that is a enormous
difference to a GIT commit. Also nowadays we consider unstable as
staging ground for our next release, we have gone away from the "thank
you for using unstable, if it breaks you may keep both pieces"-approach.

Many changes in a installed package are not trivially/easily revertable.
Think of moving files between pacages (Needs Replaces/Breaks), replaxing symlinks by dirs and vice versa (needs dpkg-maintscript-helper),
changing dpkg-conffiles (not really undoable).

cu Andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
<gioele@svario.it> wrote:

This branch of the discussion started by pointing out the fact that some >maintainers _do_ in fact orphan their packages to remove the "feeling of >being responsible", and then go on maintaining these packages.

Its a way to visibly say "I'll do the job until the second someone
else shows up".

Greetings
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.

Yes, quite. Integers are cheap, and these are not uploads directly to stable. We can always just upload again.

Good morning,
Uploading to unstable makes changes user-visible, that is a enormous difference to a GIT commit. Also nowadays we consider unstable as
staging ground for our next release, we have gone away from the "thank
you for using unstable, if it breaks you may keep both pieces"-approach.

I think it's both? But that's for a different discussion.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdn2KUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh lpUP/RSmdKrv00HmPkAxBrufRGRkkFZPnS68eewZSdEQ4BSDNBpJxh5EPRj3J+zf pws/cXfh8oo0ZSwWhweahml19wbFZKRvp5bo6v2Rrk6WXy+V6pMx5w/cuiWyR1DI Yy1GaZtabRV2whMa8Pyk2q1FY8EXSPyG2BTe1703DtQrDTO+rfI/cbcvnEIsDUti m/0jB0dEcdx0bOOOxjkVzNmjsGE2bvoBFycQTiy5jkKPWaVakfGbtm2oay/XgB5U GKDbPn1dv5LvIGDPVhrDH6GY88hCCaEQN5Nd+CVDsvJ9eXTA3dOR3M7VY//mqGfn oLcqqGBmYIye0UBS8lM6EuL6rh7bzNA77TyeOAX0DaIOtvOqFqrVjFuhyDuV8fTP r9Tqx3TYc5LpF9gO8zenjWNjHIGZ9U5ON7Xbk5JPR89UiCePcAErJSey+4jf2xNz Oqgo69fhmzxpHO8ejDRoz0zbxO2kWcPb4mjs3ggaVMDBfRZDcnyIsKZw5oJab03S Pp0mVEGimLaPK6yOrz1CnOLOhoNUyClnUf6AN+Ut2DS+veF2d7jOVK4d8Z29/mRi Y/bWpwqf4i/9+Aa+wWf8s6WNAogGFA24MG7eg8sxLQ+usyyLgiLNCjlNfESGVTQV OP3uSsfQz+YCRBwlXLQhfiWiebUgjNmrpejv47WClqM3Buv/
=h7xo
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Andrey Rakhmatullin <wrar@debian.org> [241222 10:15]:

On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.

Yes, quite. Integers are cheap, and these are not uploads directly to stable. We can always just upload again.

Uploading to unstable makes changes user-visible, that is a enormous difference to a GIT commit. Also nowadays we consider unstable as
staging ground for our next release, we have gone away from the "thank
you for using unstable, if it breaks you may keep both pieces"-approach.

I think it's both? But that's for a different discussion.

I agree on both points in this line, and nevertheless stand by my
original message.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Gioele Barabucci:
We need different levels of responsibility:

* Nobody cares ⇒ orphan package
* I care a bit, but I don't have time to handle all the responsibilities
that a maintainership entail, but try to contact me anyway, I may reply
⇒ MISSING LEVEL discussed here
* I care, as a part of a group ⇒ Team uploads
* I care, and I'm willing to handle the full maintainership: Maintaner: me@debian.org.

+1

I think this captures the situation well. We already have an
established process for dealing with fully orphaned/abandoned
packages. The challenge is how to efficiently contribute to packages
that do have a maintainer, but the maintainer is temporarily inactive.

My suggestion is to use the Merge Request feature in Salsa, or to
submit patches on the bug tracker. This is a collaborative way to
share to the maintainer (and everyone else looking) that you have
researched the issue, you have a fix, and the fix is complete and
ready to be committed on the Debian packaging branch and uploaded in
next Debian revision.

If the maintainer does not respond in 10-20 days, then proceed to
merge the request / commit your patches. Wait some additional days to
see it anyone else has stuff that should be included in the next
upload, and then upload.

Behaving like this gives the maintainer ample opportunities to
respond, and it is a fully public and transparent way of working, as
it *also* gives anyone else an opportunity to review and comment the
changes. It is also much easier for the maintainer to respond to a
suggested code change "Thanks, please do A and B but not C" if they
are in a hurry than doing actual package maintenance. If the
maintainer acks, you have the mandate to complete it, and you are
unlikely to upset the maintainer and make them feel stressed about
uninspiring cleanup work. If the maintainer does not respond anything,
but they had the chance to respond, and maybe even somebody else +1
your change, you should be in the clear of proceeding. Sometimes the
maintainer might actually know something, and having them give a brief
comment will improve the package quality for end users. Code reviews
don't have any chance to happen if people just NMU.

Daniel Gröber:
Many changes in a installed package are not trivially/easily revertable. Think of moving files between pacages (Needs Replaces/Breaks), replaxing symlinks by dirs and vice versa (needs dpkg-maintscript-helper),

+1 to this too. I have a package that carries permanently an 1: epoch
because a collaborator did an uncoordinated and unreviewed upload,
which he did then revert yes, but most of the long-term cleanup burden
that had to be done for years and across multiple parallel major
version releases then landed on me. Not fun. I almost stopped
contributing to Debian completely at that point.

Even without doing these types of irreversible changes, I am sure that
if I would hypothetically speaking today upload a new version of
gettext in Debian unstable, I am absolutely sure Santiago would be
pissed off, and perhaps even stop contributing to Debian. I should
absolutely not commit such an act, not even if the change was small
and reversible, as it would be a stressful surprise to the maintainer.
If I have an improvement to gettext, it would be much more
collaborative of me to submit a bug+patch or open a Merge Request on
gettext and give the maintainer time to process it. Doing an NMU
should be the last resort, and happen only after giving ample time for
the maintainer to react.

What strikes me in this 30+ message thread is that the focus seems to
be on lowering the bar for NMUs. That seems like an obvious minefield
to me. Can we please consider lowering the bar for Merge Requests
instead?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Niels,

Am Sun, Jan 05, 2025 at 12:40:54PM +0100 schrieb Niels Thykier:

The "I'll do the job until the second someone else shows up" sounds close to RFA (Request For Adoption).

Maybe we can do with a variant like OFA (Open For Adoption), which does not have the "lingering ownership" that RFA has. For some RFA still has a sense of "I can choose who to pass the package on to". The proposal here would be that OFA was "If you want to maintain this package, just upload it with a
new maintainer". In my world, it would be combined with Low NMU Threshold / QA upload semantics for drive-by fixes, since the maintainer is supposedly not very attached to the package.

I get the difference behind your suggested OFA and RFA. IMHO the main
problem behind both is that only active maintainers will offer this
option by actively file a bug report. I admit I rather have a problem
with inactive maintainers. I have not made some stats (yet) but its
definitely not wrong to state that >90% of the ITS bugs I've filed in
the past remained unanswered. I do not expect that these maintainers
will file [OR]FA bugs.

Kind regards
Andreas.

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Andreas,

On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:

Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.

Yes, quite. Integers are cheap, and these are not uploads directly to stable. We can always just upload again.

Many changes in a installed package are not trivially/easily revertable. Think of moving files between pacages (Needs Replaces/Breaks), replaxing symlinks by dirs and vice versa (needs dpkg-maintscript-helper),

True, there are deficencies in our tooling here. However I kind of wonder
if inaction on a maintainer's part causing more work to revert changes
isn't actually a virtous mechanism from an organizational perspective.

It makes others' contributions "stick", counterbalances the natural
tendency to keep the status quo and should ideally motivate maintainers to respond swiftly to avoid future work :-)

I fail to see anything actually wrong with that in most cases. If a
contributor truly messed something up I would expect they would also have
the motivation to clean up after themselves once the error is pointed out
by someone. Since IMO learning-by-doing is also one of the more effective
ways for people to learn it seems especially worth it to tutor (new) contributors is such cases if needed.

changing dpkg-conffiles (not really undoable).

Could you elaborate on what scenario you're thinking of here?

Ideally we should endeavor to improve our tools to eliminate common sources
of irrevertable changes.

Can anyone think of other common cases where a revert is really, actually impossible? (No, postinst doing `rm -rf /` isn't a common case :P)

--Daniel

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmdpkNEACgkQ05SBrh55 rPft+hAAnFe3Z0KWl+nU7myx/pIsCDSU72VJbSQsjZkPWMEjI91/efpSCOoFayzQ tgpowqqrGDFVtZugjDwP4X64RyOQpumPFKV3MAG4ulKH3b7vEY0Oh3YIQww9ixxc 4UyN/6yFWnvoj8nDHa/aAIHH/8gL1uetKJ+luEzlga2LbuMEYSPyw69gcb7J4Tzk 7qtiX+6EIhn9zDVJCj7ThWP0i/j6A0VFDoOnmm2YbpJtamGkDN3At1/QUx0yTlrh EjWS1lb4wgvMfIV8+rU+9whA8WoDIHaSzK4JAx1IRwjrGTwJ0WTIQSWtJ0L1Z6Dd Yhc0sQ2Sf9vogV+9q1i+3PIxGol8DP34LRv2Wth+Bx2ezSIyEcwR8ZgvysjVHPMM zaGXw4QaFh9es9o/b+GoFtYHN2A6SkBa5nwXOXn2T8TABtBpQIRfQIIdx8b0wReP P5wjkItQZfXpuRyuySWTSWx79gTWqVUw5z8ELCHF8mYzv/4sH6nLp5P5+SJ+z+q+ zpJ/2cFvobFV5X/hv7+MMFgc9CiCTp6x5lLd9h/DOGIlfEcNATBaS9SZfsNvtpE0 9z59M0fZypUzEfuXrlhpIBo0/e0WZJQixfb4FTgqwxgTlvCjywGUv7Pv0mi5FvFM IUGlhs860+Xsh2i1lcJ9to2WwoFgW/owycD52N9AjiLJDzpD1i0=
=MO1m
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/12/24 06:56, Andreas Metzler wrote:

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective,
diffused responsibility: "If this package is in bad shape, the whole
Debian project should be held responsible. Either it gets fixed by
someone or it gets RM'd by someone."

Hmm, what you describe seems more like an orphaned package.

+1 on that. The proposed scheme is exactly how "Maintainer: Debian QA
Group" works.

Not exactly.

https://lintian.debian.org/tags/uploaders-in-orphan.html

uploaders-in-orphan

Packages with their maintainer set to packages@qa.debian.org,
i.e. orphaned packages, should not have uploaders.
Adopt the package properly if you want to resume its maintenance.

We need different levels of responsibility:

* Nobody cares ⇒ orphan package
* I care a bit, but I don't have time to handle all the responsibilities
that a maintainership entail, but try to contact me anyway, I may reply
⇒ MISSING LEVEL discussed here
* I care, as a part of a group ⇒ Team uploads
* I care, and I'm willing to handle the full maintainership: Maintaner: me@debian.org.

Regards,

--
Gioele Barabucci

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-23 Gioele Barabucci <gioele@svario.it> wrote:

On 22/12/24 06:56, Andreas Metzler wrote:

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective,
diffused responsibility: "If this package is in bad shape, the whole
Debian project should be held responsible. Either it gets fixed by
someone or it gets RM'd by someone."

Hmm, what you describe seems more like an orphaned package.

+1 on that. The proposed scheme is exactly how "Maintainer: Debian QA
Group" works.

Not exactly.

https://lintian.debian.org/tags/uploaders-in-orphan.html

uploaders-in-orphan

Packages with their maintainer set to packages@qa.debian.org,
i.e. orphaned packages, should not have uploaders.
Adopt the package properly if you want to resume its maintenance.

[...]

"The proposed scheme" was supposed to be refering to the grander idea of
having a package with nobody being responsible but with "Debian" taking
care. That is exactly how qa maintained packages work. Imho the main
problem we have there is not that they are maintained badly, the
relevant packages often have high quality packaging, however there is
loads and loads of cruft that really should be removed but is not
because nobody is responsible.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Andreas Metzler <ametzler@bebt.de> [241224 11:53]:

On 2024-12-23 Gioele Barabucci <gioele@svario.it> wrote:

On 22/12/24 06:56, Andreas Metzler wrote:

On 2024-12-22 Sean Whitton <spwhitton@spwhitton.name> wrote:

On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:

We have a mechanism for when you feel responsible: "Maintainer: $me".

What is being discussed here is a mechanism for shared, collective,
diffused responsibility: "If this package is in bad shape, the whole >>>> Debian project should be held responsible. Either it gets fixed by
someone or it gets RM'd by someone."

Hmm, what you describe seems more like an orphaned package.

+1 on that. The proposed scheme is exactly how "Maintainer: Debian QA
Group" works.

Not exactly.
https://lintian.debian.org/tags/uploaders-in-orphan.html

uploaders-in-orphan
Packages with their maintainer set to packages@qa.debian.org,
i.e. orphaned packages, should not have uploaders.
Adopt the package properly if you want to resume its maintenance.

[...]

"The proposed scheme" was supposed to be refering to the grander idea of having a package with nobody being responsible but with "Debian" taking
care. That is exactly how qa maintained packages work. Imho the main
problem we have there is not that they are maintained badly, the
relevant packages often have high quality packaging, however there is
loads and loads of cruft that really should be removed but is not
because nobody is responsible.

The difference seems to boil down to "this package can be adopted
into the classic maintainership model" ('orphaned') and "this
package is someone-else-does-it-maintained and if its actually
orphaned nobody will notice".

Probably fine until actually nobody cares anymore, and then we have
a bigger mess than we already have today with actually-orphaned
packages.

Anyone who wants to introduce this concept should also describe how
these packages will be maintained/QAed/removed when all interested
people vanish.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)