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

SGkgYWxsLA0KDQpJbiB0aGlzIGRpc2N1c3Npb24gYWJvdXQgbWFuZGF0aW5nIHRoaW5ncywg SSd2ZSBiZWVuIHdvbmRlcmluZy4uLi4NCg0KT24gMTktMDUtMjAyNCA5OjExIGEubS4sIEpv bmFzIFNtZWRlZ2FhcmQgd3JvdGU6DQo+ICAgKiBtYW5kYXRlIFZDUy10cmFja2luZw0KPiAg ICAgKiBZZXMNCj4gICAqIG1hbmRhdGUgdGhlIHVzZSBvZiBvbmUgc3BlY2lmaWMgVkNTDQo+ ICAgICAqIFllczogZ2l0DQoNCldoYXQgZG8gcGVvcGxlIHRoaW5rIHRoaXMgc2hvdWxkIG1l YW4sIGEgKnNob3VsZCogb3IgKm11c3QqIGluIHBvbGljeT8gDQpUaGF0IHRoZSBwYWNrYWdl IGhhcyBhIFJDIGJ1ZyBpZiB0aGUgcGFja2FnaW5nIGlzbid0IHRyYWNrZWQgaW4gZ2l0PyBB bmQgDQppZiB0aGUgcGFja2FnaW5nIGlzIGluIGdpdCBidXQgSSBmb3Jnb3QgdG8gcHVzaCBt eSBsYXRlc3QgY2hhbmdlcyB0byB0aGUgDQpkb2N1bWVudGVkIGdpdCBzZXJ2ZXIgKHRoaXMg aGFwcGVucyByZWd1bGFybHkgdG8gbWUgYXMgSSBkbyBtb3N0IHVwbG9hZHMgDQp3aXRoIGRn aXQpPyBSQz8gSW4gYWxsIHN1aXRlcyB3aGVyZSB0aGUgcGFja2FnaW5nIHZlcnNpb24gaXNu J3QgcHVzaGVkIA0KZm9yPyBBbmQgaG93IGFib3V0IE5NVSdzPyAoSSBqdXN0IGNoZWNrZWQg YSByYW5kb20gcGFja2FnZSB3aXRob3V0IGdpdDogDQphc3BlbGwtYW0sIGxhc3Qgbm9uLU5N VSB1cGxvYWQgd2FzIGluIDIwMTMpPw0KDQpJZiAqbXVzdCogYW5kIHRodXMgUkMsIGNhbiB0 aGUgaXNzdWUgYmUgZml4ZWQgYnkgIk5NVSI/IEkuZS4gaWYgdGhlIA0KcGVyc29uIHRoYXQg ZGlkIHRoZSBjaGFuZ2VzLCAoYW5kIGhhcyBuaWNlIGxvY2FsIGNvbW1pdHMpIHNvbWVob3cg aXNuJ3QgDQphdmFpbGFibGUsIHdpbGwgdGhlIHBhY2thZ2UgKGlmIG5vdCBrZXkpIGJlIGF1 dG8tcmVtb3ZlZD8gT3IgY2FuIA0KZXZlcnlib2R5IGZpeCB0aGUgcmVwbz8gV2hhdCBpZiB5 b3UgZG9uJ3QgaGF2ZSB3cml0ZSBhY2Nlc3MgdG8gdGhlIA0KZXhpc3RpbmcgcmVwbz8gQW5k IHRoZW4gd2hhdCBpZiB0aGUgdXBsb2FkZXIgY29tZXMgYmFjayBhbmQgdHJpZXMgdG8gDQpw dXNoIHRoZSByZWFsIGhpc3Rvcnk/IFdoYXQgaWYgbXkgaGFyZGRpc2sgd2l0aCBsb2NhbCBj aGFuZ2VzIGNyYXNoZXMgDQpiZWZvcmUgSSBwdXNoIChhZ2FpbiwgSSBmb3JnZXQgdGhhdCBz b21ldGltZXMsIGJ1dCBmb3IgbWUgbHVja2lseSBkZ2l0IA0Kd2lsbCBtb3N0bHkgaGF2ZSB0 aGUgY29tbWl0cykuDQoNCk9yIGlzIHRoaXMgImp1c3QgYSBidWciLCBtYXliZSBldmVuIGF0 IGxldmVsIGltcG9ydGFudCwgYnV0IG5vIG90aGVyIA0KY29uc2VxdWVuY2VzLiBUaGFuIEkg dGhpbmsgdGhpcyBkaXNjdXNzaW9uIGlzIGdvaW5nIHRvIGJlIG1vb3QuIEkgZG9uJ3QgDQp0 aGluayB0aGVyZSdzIG11Y2ggZm9yY2luZyBwb3NzaWJsZSBhbmQgSSB0aGluayBtb3N0IGFs cmVhZHkgYWdyZWUgdGhhdCANCnN0dWZmICpzaG91bGQqIGJlIGluIFZDUywgc28gdGhpcyBp c24ndCBnb2luZyB0byBjaGFuZ2UgZm9yIHRob3NlIGluIA0KZmF2b3IuIEFuZCBkb2VzIGl0 IHJlYWxseSBhZGQgZW5vdWdoIHZhbHVlIGlmIHRob3NlIHRoYXQgYXJlIGZvcmNlZCBhcmUg DQpqdXN0IGdvaW5nIHRvIGRvICJnYnAgaW1wb3J0LWRzYyIgZm9yIGVhY2ggdXBsb2FkIHRv IHRoZSBhcmNoaXZlIG9uIGEgDQouL2RlYmlhbiBvbmx5IHJlcG9zaXRvcnk/IEJlY2F1c2Ug dGhhdCAob3IgYmV0dGVyKSB3ZSBjb3VsZCBhbHJlYWR5IA0KYXV0b21hdGUgKHNlZSBhbHNv IG15IFBTKS4NCg0KSSdtIGFnYWluc3QgbWFuZGF0aW5nICgibXVzdCIpLiBJIHRoaW5rIHRo ZXJlJ3MgYSBsYXJnZSBtYWpvcml0eSAobWF5YmUgDQpldmVuIGNvbnNlbnN1cykgdGhhdCBi ZWxpZXZlIHlvdSAqc2hvdWxkKiBoYXZlIHRoZSBwYWNrYWdpbmcgaW4gVkNTIChhbmQgDQpJ IGFncmVlIHdpdGggdGhhdCkuIE1vc3QgcGFja2FnZXMgYWxyZWFkeSBhcmUgKGhvcGVmdWxs eSBtYWludGFpbmVkKSBpbiANCmdpdCAoOTMlIGZvciB0ZXN0aW5nKSBbMV0gb24gc2Fsc2Eg KDg2JSkgWzJdLCBzbyBJIHByb3Bvc2Ugd2Ugc3RvcCB0aGUgDQpkaXNjdXNzaW9uLiBJIHRo aW5rIHdoYXQgcGVyZSBkaWQgWzNdIGNoYW5nZWQgbW9yZSB0aGFuIHRoaXMgd2hvbGUgDQpk aXNjdXNzaW9uOiBhbHJlYWR5IDQ1ICpvcnBoYW5lZCogcGFja2FnZXMgY29udmVydGVkIHRv IGdpdCBieSAyNSBBcHJpbCwgDQp3aGljaCBtZWFucyBteSBudW1iZXJzIGFib3ZlIGFyZSBv biB0aGUgbG93IHNpZGUuIFRoZSByZW1haW5pbmcgNDM4IFFBIA0KbWFpbnRhaW5lZCAoISE/ PykgcGFja2FnZXMgY29uc3RpdHV0ZSBjbG9zZSB0byAyMCUgb2YgdGhlIHBhY2thZ2VzIG5v dCANCmluIGdpdC4NCg0KUGF1bA0KDQpQUzogSSd2ZSBhbHdheXMgd29uZGVyZWQgaWYgdGhl IGRnaXQgc2VydmVyIHNob3VsZG4ndCB0cmFjayBoaXN0b3J5LCANCmV2ZW4gaWYgdXBsb2Fk cyBkb24ndCBoYXBwZW4gdmlhIGl0LiBBIGRnaXQgY2xvbmUgY291bGQgKHNob3VsZD8pIA0K YWxyZWFkeSBwcm92aWRlIGF2YWlsYWJsZSBoaXN0b3J5LCBldmVuIGlmIG5vIHVwbG9hZCBo YXBwZW5lZCB2aWEgaXQgeWV0Lg0KDQpbMV0gaHR0cHM6Ly90cmVuZHMuZGViaWFuLm5ldC92 Y3NfdGVzdGluZy1zdGFja2VkLnBuZw0KWzJdIGh0dHBzOi8vdHJlbmRzLmRlYmlhbi5uZXQv dmNzLWhvc3RpbmdfdGVzdGluZy1zdGFja2VkLnBuZw0K

--------------IXIJ5grAddTP4o0viyGYtFMv--

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

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmZJstIFAwAAAAAACgkQnFyZ6wW9dQrZ 6AgAo7rGhIzFJy7KXJghmlAsxvBLjPByrOAwvZM7Oy0i5Ddc2N8NBvOdi2YFAjMZyKbjfIaeHv6u 8Mr5F5ucoEI1Yew64gX9g/RgubQ+25GX5xcmsrdnyAeJUqz7KIl7Su88XpPa10LxGrroULkI8YhB 0TMpnsi4u+MIBiRMxauvHpOtfs+nfTtWsD7hZ91/M4vTgNEV4TfVVS0wwVlpuM56Q19qdeRv058P aHLltNZ1MQmH2KAfxzDWB7rvLdeN5RLYha1kGjJV2/CyHVZp6ukCQMtS+eBFpU9FYR2rnTMfBqCE EBAzKjoGe402W1iT6j74U/MScjh/R8Narw6gLVNLAQ==
=kDlN
-----END PGP SIGNATURE-----

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

Quoting Otto Kekäläinen (2024-05-19 05:25:10)

In a recent long thread on debian-devel you had somewhat negative
sentiments towards the usefulness of Salsa. I do see you doing good
technical work for Debian and recently a MR from Bill too, so I was
thinking that maybe you will change your mind when you read more
in-depth arguments. This is my attempt to have you think about Salsa
in a new light:

On Tue, 9 Apr 2024 at 11:41, Bill Allombert <ballombe@debian.org> wrote:

Having a repository on salsa or even "packaging team" does not prevent
a lack of maintainer, so this is not relevant.
Without a maintainer, no contribution will be merged in any case.

Consider this Merge Request to fix debbugs builds immediately, and to
include Salsa-CI to keep the build from regressing again: https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19

1. If the package was not on git and Salsa, I would have no way to see
what the maintainers have been doing in the years 2018-2023 (Debian
repos had last upload in 2018)

With git (or another VCS) but *without Salsa, you would certainly not be
blind to existing development.

I agree with striving towards VCS tracking of all code in Debian, and
striving towards the use of a single VCS, and I think it is reasonable
to separate the discussion about that from the discussion about the
relevancy of Salsa.

2. If the package was not on Salsa, and had the MR feature active, I
would not be able to submit a MR to fix the issues. Now the MR is up
there, and anybody can review and comment it - thus we are not even
dependent on the original maintainers alone.

With git but without Salsa, you would post a patch to Debbugs, that
would be up there for anybody to review and comment on.

Sure, you would not be able to specifically use a Gitlab routine without
having a Gitlab instance to do it on. And reviewers and commenters
would need to be bothered with using email, which is different but not inherently worse than having to be bothered with using Gitlab UIs.

Did you also post your MR as a patch in Debbugs?

3. The UI is easy and useful. I invite you to read my MR and add your
review. I made have some extra instructions to make this very
welcoming for people who do not "like" Salsa/GitLab and might feel
that something is unintuitive

The UI of my email program is easy and useful.

You don't need to agree with me, you can pick another email system that
is more to your liking. It is much harder with Gitlab to provide room
for different personal ways of working. Please note, that I am here,
like yourself, not talking about different ways of structuring code in a
VCS, but about how the UI affects how you personally are able to
interact.

You and I quite likely use different text editor, and different email application, and possibly also different web browser. That affects how
easy and useful the personal end of collaboration is. The collective end
of collaboration must involve how (if at all) code is tracked in a VCS,
but it need not dictate UI at all.

4. If you don't want to use the web UI, you can also download my patch https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch
and review by email. Or you can click in the UI once to subscribe the
MR and then continue review/comments by email.

If you don't want to use a command-line or a scripted or a GUI-based
email application for receiving patches shared at Debbugs, you can use a web-based email application - locally hosted or through a provider.

I already subscribe to Debbugs for the packages and teams I am most
interested in tracking contributions for.

Personally I fully agree with the people stating that "Salsa is the
best thing in Debian in the past 20 years". So far everyone I talked
to who initially had reservations regarding using Salsa have started
liking it after they learned a bit more how it works, and have seen
things like Salsa-CI in action saving the Debian archive from needless widespread failures.

Debian is *not* helped by spreading issue tracking across multiple
independent data and communication networks.

My concern about Gitlab is not its *additions* to existing services, but
its *duplications* of core services already in Debian.

Please, let us separately discuss if we should...

* mandate VCS-tracking
* mandate the use of one specific VCS
* mandate one specific VCS workflow
* mandate collaborative packaging
* mandate project-wide issue tracking
* mandate a single project-wide issue-tracker

...instead of lumping all those discussions into a discussion of ease of
user interface for a single catch-all code forge that maybe make all those other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all.

Personally, my current opinion on each of the above is this:

* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
* mandate one specific VCS workflow
* Not yet, but require unusual workflow flagged and documented
* mandate collaborative packaging
* Not yet, but
* mandate project-wide issue tracking
* Yes: personal/team issues like WNPP work are project issues
* mandate a single project-wide issue-tracker
* Yes: Debbugs (for now: open to switch but not to duplicate)


- 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 --==============�22167206630746150=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZJpgQACgkQLHwxRsGg ASGzIw/8CzzNCZzOTL7fSBT/pfkDUCwa6t1BDPU2sMM6XqHpvtQgdj7MAjVY08HR lajXGnBVEL6PZQs5WT4m7eUn0afisaraJCdKdb2xRdWG4Y3bFpDEmKrLugz7Nolf LVlfGh4jEm0p7DoveBojVSSKHT+1vb7HtP5KheEeKAQ+Rrwucqu+4hqenAtstOm6 h85g+A2OBP+80Mq0sC7PJskgqgQ/k1zC/tSs4MExpVotL+ni1vQjlTvMduN0DJ0j ZyW5KhEwrGkkJ+s2/mjFJvh1ceVww8xUMV7IJXsW7XRI+If+w4nlF6dlkfPxgW3X EyKjpZebkqjvHLOlKfYjcnOpTK2g5wtnY09waJ5zNvaAo9vD9HBPVppqx+PGQW/C ApMAC/Ay+hKJmmMCR0eCq94uU4rTfHfezcLUbwCl7WkhA3WS2DGdytsosL4rGxmJ uK+Gt6BKfPjV4X/eWMSlNoiU9wnIBShlobx7ilvA

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

VHdvIG1pc3Rha2VzIHNwb3R0ZWQgLi4uLg0KDQpPbiAxOS0wNS0yMDI0IDEwOjA1IGEubS4s IFBhdWwgR2V2ZXJzIHdyb3RlOg0KPiBJIHRoaW5rIHRoZXJlJ3MgYSBsYXJnZSBtYWpvcml0 eSAobWF5YmUgDQo+IGV2ZW4gY29uc2Vuc3VzKSB0aGF0IGJlbGlldmUgeW91ICpzaG91bGQq IGhhdmUgdGhlIHBhY2thZ2luZyBpbiBWQ1MNCg0KSSBtZWFudCAiYXQgbGVhc3Qgc2hvdWxk IiwgYXMgaW4gInNob3VsZCBvciBtdXN0Ii4NCg0KPiBJIHRoaW5rIHdoYXQgcGVyZSBkaWQg WzNdDQoNClszXSANCmh0dHBzOi8vcGVvcGxlLnNrb2xlbGludXgub3JnL3BlcmUvYmxvZy80 NV9vcnBoYW5lZF9EZWJpYW5fcGFja2FnZXNfbW92ZWRfdG9fZ2l0X18zOTFfdG9fZ28uaHRt bA0KDQpQYXVsDQo=

--------------ERIkbhXMK4xQCuvRr8s0vPnv--

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

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmZJtdMFAwAAAAAACgkQnFyZ6wW9dQpv AAgAmcpY1JBLlUFoqos6drYp1v4N0OKA7qQu3q6EI3RF/KZLkYnc1iasfcKaO0vpyOUdy4Gbr5sc h2GmrtgNpDD36Qzm5fjhfsK6ytK6N07LScQj9Y0TkJKeT9i09csONHvVslW0nvFyf+XcahwVyWmn ctRwLvljBJwcEYGIz7CtTIwmS0q8D9/zx5CkrvT7Fxq26KXCorqAllp2oY93sfXeFK7vcYqTzRfI faCMzZtr8kflNVCGZ7keadfLJKmS8nWEFQy1Uc5YkGudAvXEHj89Oi5C3a9n63IQzsbVr7P7Vmcw f9/uqsoY8RYn3r/jNd2T7iwW6EESNtP34pYcP3TxYw==
=fjng
-----END PGP SIGNATURE-----

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

Quoting Paul Gevers (2024-05-19 10:05:38)

In this discussion about mandating things, I've been wondering....

On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:

* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git

What do people think this should mean, a *should* or *must* in policy?
That the package has a RC bug if the packaging isn't tracked in git? And
if the packaging is in git but I forgot to push my latest changes to the documented git server (this happens regularly to me as I do most uploads
with dgit)? RC? In all suites where the packaging version isn't pushed
for? And how about NMU's? (I just checked a random package without git: aspell-am, last non-NMU upload was in 2013)?

If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the
person that did the changes, (and has nice local commits) somehow isn't available, will the package (if not key) be auto-removed? Or can
everybody fix the repo? What if you don't have write access to the
existing repo? And then what if the uploader comes back and tries to
push the real history? What if my harddisk with local changes crashes
before I push (again, I forget that sometimes, but for me luckily dgit
will mostly have the commits).

Or is this "just a bug", maybe even at level important, but no other consequences. Than I think this discussion is going to be moot. I don't think there's much forcing possible and I think most already agree that stuff *should* be in VCS, so this isn't going to change for those in
favor. And does it really add enough value if those that are forced are
just going to do "gbp import-dsc" for each upload to the archive on a ./debian only repository? Because that (or better) we could already
automate (see also my PS).

With "mandate" I do not mean kick out if non-compliant. Same as we (as
far as I am aware) mandate declaring Poilcy version followed by a
package, but don't kick out packages having mismatching declaration or
not following latest policy.

I think there is a big difference between saying that Salsa (or git, og Debbugs, or public-wide WNPP work tracking) is an optional addon to
Debian, to saying that it is expected of everyone (i.e. you are being
asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project).

So I disagree that tool-use severity of "important" makes progress moot.

I have met developers who have the view that we are already at the point
of non-use of Salsa being asocial behavior, and had at least one very interested (and calm) exchange of such differing views at Debconf in
Kosovo. Deciding project-wide where we are on that scale do help, I
think.

PS: I've always wondered if the dgit server shouldn't track history,
even if uploads don't happen via it. A dgit clone could (should?)
already provide available history, even if no upload happened via it yet.

All the points that I listed are all about optional/expected/required *contributor* streamlining.

If I understand your comment above about dgit correctly, it is about
automation of history tracking, which is (mostly) orthogonal to
*contributor* streamlining.

- 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 --==============i32666624744002623=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZJvKgACgkQLHwxRsGg ASHJ7g/+OCBdBrsWC0nY/63REpDgQH2rNMEpJo4NfoBUgBdg1Z5xClJyR9qHnOUt AIk+93ImFeuwSPK3SUkXSbXY4J9/jKTIkxFHidlfi4eEZsIL5ueFXMcFdBAkyH5m 6cw1X7brCFq3LaMywhZL5eh/SXVyIE8wYepJpZLwpmnOVjjVAXb1GK8Q2QkA9fo6 8KbhlOJFvvc7ldA5BiT9hzdCIOL8BUU85l7jZgZmWnLP9B1Um1ISbiDMVXT89+w4 zq1hNMf+uIBj2yF8mkSVTRrMJq9F3K55z/eV1qBiPKU4IzAg3X0Zx4Mtqq2/Q9LI JtkW4JXDRGiZYIIAwWjHPiATijXLIWUs1S9o+eECJwNt/Ncf1Ydt2+6GHfPIUdF5 aguLrc3Z0A28USzRCaqKssCECK3fZdb+YFpg4dAEsOdfpYVKkLICR/7/bnN7+BL1 ZM+LA6sKjAiqCw1nCdVaEN4hiuFYtuf4+4Y7PoGF

Quoting Mathias Behrle (2024-05-19 11:08:58)

* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200):

i.e. you are being
asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project).

I very much agree with all what you say, however could we rather say instead

i.e. you are not being collaborator friendly, and can expect your behavior be

frowned upon...

I am not a native english speaker, I think we can avoid to trap in a can of worms with problematic terms like 'asocial, unsocial, anti-social...' which could have quite special meanings in different cultures.

Thanks for raising awareness to this. I was unaware that "asocial" was disruptive to the conversation, but indeed danish dictionaries (I am no
native english speaker either) flag that word as condescending.


- 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 --==============�66739571525551506=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZJymoACgkQLHwxRsGg ASEvkQ//U/iq+yJgZJok2fotSywXyT99p5T/QrAkoeGy9TGaVnoF62cd6/hR0cve p7a5TYuySQ6GA0DPURFYgK5Cr3EW/RKwVBrmfu+LQ2LFBUlQ19VRBZ/AALeYdp8M itGAmob7SDH+aUGwKvqb276X9cUovITUB2uWmxH4Rjmc2aWM/1kJY4nGDyrC1VKR HjocRbjpqVKW9TNejOwov+7+Bq4KRE9oVAyILSaiox6GPYU0+1C76DrF1KOEOnyy qj2+EtzpsVTmstC2l7/g8zHtSA8SQUYMzlBX8fm3IDOWZJ29koLTnGPoDSeDhRNt hnu0pd5NTtLMM7q/ats59RFsgxuB1g1+SwsddiWKnZlUuZIkT1uq8GtskYxJKc4p 3ogN6gAAgQoxLCimTnBn0bf7s1BELQSKNXG3EqKUBCGKWZDOmqhtNY5wi++jahMi oRQxdrteBQGJEwnZIgLa8v6V0JhPoC0cOEAz5bbt

* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200):

i.e. you are being
asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project).

I very much agree with all what you say, however could we rather say instead

i.e. you are not being collaborator friendly, and can expect your behavior be

frowned upon...

I am not a native english speaker, I think we can avoid to trap in a can of worms with problematic terms like 'asocial, unsocial, anti-social...' which could have quite special meanings in different cultures.

Best,
Mathias

--

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6

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

On Sat, May 18, 2024 at 08:25:10PM -0700, Otto Kek�l�inen wrote:

Hi Bill and Wookey!

In a recent long thread on debian-devel you had somewhat negative
sentiments towards the usefulness of Salsa.

I am not sure this characterize my position. I have no opposition to
Salsa (even though it is missing features Alioth had I relied on),
I am opposed to be forced to use it when it just increases
bureaucracy.

I do see you doing good
technical work for Debian and recently a MR from Bill too, so I was
thinking that maybe you will change your mind when you read more
in-depth arguments. This is my attempt to have you think about Salsa
in a new light:

On Tue, 9 Apr 2024 at 11:41, Bill Allombert <ballombe@debian.org> wrote:

Having a repository on salsa or even "packaging team" does not prevent
a lack of maintainer, so this is not relevant.
Without a maintainer, no contribution will be merged in any case.

Consider this Merge Request to fix debbugs builds immediately, and to
include Salsa-CI to keep the build from regressing again: https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19

debbugs is a Debian-native package. So of course it needs an upstream git repository. All my Debian-native packages are maintained on Salsa (and before Salsa on Alioth).

The MR I did was for lintian which is also Debian-native.

Also debbugs is a special case:
The debbugs Debian package (as opposed to the debbugs software) have never been really maintained. I am actually one of the very few users of this package
and I tried several times to get the maintainers to do a new upload but they were clearly not interested.
Ideally debbugs should be made non-native so that some else could maintain the Debian package.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

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

My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian.

I agree, that's the key problem.

I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.

...instead of lumping all those discussions into a discussion of ease of user interface for a single catch-all code forge that maybe make all those other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all.

Also, there is a difference between ease of use and intuitivity. GitLab
does not provide any tools that really make packaging easier. It is
initially more accessible to non-maintainers, because of familiarity,
but actual work happens outside of it.

Would you be kind and try to understand the opposing viewpoint by
trying it for one day?

You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
conduct a code review?

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian - it is currently the only platform
to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.


- Otto

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

Quoting Otto Kekäläinen (2024-05-19 21:32:36)

My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian.

I agree, that's the key problem.

I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.

...instead of lumping all those discussions into a discussion of ease of user interface for a single catch-all code forge that maybe make all those
other complications go away by affecting all those questions and that way implicitly provides *some* answer to them all.

Also, there is a difference between ease of use and intuitivity. GitLab does not provide any tools that really make packaging easier. It is initially more accessible to non-maintainers, because of familiarity,
but actual work happens outside of it.

Would you be kind and try to understand the opposing viewpoint by
trying it for one day?

You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
conduct a code review?

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian - it is currently the only platform
to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.

But it *is* duplicating Debbugs: None of your valuable contributions
posted as part of your code review appears on Debbugs.

The developers of FreedomBox (which is a Debian Pure Blend, i.e. a
project fully within Debian) has embraced Salsa, and when I asked about
an issue with network instability for certain hardware, I was told that
it was in the issue tracker - which meant it was missing from Debbugs
while actively discussed in Salsa.

Salsa is *great* if you fully embrace it. Salsa is not good if you want
single features without fully embracing it.


- 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 --==============11425165106303330=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZKca0ACgkQLHwxRsGg ASHhUQ/9F1Kbyv4Aqwpp7YN14G3GUr+GOrY1egsAfY+Iaqz4TSCSjoyOTNJtoeE0 4TV5YbrDb3kRZzQCNLGKPwajSkq0oaVO72RbWYTlyQXk2lNJ7P3nRCAbk3pjWXFi V4fkHykRJG9lXIwm+fZQeVDkFOpPgNS4n+GHGA9PLGVkdPgrSvevjhwgkNl2G2V8 BKxTHG59hbQruCURZn9Ua/R0u/pH/kVM+eMQTWKqJFZ99DolxASF+gr40v+4I5xd aTDUZ/PMyYOl0HRvchHZAJF6dcnMbBGMSqwpz0+fr49aZ9zssFIVbr3b7xF/o0k0 w2LpUDepywZxlJZBG0gXsKwkkIYMXuw95+Y+tb/4Ug/kzrb9pCh0CdEaxxjT4+vl OtDU581Exjb7yHGthBLgdG1JOS734jr9wEeBtm/52GLYBPB10yjs2+EN/B7snlDj mdiLuwuucsz/ZHfVUN16wMAxul4TKuSsrOIaWpLL

Thanks for reply Jonas,

You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and conduct a code review?

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian - it is currently the only platform
to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.

But it *is* duplicating Debbugs: None of your valuable contributions
posted as part of your code review appears on Debbugs.

Actually some of them are in Debbugs as patches, but hard to find as
there are 200+ open bugs.
However, the bugs.debian.org system does not offer code testing or
review facilitation.

Again, I invite you to test out https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 for
_code review_ for the same reason I stated above.

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

Hi,

On 5/20/24 04:32, Otto Kekäläinen wrote:

I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.

Outside of DM uploads, I'm not sure that there is much of a need for a
code review on packaging -- really what we want is to reduce the amount
of code for packaging, by moving it into declarative frameworks whenever possible, so the vast majority of packaging changes should be trivial
ones like upgrading a dependency version.

Would you be kind and try to understand the opposing viewpoint by
trying it for one day?

I am using it for most of my packages. It has not made my life easier,
it's just another layer that I need to communicate my intentions through.

I generally do test builds of my packages in a local pbuilder instance,
with a hook script to drop me into a shell if the build fails, so the
workspace is kept for my investigation. The only CI system that offers a similar feature is Jenkins, but even there I can only inspect the files
through a clunky web interface, as soon as I need to look at a binary
file or search for a string, I need to download it as a zipfile, and
re-running commands inside the same environment to test them is
completely out.

You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
conduct a code review?

At first glance, looks good to me.

Looking at the changes:

1. The outdated build dependency is not in the package currently in
Debian. If it was, it would have been spotted by Debian's archive
analysis tools already, without the need for a build attempt.

This static analysis is cheaper than a rebuild, so to achieve the same
level of coverage, Salsa would need to perform a full archive rebuild
daily, and it would still not catch the broken Suggests: in the binary.

2. The missing file in debian/docs was already reported as #903413.

3. The other changes are "upstream" changes, which should have a
separate CI that is more extensive than "still builds."

Native packages should only be used for things where it does not make
sense to maintain a separate upstream package because they only exist
within the package ecosystem, like the "menu" package. Debbugs should
really be split into separate "upstream" and "packaging" efforts.

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian

Well, there is an issue tracker (where tickets go unresponded for a
year), that is certainly a duplication of debbugs. It would make sense
to maybe track "upstream" bugs there and forward them from debbugs (a
feature not present in GitLab's issues handling, but important for
package maintenance).

- it is currently the only platform

to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

Well, I take the diff, prepend each line with > and insert my comments,
then send it back. The author then responds to that email, and once the discussion is over, I get a new proposed patch. Not much difference.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.

It's not *bad*, but for a lot of our workflows, it's the wrong tool
because the use cases it was designed for are different from ours, and
there is little we can do to make them meet.

Debian's workflow for collaboration on things that are not yet
release-ready is clunky to the point that almost no one uses it that
way, but in principle it is there: one can always upload a package to experimental and get it autobuilt on the major architectures, and other
DDs can download it from there if they want to take a look at it.

This workflow is what packaging in git mostly replaces: in
pkg-electronics, we quite often have changes that are not ready for
release that we want to distribute to the other team members. Quite
often, these changes do not build straight away, and the reason they are
shared is specifically so other people can take a look at them.

Git is a lot better for fostering this collaboration than uploads to experimental, because we get change tracking for individual files, which
is invaluable when dealing with a behemoth like ghdl that takes a few
hours to build and run tests.

The review process still takes place via mail here, because part of the
process is that everyone involved needs to be able to build the package
locally and investigate failures. We can quickly incorporate changes
from others using git and do a minimal rebuild locally, that is useful,
but this essentially means that we are pushing commits to an offside branch.

Attaching the discussion to individual changes is not that useful for us:

1. changing an annotated line in a commit hides the annotation when
looking at another commit, so the entire discussion would need to take
place in the "all changes" view, or we risk losing context.

2. a lot of the discussion is "things that will need to be changed", not "things that have been changed and we don't like it." GitLab does not
have a workflow for discussing that as part of a MR.

In that process, CI would only tell us that the package fails to build,
but we already know that: that's why we shared it in this way. If it
worked, we would have uploaded it already. Trying to build it in CI is a
waste of four hours of CPU time, and we iterate a lot faster than that
usually because we do incremental builds in between, and a full build
inside pbuilder only as part of the final upload procedure.

After an upload is done, the discussion and intermediate stages become
less useful for us, so GitLab's approach of isolating them in the MR is acceptable from my point of view, even if other people would like to
have them archived in the mailing list archive so it is easily
accessible to search engines.

Also, we usually get build failures from ports, which is kind of
unavoidable because CI testing everywhere is prohibitively expensive,
and the high level of optimization we need to run means that we will get
bitten by target specific bugs. We cannot avoid uploading "broken"
packages, unless we integrate the autobuilder network into CI and wait
four days for jobs to finish.

What Debian does instead is to filter broken packages from reaching
testing -- this is way stricter than any CI process on Salsa can
provide, although with a longer turnaround time, because the CI
processes performed by the Debian archive software take a lot longer.

This, too, is something that Salsa cannot replicate because of the way
GitLab is designed, so it cannot supplant this process, just duplicate
some aspects of it, so we would end up with build failure reports from
two sources, in two different places.

There is likely a spot where collaborating on packages through MRs is
useful, but I'd argue that the majority of packages will either get only trivial MRs that don't require discussion, or require workflows that
cannot be easily mapped to MRs, and attempting to make the workflow fit
the tool rather than the other way around will create additional
friction here.

Simon

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

Ideally debbugs should be made non-native so that some else could
maintain the Debian package.

I'm happy to review patches that get the 2.6 branch of debbugs in shape
where it can be released into Debian again if someone wants to take that effort. I've just assumed that anyone using that package was running
unstable or running debbugs out of git.

I did not notice the release_2.6 branch before. What is the intent
with that branch? Do you want people to submit patches targeting
'master' or 'release_2.6'? How often do you plan to merge it to or
from 'master'?

The 'master' branch is still the default branch. The https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/README.md
does not mention anything about release_2.6. Should it?

I am a big fan of READMEs and recommend using them to convey guidance
to contributors (assuming you want to have contributors).

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

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:

My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian.

I agree, that's the key problem.

The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it mandated.

The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
in which areas it's poor, and it's bad e.g. because force pushes are
enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.
It makes sense that some people want to replace it with a good VCS, but I
agree that adding a good VCS only gives us two VCSes because replacing
will never happen.


--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZMRT0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh KmgP/jsmOIeZCQi8Evg0NTmOZ4JApmbXmoeYM0Jmc6q7ip5c08OHUelzsza7cetp UNF67kkhccy1SGZlQUFqQZT76olp7OXgDG/ITGUDA2hjGZXAnrDgUGMkpEaGRBM5 lQxTbVXfcZIE3MHPdxSO0qIvszyNKtHM7SFGjVVjLCE/SHthcYmE3LjLeWd7zgAd ch7Z9hY1WXuXTBL6klVTsK8KAH1dsOQCru7l3aLs2y0e5rRMixhA/iHbZmK6Hqtq au4mRrig7SEOz8kgFqB4Bn3iPvjYttCH6iCWfli+4Xo6c6NLSoHi8vNa0xzIJ8Xm hwUWuFqc+0hX+cD92AcrW/jPYqieXslGwWOJhdSeCVMbNyvx+8kC/LPIqMIr7cqS mYO7O+dEmeSt2XluP0BP4TpzdE65C2c7Tydzqq9ynNyF/fld22MOOLc2/9T7d2wT i+jDVrBOy2YeaWbcCaAr9QuEk5He9ahYJ6Ggtsk52G9dkJvtSA2sObElKZtxqFDz 8sW5zStFa3l08J3ao9jVcpQxr17E+j71EUsez7kwbe0P/NB/2/cLVlfb8csErlpo SB7m5RQVAG/et1DKSGE7QA9fmRXpApm9RHdNlm2QJeAZEmlVPORm3hgyG2OveUiC 1U25cDvFBoFksPLgDU3UBHcSWgRhYoscYd+PXItYTcsd/ToO
=lAme
-----END PGP SIGNATURE-----

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

Hello,

On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote:

PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet.

Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
history. So it sort of does this. We could make it do more.

--
Sean Whitton

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

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

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmZMgKAZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQArDD/9Jw92rfSpbMtw3j6l29jcl KZD3zE+Vv3r2k+hUzq+JcB4VQzboofGEl4TGyH5L58QOFyB3wDrTqURGJf9ORIlp VTP8p4n0ZAaRgXNZiA120Y98HfHdiEwV5Sik96EHtSci8eblomL67edN9bJD//Mk sHsls33/i6uqcCq2qJ/rxaxb93O9TABj95QyL9ohIk1QqQAnvVkq7fQv4k1bV50q DXShxpI/mSWn6DyB7XEjO+P7xDrRWyhjsphFyndSVCsfls8ZnKGJnKtDs5LcKdRD YgWPKcmPz4Ein6EYAzNBSSHaNQudJxXl0vGDb8/CPBwFMbmPOQg7PISF35GM/Jtk 0vOUotKeoP7R5P4th5tmJz4sKgeAHD52zLKxtrlzAjDWEdejcU4bwPeibk3RQYdG Yf3XvAs5ny4+ENpNUa91Dp2xJMf7hp4RMqHJKojQAwvQHN3+KPR7Nd8H7y+5Ko/u 58ilKuRJU5vSCt2tLogFCtZ3G95k8FNPqZrQYAxWLJ6qyqyZ1EG1QHQwx8eb6A/m BKwHpDGROnI8TQy6ft23qCvPvYOJENjq3QAiLg0nggQEu0DHvBmiAkCijCiz8JKu xP49DjOA5/zgABkGR0E13WSNEn/EwIk70x2SoLEB4hiOjZ+Amr3U4aiCl346wnJp tgM2BIbVQwczQAMOaG/kIQ==HRhK
-----END PGP SIGNATURE-----

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

Hello,

On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote:

You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
conduct a code review?

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian - it is currently the only platform
to conduct code reviews on in a way that has automatic testing and comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.

I have tried it out, and am happy for those maintainers that like it to
use it, but I do not want to maintain most of my packages that way.
I want people to send me patches to the BTS / project ML.

--
Sean Whitton

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

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

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmZMgHsZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQE9TD/99pFtS2KYZJV1xDlBXLTyG 9GhjD8mkoMO0KY/GuLGmqCMsWUFT17aN8xcTR6+HpM5Lg1KGe1u8sKPDD2N6l0nl 8b9+RlepORkjtZMZ9Xyjyi/xpdnezFnL/Q4YE9vX0/JAZYbcFveVdop789TKJ/Q+ a/yO+5+o4RmEZvpqT/vPlyk8HNumnBHV2hm+ShdS/FI3ruqq8/TtMkCXAYsp+qwj bD9ElJCQ7cITcgsVMm8KAlWOvH/bKurCIidbh7RuKwAlKeQYsjX/EagejHSgqmRB eT/VGuFaUzm7pMbJe0SORiocbM8zhkp2fUpvTYTCCamjwsHoS46XigjNN36579No MuO/MZ0JGI5KJ5UWlYzJxuiuQIB7Al0wb/1VARtn4Vcjr2pIx4mJEOHkNJhK7YBx drQtb4tyvLdsjYn/hNL1d3nrNEcx6+UAw7NZcBz7WOsiPP8XwaGF5D2fgkFY9Pn1 fe14E3501xb4brbhTBQpqDXjrnY959N1b6EES6Sz6uekLs35eEOS8GPhfutQ34lT 75KuN5OX+sP0QbOR7ipL9eydRwLEY197h0XpDREKK9usDZK4Hd6wwUlAy1GQ0n2T G2qve5GVrg5gX34PnRIW0PqkaVaQ1FdDNA77GWI0osYYdp/RzbTFJnklthLo8FBH eYFBWHvQm+pTXpwMpCJm+g=�0V
-----END PGP SIGNATURE-----

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

Hi,

On 5/21/24 15:54, Andrey Rakhmatullin wrote:

The Debian archive itself is a VCS, so git-maintained packaging is also a
duplication, and keeping the official VCS and git synchronized is causing
additional work for developers, which is why people are opposed to having it >> mandated.

The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
in which areas it's poor, and it's bad e.g. because force pushes are
enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.

All of these things are *also* explicit features. We need a way to
unpublish things, and mirrors only want to keep a shallow subset.

Representing the Debian archive in git would probably look like a
massive amount of submodules, because that's the only way to represent
state across multiple projects without extending it -- and extending is
a big no-no, because then we'd lose all the forge support. Submodules
cannot represent the pristine-tar branch though.

It makes sense that some people want to replace it with a good VCS, but I agree that adding a good VCS only gives us two VCSes because replacing
will never happen.

There are two axes here -- "good" and "fits the use case."

What I'm arguing is that git does not fit our use case, despite being
good, because it is designed for something else. We can make it fit our
use case by wrapping it, but then we have a choice between a thin veneer
that breaks easily as people use git commands inside a source tree, when
they should only be using gbp commands, or a completely opaque wrapper
that loses us all the git integration from third-party tools like forges.

Because git treats packaging metadata as data, no correctness of
metadata is enforced at this level. We could add this in the form of
upload hooks, but then people would start complaining that they want to
use the tools like they want. They would be wrong, but that is what
happens with leaky abstractions.

This is the exact opposite of the mandatory-debhelper debate: requiring declarative packaging (and therefore calcifying all custom sequences
into debhelper plugins) is precisely the opposite of "using git because
it is familiar" -- the benefit of using the abstraction comes from
denying access to the layer below and therefore hiding its complexity.

Simon

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

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:

Hi,

On 5/21/24 15:54, Andrey Rakhmatullin wrote:

The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it
mandated.

The Debian archive itself is a *bad* and *poor* VCS. It should be obvious in which areas it's poor, and it's bad e.g. because force pushes are enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.

All of these things are *also* explicit features. We need a way to unpublish things, and mirrors only want to keep a shallow subset.

We don't have a way to unpublish things, and force pushes I meant are
uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

Representing the Debian archive in git would probably look like a massive amount of submodules, because that's the only way to represent state across multiple projects without extending it

Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?


--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZMjFQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh vhIP/RmFc/UCvS79UkIRcM3G9nw38n7Li2rUsgauBG1nYjY4MBHugkLFUX2AG+J/ esbFKyVX29x5Jy6A38IdMs5T3+Piy1XXLdZsZwiWYc/hI0evlQd3F+lobxEl1EE9 Eia/X+DVD1K9o1eOQzFj/GPDDP1EeMy6lkcK8g7szAiURfYqrOwVidlX7f3UXDzP +0jSre6FdD+PmNHAsb0k1jY2uyCJYr4L6SFcs2tLELuzGxMTKljTtpyRRLM7O9vK zA9RwAToOfWuGj6xC0zy5t0bLrPl7eHBTIPyyVp1FixBrZyNWaUF+uOgRJETfBau qxle3QK40fHLTYrhodNCS3in6gXbzXiKuuN2YJhPJpd/tL2RojYtTB3DOFMsd4ua hgcWp8ZBjJHDHn3f6Tv6Vg1gWpUVd6SYaNxQBTXK8o0VwRbUq4rMQ4b+SS+BixCV 0vYFTOD7DU0uV2Z6TRxN0FJMedBgyIlb+zJDSZFMNS2bBgc/xXe0xx2bl2jipl+H fUel/fLTv144MmBkNAQyOPDGrxgvZfCDiyKN1GO/3QDkTlIZBeOQbYZIzuyWKgbw Mlt+KwPn77G0gQpy7uqg5FkXcvtKnZ0jg54rUVaF6PawNxVuhBGTu+W0haNz5gX0 Ojv37C2q+BfkGlSPfwaZiWCgUekcjI25w3RG68klyQDapsw7
=6F/e
-----END PGP SIGNATURE-----

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

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:

The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it mandated.

I don't follow this conclusion because the premise "the Debian archive itself is
a VCS" is as right or wrong as the statements "earth is clock" or an "ocean is a
washing machine".

Or, to put it differently, "vi $file ; cp $file $file.bak ; vi $file" is also a VCS, but an even poorer one than the Debian archive.

Just because something has some VCS like properties it doesn't make it a VCS
as in the sense as people understand it in 2024.

IMO (very few) people object using a(n official) VCS is because it would change their workflows and/or because they believe their needs are more important than our needs. And saying "the Debian archive is a VCS and that causes conflicts with another VCS" is a red herring at best, because as dak+git or dak+vim+copy shows (or gosh, using different git repos) that using several VCS is possible and
done by millions daily.


--
cheers,
Holger

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

It's not climate change nor climate crisis, it's climate disaster.

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

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmZMmdMACgkQCRq4Vgaa qhwGMQ//cuxxWki2rVTvZKYceLNVjfOa1YsIj4/6MTVZFaoQUYAtNAZ1GfoqlNEq u7rxqsqzQNts2c25rW5pf/Xuw8CQusQhQv0JPrBqx6vJme3Y/nqV/yHL/rSUlVzn Gw+SBEaI6vKYnJnYV3GHO2ZnXDeTL7aJ13DIvuf5xkEWvjUzHFKQ2BX2BBt+sxzb NbXSh3hL8zsi+XsEj7ancB+L9qN7/6Z8szeXQWf5ZQu/GazwwjbBszqvd5dIOIpp YN4/8qTXltqdM+XLQyblh/L6PWhYRk0EyzzLkSu1rOTwAZW/cbUmFECe2Nc71ASo /szZj4STLinDcSdiULxdePLZm/jjVaJAOHXWTrfyjEv+MzbxQGNfBBXWtexG9eUd 03DoxZ2zCCHY3GBbGHKcTKcDLYR9D+JPOVUw/SwRLZdhtaTbHwlUlzKw0yEDMuGG jd4C/79qLxW1xoP6o7uf2uERfKYr5x9HvZqQZRMStS/l4cQmqjiYTka3smWk7WmP f9JX11uKyJ8Iez8xjdQkmC6ydFwMXH8hFSWCZl+lBjjUdvY+P9bZ4h9yhzF4NSHj V48IH/sN8SBZUlJ1iYSlQYrdD8HrHj6eEbSN4YA/OMX+gj

On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin <wrar@debian.org> wrote:

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:

Hi,

On 5/21/24 15:54, Andrey Rakhmatullin wrote:

The Debian archive itself is a VCS, so git-maintained packaging is also a
duplication, and keeping the official VCS and git synchronized is causing
additional work for developers, which is why people are opposed to having it
mandated.

The Debian archive itself is a *bad* and *poor* VCS. It should be obvious in which areas it's poor, and it's bad e.g. because force pushes are enabled, the history is periodically truncated (though there is no easy way to get it anyway) etc.

All of these things are *also* explicit features. We need a way to unpublish
things, and mirrors only want to keep a shallow subset.

We don't have a way to unpublish things, and force pushes I meant are uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

Representing the Debian archive in git would probably look like a massive amount of submodules, because that's the only way to represent state across multiple projects without extending it

Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?

Yeah, I don't understand that either. It seems there is some
misunderstanding, the suggestion to use Salsa doesn't mean that the
current ftp servers are retired. It just means that Salsa is used for
sources, like it is already used in ~90% of the packages today as per trends.debian.net. Now, whether someone wants to make tarballs and ftp
uploads happen transparently behind the curtain in a salsa-ci job or
something like that is really orthogonal to the idea that sources need
to be stored in git.

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

"Otto" == Otto Kekäläinen <otto@debian.org> writes:

Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?

Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?

I have not done a code review of that particular patch on salsa.
I have done code reviews on salsa, many other gitlabs, and github.
I find doing a code review in a web page far more frustrating than in
email.
I appreciate other people have different experience.
Some of my experience but not all is accessibility related.

I do find that trying to put everyone into one user interface--whether
it is github or gitlab or whatever--means some people are going to be
left out.
Interfaces like email mean that people can develop their own tooling.
And for those who do and find tooling they really like that's superior
to a common UI like gitlab for *those people*.
But it's going to be inferior for people who do not spend significant
time on tooling; for those people a common web ui is going to be
superior.

And you can say that I can use my own tooling with gitlab.
That's sort of true. But then you or people like you will get
frustrated that I don't interact with your per-commit-line comments
entered in the website, or go to the website to resolve comments or
whatever.
And you'll say that if I just tried the website I'd like it.
And that won't be true, because I have, I do use it in my day job, and I
don't really like it that much.

Even so, I think it is enough better that Debian should move in that
direction.

But Otto, I would encourage you to have more compassion for people who
work with the world differently than you.
In this thread, and in the krb5 merge request we are discussing, you
really do seem to be jumping to an assumption that everyone approaches
code the same way.
And you don't appear to be taking the time to understand or value how
the people you are interacting with may deal with the world differently.

Rather than simply asking people to try out your way, I'd encourage you
to ask me and others how they deal with code and what they like about
their work flow.
I'm not going to ask you to try it out, because it probably won't work
for you.
You've found something you think is great.
But I am going to ask you to ask and listen.

I do think we should fall in on the salsa way. I think it will
generally be better overall.
I do think some of us will suffer as a result.

But there appears to be an assumption here that if we just all tried
this new thing it would be great.
I would appreciate compassion for our differences and for how that's
just not true.
There will be trade offs.

--Sam

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

Hi!

On Sun, 19 May 2024 at 20:48, Don Armstrong <don@debian.org> wrote:

On Sun, 19 May 2024, Bill Allombert wrote:

Also debbugs is a special case:
The debbugs Debian package (as opposed to the debbugs software) have never been
really maintained. I am actually one of the very few users of this package and I tried several times to get the maintainers to do a new upload but they
were clearly not interested.

It's more that I'm prioritizing spending my (very) limited Debian time
on keeping bugs.debian.org and debbugs itself working (and [very slowly] developing a new version of Debbugs with a more modern design in the
hopes that others will contribute.)

Everyone else has very limited time to contribute to Debian as well.
Therefore we all need to think about what is the most efficient
workflow.

Perhaps you could consider how you can be a force multiplier and scale
your work? You could for example add some of the recent contributors as developers or maintainers at https://salsa.debian.org/groups/debbugs-team/-/group_members so they
can review/merge/push code, and you could review all submissions at https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and
grow those contributors into co-maintainers instead of just ignoring
them?

Perhaps you can also consider optimizing your git workflows? For
example in the case of https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you
could have simply pressed "Merge" and everything would be good. Now
you decided to not use any of the support Salsa/Salsa-CI provides, you
did extra work to cherry-pick some commits (but not all), added your
extra commit to break the build and now there is new follow-up work to
be done for lapses that could have been easily avoided if Salsa-CI was enabled.. (I did submit MR!20 though, you can just merge it)

I started this thread "Salsa - best thing in Debian in recent years?"
by asking people who resist Salsa to at least try using it for a while
before criticizing it so much.

What happened in this episode is a case in point. You sit in a "local
optima" of your current workflow and are not willing to invest a bit
extra effort to get to a place where Salsa+Salsa-CI can benefit and
decrease your extra work burden. Now both you and me ended up having
to do extra work that could easily have been avoided..

Personally I like Salsa a lot, and collaboration with maintainers who
embrace Salsa is a breeze, and I feel that my limited Debian time is
relatively productive. That is all thanks to Salsa. I wish those who
are not yet using it would give it a sincere try.

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

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

SGkNCg0KT24gMjEtMDUtMjAyNCAxOjA4IHAubS4sIFNlYW4gV2hpdHRvbiB3cm90ZToNCj4+ IFBTOiBJJ3ZlIGFsd2F5cyB3b25kZXJlZCBpZiB0aGUgZGdpdCBzZXJ2ZXIgc2hvdWxkbid0 IHRyYWNrIGhpc3RvcnksIGV2ZW4gaWYNCj4+IHVwbG9hZHMgZG9uJ3QgaGFwcGVuIHZpYSBp dC4gQSBkZ2l0IGNsb25lIGNvdWxkIChzaG91bGQ/KSBhbHJlYWR5IHByb3ZpZGUNCj4+IGF2 YWlsYWJsZSBoaXN0b3J5LCBldmVuIGlmIG5vIHVwbG9hZCBoYXBwZW5lZCB2aWEgaXQgeWV0 Lg0KPiANCj4gV2VsbCwgJ2RnaXQgY2xvbmUnIGFkZHMgYSB2Y3MtZ2l0IHJlbW90ZSBwb2lu dGluZyBhdCB0aGUgbWFpbnRhaW5lcidzDQo+IGhpc3RvcnkuICBTbyBpdCBzb3J0IG9mIGRv ZXMgdGhpcy4gIFdlIGNvdWxkIG1ha2UgaXQgZG8gbW9yZS4NCg0KSHVoLiBUaGFuIG15IHdv cmtmbG93IGhpZGVzIHRoaXMuIEFsbCBJJ20gb2Z0ZW4gc2VlaW5nIGlzIGp1c3QgdGhlIHRh ciANCmNvbnRlbnQgcmVwcmVzZW50ZWQgaW4gYSBjb21taXQsIHRoZSBsYXRlc3QgRGViaWFu IHBhY2tpbmcgaW4gYW5vdGhlciANCmFuZCB0aGUgbWVyZ2Ugb2YgdGhlc2UgdHdvIChpZiBJ IHJlY2FsbCBhbmQgZGVzY3JpYmUgd2hhdCBJIHJlY2FsbCANCmNvcnJlY3RseSkuIEkgYWx3 YXlzIHRob3VnaHQgdGhhdCBkZ2l0IGNsb25lIGdlbmVyYXRlZCB0aGF0IG9uIG15IA0KY29t cHV0ZXIgaWYgdGhlcmUgd2FzIG5vIGdpdCBjb250ZW50IG9uIHRoZSBkZ2l0IHNlcnZlci4g SSdsbCB0cnkgdG8gDQpyZW1lbWJlciB0aGlzIG5leHQgdGltZSBJIHJ1biBteSBuby1jaGFu Z2VzLXNvdXJjZS1vbmx5IHVwbG9hZCBzY3JpcHQuDQoNClBhdWwNCg==

--------------dGNe6BMSnbr67Xglck8IkY1f--

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

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmZOTaQFAwAAAAAACgkQnFyZ6wW9dQqs iAf9G0ePx4DaOjgkBcC0jP9AKdc0i7G5AjlpKtcPsDtPc8Hp7TBPgmGo94ftgq+OaDft6PTSIGZo rqYIuqjKMjAexjFsro9YKfGUeRdcdz5c9exZ+7qxhDKNL5g38Pg8uVhARKTKhHS2D5RuEPaBlJa1 UZZzX/1LrKTs8zQYAsrrj54eECyCC8QxczujSDwO2XzbPSkaI8zPTRG64Z+QhBYuNnB1YiXxkPwS Z3kDS7ZOZhpggui5fy/LiWe/TPqCYAXneqDNqPiEctjbfHLu93ewwlsluq1WCOhthW2ProW/PUtE mhBTSg6Edzw+aJAcUL92BBbteoGWVq+R2SyLKJwTBQ==
=67zy
-----END PGP SIGNATURE-----

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