Simon Richter writes ("Re: Summary of the current state of the tag2upload discussion"):

On 6/25/24 09:38, Brian May wrote:

But like it or not mistakes can happen. e.g. somebody applies a security update to the project. And uploads it to Debian. But forgets to do a git push to salsa.

You can only call it "forgetting" to do a git push if you introduce a
policy that contributions to git-maintained packages have to be made
through git.

In fact, tag2upload avoids this *even for NMUs made outside git* !

This is because it is possible for a computer to tell that you're
overwriting someone's changes. The debian/changelog will be missing
the previous upload. This situation is detected by `dgit push`.
It's one of the extra safety catches that dgit has - one of the
reasons why using dgit for all your uploads is a good idea.

And, because tag2upload reuses much of the same implementation, this
situation is also detected by tag2upload.

So with tag2upload, you'll get an email report from the t2u server
saying that your upload failed. (Overwriting a non-git-based NMU
can't be detected locally by git-debpush because by definition the
thing you're overwriting isn't in git.)


But, with wide tag2upload adoption, things are even better:

If everyone is using tag2upload[1], we simply avoid the problem,
by avoiding the mistake. This is because git-debpush's default
behaviour is to push your *branch* as well as just the *tag*.

So the original mistake, of forgetting to push to salsa, is simply
avoided, because it's not something human needs to remember to do.


One of the design principles of both dgit and tag2upload is to try to
avoid having humans do work that can be done by computers.
Especially, avoiding humans having to check things, or remember to do
every step in a multi-stage process. These kind of tasks are often
dull, and humans are very bad at them.


So, yes, tag2upload offers an end to accidental reversion of NMUs.

Ian.


[1] Strictly speaking, if everyone is using git-debpush - the
tag2upload tag signing utility that we're providing. If you write the
tag by hand, or with some other tool, then the behaviour might be
different.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

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

On Tue, 2024-06-25 at 11:00 +0100, Ian Jackson wrote:

Simon Richter writes ("Re: Summary of the current state of the tag2upload discussion"):

You can only call it "forgetting" to do a git push if you introduce a policy that contributions to git-maintained packages have to be made through git.

In fact, tag2upload avoids this *even for NMUs made outside git* !

[...]

But, with wide tag2upload adoption, things are even better:

If everyone is using tag2upload[1], we simply avoid the problem,
by avoiding the mistake.  This is because git-debpush's default
behaviour is to push your *branch* as well as just the *tag*.

So the original mistake, of forgetting to push to salsa, is simply
avoided, because it's not something human needs to remember to do.

As far as I understand this requires:

1. Either one canonical repository on Salsa for each package to which
everyone (including non-team members for NMUs) have full access or alternatively having some tag2upload-related service having full
access.
2. In case of multiple repositories, all of them to be in sync.

What will tag2upload enforce here? Or is there some alternative
solution that works in the context of NMUs and Git repositories hosted
on Salsa?

Ansgar

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

On Sun, 30 Jun 2024 at 20:49, Ansgar 🙀 <[email protected]> wrote:

On Tue, 2024-06-25 at 11:00 +0100, Ian Jackson wrote:

Simon Richter writes ("Re: Summary of the current state of the tag2upload discussion"):

You can only call it "forgetting" to do a git push if you introduce a policy that contributions to git-maintained packages have to be made through git.

In fact, tag2upload avoids this *even for NMUs made outside git* !

[...]

But, with wide tag2upload adoption, things are even better:

If everyone is using tag2upload[1], we simply avoid the problem,
by avoiding the mistake. This is because git-debpush's default
behaviour is to push your *branch* as well as just the *tag*.

So the original mistake, of forgetting to push to salsa, is simply
avoided, because it's not something human needs to remember to do.

As far as I understand this requires:

1. Either one canonical repository on Salsa for each package to which everyone (including non-team members for NMUs) have full access or alternatively having some tag2upload-related service having full
access.
2. In case of multiple repositories, all of them to be in sync.

What will tag2upload enforce here? Or is there some alternative
solution that works in the context of NMUs and Git repositories hosted
on Salsa?

There are two interesting options here:

1. There is a non-git NMU on a package that is normally managed via git and t2u

The maintainer would need to "accept" the NMU by importing the change
into their git tree. Somehow. Presumably via dgit service. I would
expect that each git workflow will have a slightly different way of
doing this correctly which will need to be practised and documented.

2. There is a git-based NMU on a package that is normally managed via
git and t2u

- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)
- else the NMU author would have to fork the main git repo of the
package on Salsa to their own Salsa namespace and create a commit and
tag there. The NMUer would then create a pull request to the main repo
and the maintainer approving this pull request would (quite cleanly)
accept the NMU

As you can see the git repos do not *have to* be in sync, but the
Debian process of accepting a NMU already provides the path to getting
to eventual sync.

There is no way to push a tag without having some kind of repo to push
it to and you can't push just a tag without also pushing the code that
you are tagging. So there is no technical way of uploading a package
via t2u without also pushing the source to some kind of git repo (that
is readable and is being monitored by t2u).

--
Best regards,
Aigars Mahinovs mailto:[email protected]
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#

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

Hi,

On 7/1/24 04:55, Aigars Mahinovs wrote:

- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)

If we create a method with a low technical barrier for NMUing, we also
need to have a discussion about procedural expectations for that at some
point.

Like, if someone makes an NMU that solves a problem, but creates
maintenance issues down the line, is it acceptable to back that out immediately?

In a pure git workflow, it is understood that if you are not usually
involved with the project, you'd send a pull request rather than merge directly, but since we're all somehow "involved" with Debian, I'd expect
the barrier for just committing changes to other people's packages to be somewhat lower -- which may be good or bad.

- else the NMU author would have to fork the main git repo of the
package on Salsa to their own Salsa namespace and create a commit and
tag there. The NMUer would then create a pull request to the main repo
and the maintainer approving this pull request would (quite cleanly)
accept the NMU

So a NMU is more of a pull demand than a pull request? :>

There is no way to push a tag without having some kind of repo to push
it to and you can't push just a tag without also pushing the code that
you are tagging. So there is no technical way of uploading a package
via t2u without also pushing the source to some kind of git repo (that
is readable and is being monitored by t2u).

I kind of expect someone who is overenthusiastic about git to just
create a repo for me if my package isn't yet "team-maintained", and it
would be nice to define whether that is an appropriate course of action
ahead of time.

Simon

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

On Mon, Jul 01, 2024 at 01:18:58PM +0900, Simon Richter wrote:

Hi,

On 7/1/24 04:55, Aigars Mahinovs wrote:

- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)

If we create a method with a low technical barrier for NMUing, we also need to have a discussion about procedural expectations for that at some point.

Like, if someone makes an NMU that solves a problem, but creates maintenance issues down the line, is it acceptable to back that out immediately?

In a pure git workflow, it is understood that if you are not usually
involved with the project, you'd send a pull request rather than merge directly, but since we're all somehow "involved" with Debian, I'd expect the barrier for just committing changes to other people's packages to be
somewhat lower -- which may be good or bad.

I'm not sure I understand these questions correctly.
The technical barrier for NMUing is already low, and you (the maintainer)
are already expected to keep the NMU changes, the NMU changelog entry
(even if you revert the changes) and, consequently, git commits (likely
created by you from the NMU upload) that add those.


--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaCRCktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh +CoQAKOkIuAwYaerGAth5J8/+6BeuM4b8oFMeMuWRRQqE5+wB/UWEixUlcrVE8i8 h/wRj1CrW63bEicy2y0TXpU2ZZhzaajYoJPSum2y3CjkkbmK2dEVIguRSqhdCKAV uLWfpt3SPgKaecVhIxsLpWe3fatF+6TCg0b24t6+8gsz3oNMiJjF/5OsU4E2cSRo YDrz4CGnBzkRGLAcyBuW2aR5rI8vmsId078TcmCpmPTrjm8iuigOn6Lg0xmw4tQx ZXgSuhAcyjAg9Cv1kn5PBHAucFzNjEXPRJ8Kgqn67zCRTIOFdk3qw6INS25hPvp3 2A8QJg2OvLVGpfOW9Lw1BreCfsiq3HQLferpvYmMaC/mlJ63DA6/SI4KhL+B/oL5 A4PzK2kshTuHSCdxdVNPlQvdKY6WgTedgN/ckl3QjemqxZTJ5vkEkfeRdCqHVWY5 cCgCzmN8WXpfGMm3mdlrXOsrp3/W50YnDS61nxDTj+IOQLxJC3DaP+Ga98ZDdmI/ ZT5H+tRYK7KNmn02Fmt8go3XmdySo3fU0WCYalt5l8ZLT9sqzq7UdAE7M8cw8ZOT CLqHh1xuRVwsWz0Z7jvHVIO1iTfjF3UDEVWdUVos0YTvN+NPkwohxD9+j3VoNwSU DDDiF3NpgJpOpb66v7t5/Cp05/sebi1cFAdvJgqL4rkHfWw1
=xVpT
-----END PGP SIGNATURE-----

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

Hi Aigars,

On Sun, 2024-06-30 at 21:55 +0200, Aigars Mahinovs wrote:

On Sun, 30 Jun 2024 at 20:49, Ansgar 🙀 <[email protected]> wrote:

On Tue, 2024-06-25 at 11:00 +0100, Ian Jackson wrote:

Simon Richter writes ("Re: Summary of the current state of the tag2upload discussion"):

You can only call it "forgetting" to do a git push if you introduce a policy that contributions to git-maintained packages have to be made through git.

In fact, tag2upload avoids this *even for NMUs made outside git* !

[...]

But, with wide tag2upload adoption, things are even better:

If everyone is using tag2upload[1], we simply avoid the problem,
by avoiding the mistake.  This is because git-debpush's default behaviour is to push your *branch* as well as just the *tag*.

So the original mistake, of forgetting to push to salsa, is simply avoided, because it's not something human needs to remember to do.

As far as I understand this requires:

1. Either one canonical repository on Salsa for each package to which everyone (including non-team members for NMUs) have full access or alternatively having some tag2upload-related service having full
access.
2. In case of multiple repositories, all of them to be in sync.

What will tag2upload enforce here? Or is there some alternative
solution that works in the context of NMUs and Git repositories hosted
on Salsa?

There are two interesting options here:

1. There is a non-git NMU on a package that is normally managed via git and t2u

That seems unrelated to my mail.

2. There is a git-based NMU on a package that is normally managed via
git and t2u

- if the NMU author has access to the main git repo of the package on
Salsa they can make a commit and tag there (normal team-like
maintenance)

The claim in the mail I responded to claims one cannot forget to push
the repository to the changes are visible to the maintainer. This seems
only true if the regular maintainer also (a) knows about the repository
and (b) their workflow involves integrating changes from there.

NMU authors often don't have access to the maintainer's repository.

- else the NMU author would have to fork the main git repo of the
package on Salsa to their own Salsa namespace and create a commit and
tag there. The NMUer would then create a pull request to the main repo
and the maintainer approving this pull request would (quite cleanly)
accept the NMU

No, the NMU author could also just create a new repository (not forked)
and push the changes there.

Anyway, will git-debpush automatically open this MR so the NMUer
doesn't forget doing so? Will t2u enforce a forked repository of the
canonical repository is used so a MR can be opened at all? (AFAIU
GitLab requires that fork relation and one cannot add it afterwards.)

As you can see the git repos do not *have to* be in sync, but the
Debian process of accepting a NMU already provides the path to getting
to eventual sync.

Yes, by manually integrating changes. The claim was that t2u improves
this, in particular for NMU uploads (where the uploader often does not
have write access to the maintainer's Git repository).

Your answer seems to be that nothing changes and the same mistakes that
t2u claims to solve will still happen with it?

There is no way to push a tag without having some kind of repo to push
it to and you can't push just a tag without also pushing the code that
you are tagging. So there is no technical way of uploading a package
via t2u without also pushing the source to some kind of git repo (that
is readable and is being monitored by t2u).

Yes, but with Git being a *distributed* version control system, this
doesn't have to be the same repository that the maintainer uses. So how
does this improve anything over the current workflow?

Ansgar

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