[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of the current state of the tag2upload discussion [and 1 more messages]



Hi Aigars,

On Sun, 2024-06-30 at 21:55 +0200, Aigars Mahinovs wrote:
> On Sun, 30 Jun 2024 at 20:49, Ansgar 🙀 <ansgar@43-1.org> 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


Reply to: