[Feel free to quote any part of this email which I wrote outside of this mailinglist]
Debian packages need to be well maintained. In some cases, having
multiple maintainers on a package improves the resulting quality of
packages. But in some other cases, it does not; one example for this
second case is my package "logtool", which I'm going to upload to fix #1066251 soon and for which by the simple act of doing that I will
double the amount of uploads it's seen in the past five years (and the
number of uploads in the past 10 can still be counted on the fingers of
a single hand).
This is not because it's not well maintained; it's because the package
just *does not require* a lot of work to be kept up to date: upstream
has not been active for over 20 years, but it still performs the job it
was designed to do, as it was designed to, and I see no need to have it removed from the archive.
A second good example is my package "nbd".
Similarly, the fact that a package has a "team" listed as its maintainer
not in any wayimply that the team has more than zero members.
If there are stupid barriers to helping people out by doing NMUs or
taking over packages, then by all means let's break down those barriers.
But let's not try to "fix" a problem by introducing a rule that is, at
best, affecting something only very weakly related to the problem that
we are trying to solve.
What is your opinion about pushing logtool to Salsa?
I did that as part of my latest upload :)
https://salsa.debian.org/wouter/logtool
(I realize now that I forgot to add VCS headers... ah well, next time
I'm sure)
And that's not good, and we should work on those.
I just don't think that mandating team maintenance drops those barriers.
Hi Wouter,
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
[Feel free to quote any part of this email which I wrote outside of this mailinglist]
OK, moving the discussion to debian-devel where it should belong.
Debian packages need to be well maintained. In some cases, having
multiple maintainers on a package improves the resulting quality of packages. But in some other cases, it does not; one example for this
second case is my package "logtool", which I'm going to upload to fix #1066251 soon and for which by the simple act of doing that I will
double the amount of uploads it's seen in the past five years (and the number of uploads in the past 10 can still be counted on the fingers of
a single hand).
This is not because it's not well maintained; it's because the package
just *does not require* a lot of work to be kept up to date: upstream
has not been active for over 20 years, but it still performs the job it
was designed to do, as it was designed to, and I see no need to have it removed from the archive.
What is your opinion about pushing logtool to Salsa?
If there are stupid barriers to helping people out by doing NMUs or
taking over packages, then by all means let's break down those barriers.
I was sometimes confronted with those barriers.
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
[Feel free to quote any part of this email which I wrote outside of this mailinglist]
OK, moving the discussion to debian-devel where it should belong.
<snip example>Debian packages need to be well maintained. In some cases, having
multiple maintainers on a package improves the resulting quality of packages. But in some other cases, it does not;
I am all for reducing the barrier to doing NMUs. Let's look at
that; it's ridiculous that we need to ask permission to help
someone else with maintaining packages if it's clear that they can
use it. Debian as a whole is a team, and we maintain the
distribution together. So when I do an NMU for your stuff, I'm
here to help. You should be happy when I'm offering to help; and
that's even enshrined in the code of conduct:
[...] offers for help should be seen in the context of our shared
goal of improving Debian
The fact that a package is listed as maintained by a person rather
than a team does not mean the person is the only person who is
responsible for that package. Debian as a whole is. And the
release team is, in the context of deciding what happens with a
package that has outstanding RC bugs. And the QA team is, when
they run full-archive test rebuilds for new things. And our users
are, when they file bugs.
If there are stupid barriers to helping people out by doing NMUs or
taking over packages, then by all means let's break down those barriers.
But let's not try to "fix" a problem by introducing a rule that is, at best, affecting something only very weakly related to the problem that
we are trying to solve.
I would be happy to talk about rules that might help solving problems
(as well as droping rules that are creating barriers).
I think that's a mistake, and I'm not a fan. Because so far as I canI started using git quite late and spent really a lot of time trying to understand how it fit in my quilt workflow (I loved quilt), but in the
tell 'use salsa' actually means 'maintain your packages in git'. So
far as I can see it is not possible to use our existing 'uscan, patch, sbuild, dupload' type workflows with Salsa. And that's why I'm not
using it, and don't want to be made to use it.
Hi Wouter,
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
[Feel free to quote any part of this email which I wrote outside of this mailinglist]
OK, moving the discussion to debian-devel where it should belong.
Debian packages need to be well maintained. In some cases, having
multiple maintainers on a package improves the resulting quality of packages. But in some other cases, it does not; one example for this
second case is my package "logtool", which I'm going to upload to fix #1066251 soon and for which by the simple act of doing that I will
double the amount of uploads it's seen in the past five years (and the number of uploads in the past 10 can still be counted on the fingers of
a single hand).
This is not because it's not well maintained; it's because the package
just *does not require* a lot of work to be kept up to date: upstream
has not been active for over 20 years, but it still performs the job it
was designed to do, as it was designed to, and I see no need to have it removed from the archive.
What is your opinion about pushing logtool to Salsa?
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
Most of the actual packager work is not reflected in the source
package. Testing that the package integrates well with the rest of
Debian,
replying to bug reports,
communicating with upstream etc.
I maintain a number of packages. Some are on Salsa, some are not, some are team
maintained, some are not, some use dh, some use debhelper etc.
This is a matter of efficiency, one size does not fit all.
On 2024-04-07 16:04 +0200, Andreas Tille wrote:
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:Good plan.
[Feel free to quote any part of this email which I wrote outside of this mailinglist]OK, moving the discussion to debian-devel where it should belong.
The fact that a package is listed as maintained by a person rather than a team does not mean the person is the only person who is responsible for that package. Debian as a whole is. And the release team is, in the context of deciding what happens with a package that has outstanding RC bugs. And the QA team is, when they run full-archive test rebuilds for new things. And our users are, when they file bugs.
So I agree with everything Wouter said in this mail. I'm keen on
changing the _culture_ to make it easier to just fix things.
But Andreas seems to have taken this idea of 'we should make it easier
to help people maintain packages', and conflated it with 'everyone has
to use salsa' and 'everything should be team maintained'.
I think that's a mistake, and I'm not a fan. Because so far as I can
tell 'use salsa' actually means 'maintain your packages in git'. So
far as I can see it is not possible to use our existing 'uscan, patch, sbuild, dupload' type workflows with Salsa. And that's why I'm not
using it, and don't want to be made to use it.
But I am _not_ against people helping me fix my stuff - I'm on the
'just NMU my packages - I won't bite' list.
As I said elsewhere:
For me Salsa is just one more thing to deal with. It is useful if you
need to share a package _before_ it is uploaded, but mostly it's just
a load of extra stuff I didn't want or need (git, web-interfaces, certificates). And when I _do_ have to deal with it it takes a lot of
extra time and effort I would prefer to have spent elsewhere.
I have a workflow I am quite happy with (uscan, meld, quilt, sbuild, dupload). I've tried various fancy new things (salsa, git, dgit) but
mostly I've found they got in the way (and delayed uploads/wasted
time) rather than made my life easier, so I keep going back to the old
way because it just works.
I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
enjoy seeing 'packages must be in Salsa' made a requirement, for
example.
Dgit almost solves this problem but is backwards from my POV. It lets
the git people pretend that they still use quilt and tarballs so the interface remains compatible (excellent). But it doesn't let the
tarball people expose an interface to keep the git people happy (SFAIK - you can't do a dgit upload unless you have a git repo) which is a pity - I'd be fine doing doing 'dgit upload' instead of 'dupload' for compatibility purposes.
Then there is salsa... I have mixed feelings about it. On the one hand, it's this big beast with tons of javascript and apparently we are not even dog-fooding gitlab as packaged in Debian to overseves. I'd like our infrastructure to be based on the things we offer in our distro. And it's just
so much javascript... I cannot open a build log in the browser without it just
vanishing before my eyes with an error message in red at the top. My computer is slow (ARM Cortex A53) and this does not play well with it. I wish there was
a way to interact with it from my terminal instead of having to click on buttons in a very slow web interface.
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
Hi Wouter,
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
[Feel free to quote any part of this email which I wrote outside of this >> > mailinglist]
OK, moving the discussion to debian-devel where it should belong.
Debian packages need to be well maintained. In some cases, having
multiple maintainers on a package improves the resulting quality of
packages. But in some other cases, it does not; one example for this
second case is my package "logtool", which I'm going to upload to fix
#1066251 soon and for which by the simple act of doing that I will
double the amount of uploads it's seen in the past five years (and the
number of uploads in the past 10 can still be counted on the fingers of
a single hand).
This is not because it's not well maintained; it's because the package
just *does not require* a lot of work to be kept up to date: upstream
has not been active for over 20 years, but it still performs the job it
was designed to do, as it was designed to, and I see no need to have it
removed from the archive.
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
enjoy seeing 'packages must be in Salsa' made a requirement, for
example.
We are not missing it.I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
enjoy seeing 'packages must be in Salsa' made a requirement, for
example.
What people seem to be missing is that the Debian archive *is* a version control system.
Stacking another VCS on top of it leads to a lot of annoying artifacts, because there is no sensible metadata mapping between them -- what is metadata in Debian becomes data in git, and another metadata layer is added on top of that, and what is data in Debian must be run through a filter to make it accessible to git for efficient handling, so part of it gets converted to metadata.We know, and we are sad about this, but we see the benefits it brings so
The result is... not ideal, because the resulting workflow is neither a Debian nor a git workflow, but a mix that requires users to be aware of the state of two systems at the same time.
Testing a package requires me to commit everything into git first, so IAt least gbp doesn't require anything like this (unless your "testing"
have to remember to squash all these commits later.\
What would make sense would be a git based format that is designed aroundWe know. It was rejected as Debian doesn't want to store random data as a
the requirements for package maintenance, and where internal consistency can be enforced by upload hooks -- for example by storing metadata out-of-band
in a separate branch.
I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
- What does that web interface have that people don't like?
Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
On 07/04/24 23:11, Bill Allombert wrote:
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
As a contributor, having a package on salsa is extremely useful, far from "useless".
By clicking on "fork" (or running the equivalent CLI command) I get a copy of the package, with all its history, a Debian-specific CI, the ability to work on different features or bug fixes at the same time and independently from one another, the possibility to send a merge request, that can be annotate line-by-line by all other Debian contributors.
A package with a repo on salsa is sending a clean message: go away, I don't want your contribution.
I suppose you meant _without_. The message is not "your contribution is
not wanted" but rather "your contribution is not needed because there
nothing to do".
They are hundred of other packages where your contribution would
make a difference.
Simple packages need someone who is responsible and responsive for them
in the long run and know there history much more than needing sporadic contributions.
On 07/04/24 23:11, Bill Allombert wrote:
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
As a contributor, having a package on salsa is extremely useful, far from "useless".
By clicking on "fork" (or running the equivalent CLI command) I get a copy
of the package, with all its history, a Debian-specific CI, the ability to work on different features or bug fixes at the same time and independently from one another, the possibility to send a merge request, that can be annotate line-by-line by all other Debian contributors.
A package with a repo on salsa is sending a clean message: go away, I don't want your contribution.
Simple packages need someone who is responsible and responsive for...right up until the point where that "bus factor of 1" moves
them
in the long run and know there history much more than needing
sporadic
contributions.
on/changes priorities/changes job/etc and the package is abandoned. Fortunately that never happens, though!
Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
On 07/04/24 23:11, Bill Allombert wrote:
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
As a contributor, having a package on salsa is extremely useful, far from "useless".
By clicking on "fork" (or running the equivalent CLI command) I get a copy of the package, with all its history, a Debian-specific CI, the ability to work on different features or bug fixes at the same time and independently from one another, the possibility to send a merge request, that can be annotate line-by-line by all other Debian contributors.
A package with a repo on salsa is sending a clean message: go away, I don't want your contribution.
I suppose you meant _without_. The message is not "your contribution is
not wanted" but rather "your contribution is not needed because there
nothing to do".
They are hundred of other packages where your contribution would
make a difference.
Simple packages need someone who is responsible and responsive for them
in the long run and know there history much more than needing sporadic contributions.
On 17194 March 1977, Luca Boccassi wrote:
Simple packages need someone who is responsible and responsive for...right up until the point where that "bus factor of 1" moves
them
in the long run and know there history much more than needing
sporadic
contributions.
on/changes priorities/changes job/etc and the package is abandoned. Fortunately that never happens, though!
And interestingly, this does NOT need required team maintainance. It
does NOT need "package must be in git". It does NOT need "package must
be on salsa".
It "only" needs good procedures in taking over maintainership of
abandoned packages. And hey, for clearly abandoned packages, we have
that, and it works.
The problem is with people who are *not* clearly gone. Who are around
and block changes to "my package, my way, i ignore all outside wishes".
Or who are around and work against project wishes, in some way. And no
amount of "force a team on everyone" and no amount of "you must use
salsa" will solve this problem. While creating problems elsewhere.
I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
- What does that web interface have that people don't like?
Testing a package requires me to
commit everything into git first, so I have to remember to squash all these commits later.
And of course git can emulate the other workflow using git-worktree.And I do just prefer having two directories rather than multiple
version on top of each other. My simple brain finds it a lot easier to
keep track of a version directory to diff between, rather than finding
the right runes to get git to give meld faked-up directories pointing
at revisions or branches.
I found this paragraph really interesting because reading your other emails I was wondering "well but how else do you do it then??" :D Maybe this is just muscle memory? Your directories are just my git branches. Instead of "cd ../source-verX" I'd do "git switch verX". Personally, I find git branches superior to directories because the git commit messages in each branch allow me
to describe what this feature-branch is doing much better than a directory name
could. A stack of commits in a branch allows me to trace back what changes I did in what order when I worked on a feature. By pushing the branches to salsa,
I enable collaboration on my work by doing not much more than running "git push
--set-upstream origin myfeature".
On 2024-04-08 21:44 +0900, Simon Richter wrote:
Testing a package requires me to commit everything into git first, so I have to remember to squash all these commits later.Right - this was (one of the) main thing(s) that annoyed me enough to just go back to the non-git based workflow. I want to make changes and try them. I don't want to have to commit every damn time - it's not done yet - I'll commit it after I'm satisfied that it works. But I don't know that until I've made a whole set of changes and it builds.
So now I've got a pile of changes which should really be separate commits and logically separate things often affect the same files, and even the same lines, so really I need to commit some chunks and not others and tidy it all up. Yes this makes a nice set of commits but it's _so_ much work in comparison to just editing the damn files, and then effectively doing one fat 'commit' when I dupload. Often something ends up stalled for weeks or months or years because I've got some chunks in the wrong places and sorting it out is painful, so I go do something else and lose all my state. You all know how that goes...
I realise this (like my previous message) will result in a load of people telling me git _is_ better and I'm just doing it wrong, or should learn better tools. And they may even be right, (and I will probably learn some things from this thread), but I don't believe the goal we agree on (fixing other people's packages should be culturally accepted) _requires_ this change in tooling (which is a heavy cost for at least some of us).
Also what do you git people do to replace uscan? Currently I go to my existing version, or a newly-acquired apt get or dget source. I do 'uscan' and if there is a new upstream version I have a nice separate directly that is easy to dirdiff (then fixup any packaging and dupload). If there isn't I can move on.
And I do just prefer having two directories rather than multiple
version on top of each other. My simple brain finds it a lot easier to
keep track of a version directory to diff between, rather than finding
the right runes to get git to give meld faked-up directories pointing
at revisions or branches.
I do understand the argument that lots of different workflows adds friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review.
Josch's suggestion that just recording the workflow in metadata would be useful is a good one. Then at least you know what other maintainers are doing. And dgit's approach of unifying the archive representation and the git representation is definitely progress in the right direction. I was very sad to find that it didn't help us 'tarball people' directly at all (except I guess to reduce exactly this pressure to stop doing it and use git).
So why mandate salsa rather than make dgit more official? That lets the people that want to use git use it for everything - even the packages that were just uploaded as tarballs. And explicitly _doesn't_ remove the archive VCS interface. And it supports all the git-based workflows. (someone should probably tell IWJ this conversation is occuring as he's taken a bit intererest in it, but no longer reads debian-devel). Does than not solve a good chunk of this 'make it easy to fix other packages using your standard tools' desire?
Right - this was (one of the) main thing(s) that annoyed me enough toAgain, you don't need to commit anything to test it, so you can use
just go back to the non-git based workflow. I want to make changes and
try them. I don't want to have to commit every damn time - it's not
done yet - I'll commit it after I'm satisfied that it works. But I
don't know that until I've made a whole set of changes and it builds.
So now I've got a pile of changes which should really be separate
commits and logically separate things often affect the same files, and
even the same lines, so really I need to commit some chunks and not
others and tidy it all up. Yes this makes a nice set of commits but
it's _so_ much work in comparison to just editing the damn files, and
then effectively doing one fat 'commit' when I dupload. Often
something ends up stalled for weeks or months or years because I've
got some chunks in the wrong places and sorting it out is painful, so
I go do something else and lose all my state. You all know how that
goes...
Also what do you git people do to replace uscan?gbp import-orig --uscan
git world seems to make this way more complicated. I have to set upYou don't need to do that, you can't do that with upstreams that don't use
two different repos - one for salsa one for upstream, then pull them,
maybe into different branches, and fight the diff config to let me
dirdiff two different commits. And the upstream pull will always pull changes, not just only do it is there is an actual release (tag).
...right up until the point where that "bus factor of 1" moves
on/changes priorities/changes job/etc and the package is abandoned. Fortunately that never happens, though!
So why mandate salsa rather than make dgit more official?
On 2024-04-08 21:44 +0900, Simon Richter wrote:
Testing a package requires me to
commit everything into git first, so I have to remember to squash all these commits later.
Right - this was (one of the) main thing(s) that annoyed me enough to
just go back to the non-git based workflow. I want to make changes and
try them. I don't want to have to commit every damn time - it's not
done yet - I'll commit it after I'm satisfied that it works. But I
don't know that until I've made a whole set of changes and it builds.
So now I've got a pile of changes which should really be separate
commits and logically separate things often affect the same files, and
even the same lines, so really I need to commit some chunks and not
others and tidy it all up. Yes this makes a nice set of commits but
it's _so_ much work in comparison to just editing the damn files, and
then effectively doing one fat 'commit' when I dupload. Often
something ends up stalled for weeks or months or years because I've
got some chunks in the wrong places and sorting it out is painful, so
I go do something else and lose all my state. You all know how that
goes...
I realise this (like my previous message) will result in a load of
people telling me git _is_ better and I'm just doing it wrong, or
should learn better tools. And they may even be right, (and I will
probably learn some things from this thread), but I don't believe the
goal we agree on (fixing other people's packages should be culturally accepted) _requires_ this change in tooling (which is a heavy cost for
at least some of us).
The point here is that 'requiring salsa' is actually code for 'no,
you can't just use the tarball-based VCS any more - you have to use
git'. Removing that interface is a very big deal - it has served
quite well for 30 years. Yes it old-fashioned and crufty and
(presumably) only a minority still use it as the primary interface,
but any GR on this should acknowledge what we are requiring of people
still using it, not just frame this as 'and add salsa'. It's more
fundamental than that (or I am misunderstanding)..
Also what do you git people do to replace uscan? Currently I go to my existing version, or a newly-acquired apt get or dget source. I do
'uscan' and if there is a new upstream version I have a nice separate directly that is easy to dirdiff (then fixup any packaging and
dupload). If there isn't I can move on.
git world seems to make this way more complicated. I have to set up
two different repos - one for salsa one for upstream, then pull them,
maybe into different branches, and fight the diff config to let me
dirdiff two different commits. And the upstream pull will always pull changes, not just only do it is there is an actual release (tag).
None of that feels like an improvement over 'uscan'. One word for the standard process of updating to a new version. And if the patches
still apply it's probably all done (I always do a meld review too to
see what changed).
If someone can make a tool so that this workflow still works, but a
copy gets dumped into salsa, then I don't mind this new
requirement. But otherwise it seems like a big imposition.
I do understand the argument that lots of different workflows adds
friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review.
Josch's suggestion that just recording the workflow in metadata would
be useful is a good one. Then at least you know what other maintainers
are doing. And dgit's approach of unifying the archive representation
and the git representation is definitely progress in the right
direction. I was very sad to find that it didn't help us 'tarball
people' directly at all (except I guess to reduce exactly this
pressure to stop doing it and use git).
So why mandate salsa rather than make dgit more official? That lets
the people that want to use git use it for everything - even the
packages that were just uploaded as tarballs. And explicitly _doesn't_
remove the archive VCS interface. And it supports all the git-based workflows. (someone should probably tell IWJ this conversation is
occuring as he's taken a bit intererest in it, but no longer reads debian-devel). Does than not solve a good chunk of this 'make it easy
to fix other packages using your standard tools' desire?
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian only,
which also is a barrier for some.)
- I love autopkgtests.
- I hardly every look at the autopkgs logs on salsaci, cause I find
them incomprehensible and the javascript "UX" makes me wanna chop wood.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership. Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
I only use salsa's git. That begs two questions:If you are owner of a team repository you need to manage members. As
- What do I miss by not using the web interface?
far as I know this is only possible via web interface (I did not checked
glab since I just learned in this thread about is existence.)
On 2024-04-08 21:44 +0900, Simon Richter wrote:
Testing a package requires me toRight - this was (one of the) main thing(s) that annoyed me enough to
commit everything into git first, so I have to remember to squash all these commits later.
just go back to the non-git based workflow. I want to make changes and
try them. I don't want to have to commit every damn time - it's not
done yet - I'll commit it after I'm satisfied that it works.
The point here is that 'requiring salsa' is actually code for 'no,
you can't just use the tarball-based VCS any more - you have to use
git'.
Josch's suggestion that just recording the workflow in metadata would
be useful is a good one.
Right - this was (one of the) main thing(s) that annoyed me enough to
just go back to the non-git based workflow.
try them. I don't want to have to commit every damn time - it's not
done yet - I'll commit it after I'm satisfied that it works. But I
don't know that until I've made a whole set of changes and it builds.
So now I've got a pile of changes which should really be separate
commits and logically separate things often affect the same files, and
even the same lines, so really I need to commit some chunks and not
others and tidy it all up. Yes this makes a nice set of commits but
it's _so_ much work in comparison to just editing the damn files, and
then effectively doing one fat 'commit' when I dupload.
Sometimes git is useful - I do use it quite intensively for things
where it actually helps (complicated cave survey datasets with
hundreds of entangled commits that need re-ordering). For the vast
majority of my debian packaging it's just makework.
I realise this (like my previous message) will result in a load of
people telling me git _is_ better and I'm just doing it wrong, or
should learn better tools. And they may even be right, (and I will
probably learn some things from this thread), but I don't believe the
goal we agree on (fixing other people's packages should be culturally accepted) _requires_ this change in tooling (which is a heavy cost for
at least some of us).
The point here is that 'requiring salsa' is actually code for 'no,
you can't just use the tarball-based VCS any more - you have to use
git'. Removing that interface is a very big deal - it has served
quite well for 30 years. Yes it old-fashioned and crufty and
(presumably) only a minority still use it as the primary interface,
but any GR on this should acknowledge what we are requiring of people
still using it, not just frame this as 'and add salsa'. It's more
fundamental than that (or I am misunderstanding)..
Also what do you git people do to replace uscan?
Currently I go to my
existing version, or a newly-acquired apt get or dget source. I do
'uscan' and if there is a new upstream version I have a nice separate directly that is easy to dirdiff (then fixup any packaging and
dupload). If there isn't I can move on.
git world seems to make this way more complicated. I have to set up
two different repos - one for salsa one for upstream,
then pull them,
maybe into different branches,
and fight the diff config to let me
dirdiff two different commits. And the upstream pull will always pull changes, not just only do it is there is an actual release (tag).
None of that feels like an improvement over 'uscan'. One word for the standard process of updating to a new version. And if the patches
still apply it's probably all done (I always do a meld review too to
see what changed).
And I do just prefer having two directories rather than multiple
version on top of each other. My simple brain finds it a lot easier to
keep track of a version directory to diff between, rather than finding
the right runes to get git to give meld faked-up directories pointing
at revisions or branches.
If someone can make a tool so that this workflow still works, but a
copy gets dumped into salsa, then I don't mind this new
requirement. But otherwise it seems like a big imposition.
I do understand the argument that lots of different workflows adds
friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review.
Josch's suggestion that just recording the workflow in metadata would
be useful is a good one. Then at least you know what other maintainers
are doing. And dgit's approach of unifying the archive representation
and the git representation is definitely progress in the right
direction. I was very sad to find that it didn't help us 'tarball
people' directly at all (except I guess to reduce exactly this
pressure to stop doing it and use git).
So why mandate salsa rather than make dgit more official? That lets
the people that want to use git use it for everything - even the
packages that were just uploaded as tarballs. And explicitly _doesn't_
remove the archive VCS interface. And it supports all the git-based workflows. (someone should probably tell IWJ this conversation is
occuring as he's taken a bit intererest in it, but no longer reads debian-devel). Does than not solve a good chunk of this 'make it easy
to fix other packages using your standard tools' desire?
I do understand the argument that lots of different workflows adds friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review.
I agree that different workflows are not helpful. We have DEP14[1]
... but we have no efficient processes to
a) accept DEPs
b) dedicate to accepted DEPs
we need both. Domain specific knowledge is clearly very important and I'm not trying to argue against it. But doing packaging in a way such that it becomes easy for others to contribute is *also* every important. As the maintainer of a
package with expert knowledge of it you might think that there is nothing to do
but you while you are the expert for that package, you might not be the expert
on topics like cross building, reproducible builds, multiarch, build profiles,
merged-/usr, build hardening and many other topics which span the whole distribution. There are people who are heavily invested in these topics and who
will want to touch very many packages to fix things. It should be made easy for
them to make these contributions without them bit-rotting as a patch in the BTS
for months or years. I'm not saying that *you* let these contributions bit-rot.
This is meant as a general argument for making it easier to make large-scale changes to packages. Diversity in our packaging styles and strong package ownership sometimes work contrary to issues affecting very many packages across
our distro.
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian only,
which also is a barrier for some.)
- I love autopkgtests.
- I hardly every look at the autopkgs logs on salsaci, cause I find
them incomprehensible and the javascript "UX" makes me wanna chop wood.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership. Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian only,
which also is a barrier for some.)
- I love autopkgtests.
- I hardly every look at the autopkgs logs on salsaci, cause I find
them incomprehensible and the javascript "UX" makes me wanna chop wood.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership. Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:[...]
I agree with everything you say here!
Wrt git-buildpackage, I'd like to add that personally, I respect the gbp authors and maintainers and it's a very useful tool to bring together
some complex workflows and in particular successfully move a lot of
people over from svn-buildpackage.
I do however agree that there's too much magic. Some of that is
inherited from the Debian-specific tooling it sits on top of: I also
think there's too much magic and/or complexity in debuild and dpkg-buildpackage.
Asking maintainers "to use git" means: please push your changes, even
those unreleased to a public git repository (salsa, github, codeberg,
your own domain...), so other people can contribute 1) knowing that they
are working against the same sources the maintainer has on their hard
drive, and 2) using git-based workflows.
dgit is both a Web interface to browse git repositories as wells as a
system to access the Debian archive as if it were a git repository, so
you can "dgit push" a branch and have the resulting binary uploaded to
the archive. (Yes, I'm simplifying here, but that's the gist.)
Salsa is a forge, i.e. a combination of a Web interface, a git server,
and a set of integrated features. In comparison to dgit, salsa has, like
most forges:
* Merge requests: where people can suggest changes and discuss them with >line-based comments (accessible via email, no need to use the Web interface)
* Continuous integration pipelines: as soon as you push a commit,
Salsa-CI will try to build a package, cross build it, test it against >piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI >developers).
* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla,
but funnily enough not BTS).
* Project specific wikis, snippets, Docker images.
* And with tag2upload salsa fulfills 50% of dgit functionality.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership.
Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
Also regarding gbp, my packaging workflow does not require it >(debian/-folder-only in Git). Being enforced to use some other pkg'ing
style would reduce my fun and end up with less productivity, I fear.
The gbp workflow has its pros, but for me it is a too complex overhead >without much gain to the end result (the uploaded package).
On Fri, 12 Apr 2024 09:26:10 +0000, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Also regarding gbp, my packaging workflow does not require it
(debian/-folder-only in Git). Being enforced to use some other pkg'ing
style would reduce my fun and end up with less productivity, I fear.
The gbp workflow has its pros, but for me it is a too complex overhead
without much gain to the end result (the uploaded package).
The debian/-only layout was quite common in the svn days and back then
we had adequate tooling to support that but those tools have rotted
away, it feels unnatural to me, and, frankly, exim's debian/-only
layout (that I introduced myself fifteen^wtwenty years ago) is the
main reason why I am a mostly inactive member on the exim team since I
still don't know any more how to properly build the package.
'Require' is probably the wrong word. I simply have heard from several >potential young contributors that they feel blocked by the tooling and >specifically not everything in Git.
then pull them,
maybe into different branches,
git-buildpackage maintains two or three branches: The main packaging
branch and an upstream branch. The pristine-tar branch is optional (but >default in the teams I'm working in)
Hi,
On 13.04.24 00:19, Marc Haber wrote:
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.
That does not only apply to young contributors. I am an old fart and I still shy back from packages where I need to familiarize myself with
an uncommon packaging toolchain.
We cannot help people who want Debian packaging to work like Git,
because Git is not a packaging tool, and neither are the forges.
We're not even doing anyone a favour by introducing the git based
workflows first, because about half of the techniques people know from
git will conflict with something git-buildpackage or dgit does, and
without a mental model of how Debian packaging is supposed to work standalone, they have no chance of solving even the simplest problem.
For example, any repository that does not list debian/files and debian/*.substvars in the gitignore will fail to build twice in a row, because these files are created and are subsequently untracked. Only
Debian packaging knowledge can tell you that these should never be
checked in and can be ignored -- or we make people reliant on a magic
tool to set it up properly for them.
Once people are familiar with how Debian packaging works, we can
introduce the git interfaces on top. Before that, git is more of a
hindrance than a benefit to new contributors, precisely because it looks familiar, but the knowledge is not transferable.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership. Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
For example, any repository that does not list debian/files and debian/*.substvars in the gitignore will fail to build twice in a row, because these files are created and are subsequently untracked.
Once people are familiar with how Debian packaging works, we can introduce the git interfaces on top. Before that, git is more of a hindrance than a benefit to new contributors, precisely because it looks familiar, but the knowledge is not transferable.this as a general rule.
From my mentoring work I can confirm this sequence is not necessary for everyone. You might have different experience, but I would not subscribe
I was afraid that's what "or we make people reliant on a magic tool to setFor example, any repository that does not list debian/files and debian/*.substvars in the gitignore will fail to build twice in a row, because these files are created and are subsequently untracked.
Sorry, no. We should teach people to build in a chroot which does
not leave this stuff inside local debian/ dir.
Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
For example, any repository that does not list debian/files and debian/*.substvars in the gitignore will fail to build twice in a row, because these files are created and are subsequently untracked.
Sorry, no. We should teach people to build in a chroot which does
not leave this stuff inside local debian/ dir.
Once people are familiar with how Debian packaging works, we can introduce the git interfaces on top. Before that, git is more of a hindrance than a benefit to new contributors, precisely because it looks familiar, but the knowledge is not transferable.
From my mentoring work I can confirm this sequence is not necessary for everyone. You might have different experience, but I would not subscribe this as a general rule.
We're not even doing anyone a favour by introducing the git based workflows first, because about half of the techniques people know from git will conflict with something git-buildpackage or dgit does, and without a mental model of how Debian packaging is supposed to work standalone, they have no chance of solving even the simplest problem.
New contributors won't start in a vacuum, most will start contributing
first to existing projects on Salsa
New contributors won't start in a vacuum, most will start contributing first to existing projects on Salsa
Or maybe they start with an ITP+RFS… was that an informed statement or a supposition?
Debian is about freedom, so let's apply that to free choice of the tooling
to be usable.
- I also think disallowing single-person maintainership would be very unwise,
though I agree team maintenance in general is probably better than
single-person maintainership. Still disallowing single-person maintainership
doesnt make a team and motivation lost is often motivation lost forever.
What would that even mean? What is a team anyway?
Hi,
On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
Do you think that mandating Salsa is a sensible step in this
direction?
Absolutely.
Also I think requiring a common git layout and the usage of recent
versions of dh should be required. Using merge requests instead of
sending patches should be recommended, or at least we could have a
service that creates and maintains merge requests based on patches
found in bug reports.
All these things should make it much more easy for other people or
automated tools to send merge requests or keep maintaining a package in
case the original maintainer becomes MIA.
Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.
Hi,
On 5/21/24 07:43, Bernd Zeimetz wrote:
Also its a gitlab instance. There are all kinds of documentation, tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it does not depend on a few (two?) developers.
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. We would
not even save effort in onboarding, because we'd still need to explain
the Debian specific aspects, only we would now also need to explain
which parts of the git workflow we can keep and which parts don't work
for us.
The workflows of GitHub (more deployment focused) and GitLab (more development focused) are already different enough that I have seen organizations struggle after making the wrong choice.
git-buildpackage is not a good mapping of packages to git, but the best
you can do without modifying git itself. Actually using it requires more
than beginner-level knowledge of git and suspension of any previously
held convictions that every single commit should be buildable (because
gbp likes to generate ones that aren't).
A better approach would not treat Debian metadata as git data. Even the
most vocal advocate of switching everything to Salsa writes in his MR
that the changelog should not be touched in a commit, because it creates conflicts, and instead a manual step will need to be performed later.
At the very least, GitLab integration would allow me to automate such a simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.
A better approach would not treat Debian metadata as git data. Even the most vocal advocate of switching everything to Salsa writes in his MR
that the changelog should not be touched in a commit, because it creates conflicts, and instead a manual step will need to be performed later.
At the very least, GitLab integration would allow me to automate such a simple thing as changelog handling in a more comfortable way than displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to solve the problem.
gbp dch --commit --release
A better approach would not treat Debian metadata as git data. Even the
most vocal advocate of switching everything to Salsa writes in his MR
that the changelog should not be touched in a commit, because it creates conflicts, and instead a manual step will need to be performed later.
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is
not to double down on them.
At the very least, GitLab integration would allow me to automate such a
simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.
gbp dch --commit --release
All these things should make it much more easy for other people or automated tools to send merge requests or keep maintaining a
package in
case the original maintainer becomes MIA.
People will resign.Mandating a specific git layout is a big jump from not requiring a
VCS at all.
yes, its a big jump, but we are in 2024 and a modern workflow should be expected from a modern distribution.
On Mon, 2024-05-20 at 20:47 +0000, Scott Kitterman wrote:
All these things should make it much more easy for other people or
automated tools to send merge requests or keep maintaining a
package in
case the original maintainer becomes MIA.
Mandating a specific git layout is a big jump from not requiring a
VCS at all.
yes, its a big jump, but we are in 2024 and a modern workflow should be expected from a modern distribution.
Hi,
On 5/21/24 10:43, Luca Boccassi wrote:
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is
not to double down on them.
Our workflows are largely influenced by what we do here: we maintain packages. This is different from "developing software", or "operating infrastructure."
If we can improve the workflows, then I'm all for it. What does not
work, however, is to replace them with workflows from a different task.
All we are doing here is providing a mapping of the packaging workflow
onto a git software development workflow. It still remains a packaging workflow, because the *goal* of the workflow is the completion of
packaging tasks.
Providing an implementation layer does not change the goal layer, and
GitLab does not provide any tools on the goal layer.
If we had buttons in GitLab "import new upstream release" or "show
issues affecting the stable release branch", I would consider that as
support for a packaging workflow. As it is now, GitLab only supports the workflows that the implementation layer below the goal layer typically
uses, including workflows that break the upper layer.
At the very least, GitLab integration would allow me to automate such a
simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.
gbp dch --commit --release
Where is that button in GitLab?
Exact quote: "These commits have intentionally no debian/changelog
updates as it causes every single rebase or cherry-pick of a commit to
always have a merge conflict. It is much better to have all commits
as-is, and then right before upload just run gbp-dch --auto to
automatically generate the changelog."
Definitely no.All these things should make it much more easy for other people or
automated tools to send merge requests or keep maintaining a
package in
case the original maintainer becomes MIA.
Mandating a specific git layout is a big jump from not requiring a
VCS at all.
yes, its a big jump, but we are in 2024 and a modern workflow should be expected from a modern distribution.
Attempts at top-down imposition of new methods on Debian strike me as
being unlikely to induce joy in anyone involved.
After all, We're a self-selecting group of people who are prone to
repeatedly walking the road less travelled.
Do we even have a consensus on which layout is "best"?
For anyone with an opinion, I'd suggest that you should try to make sureHow do you envision this for people who are against storing upstream
that DEP-14 reflects your opinion, and then work on getting people to
adopt the use of DEP-14 and/or get DEP-14 accepted.
Do you think that mandating Salsa is a sensible step in this direction?
Attempts at top-down imposition of new methods on Debian strike me as
being unlikely to induce joy in anyone involved.
I suspect that there's a decent chunk of developers who generally just
follow the status quo of every package they work on, without fuss.
I rather like dgit for reducing the extent I have to think about this
sort of thing, but I note that at least one person in this thread seems
vexed by it, so we cannot even agree on the merits of that, apparently.
On the other hand, dgit is only useful if you have a certain view of the world, that hasn't aligned with how I've done Debian packaging. I mean,
an entirely git-centric view where you let go of trying to maintain your patch stack.
Could you explain that? I do similar things (just that not everything
of it is published for $reasons), and I can't see how its increasing my workload as git and CIs are doing these things for me.
So I'm always curious on why workloads increase just by maintining a
package on salsa.
I would rather see a small but very stable base distribution, with the
option to add features on top.
If the debian/ directory is on salsa, but the rest of the project is somewhere else, then this no longer works, I have to tag in 2 different places, I have 2 different repositories to push to and so on.
Salvo Tomaselli <tiposchi@tiscali.it> writes:
If the debian/ directory is on salsa, but the rest of the project is somewhere else, then this no longer works, I have to tag in 2 different places, I have 2 different repositories to push to and so on.
For what it's worth, what I do for the packages for which I'm also
upstream is that I just add Salsa as another remote and, after I upload
a new version of the Debian package, I push to Salsa as well (yes,
including all the upstream branches; why not, the Debian branches are
based on that anyway, so it's not much more space). One of these days
I'll get CI set up properly, and then it will be worthwhile to push to
Salsa *before* I upload the package and let it do some additional
checking.
It's still an additional step, and I still sometimes forget to do it, but after some one-time setup, it's a fairly trivial amount of work.
It's more work to accept a merge request on Salsa and update the
repositories appropriately, since there are two repositories in play, but
in that case I'm getting a contribution out of it that I might not have gotten otherwise, so to me that seems worth it.
I used to try to keep the debian directory in a separate repository or try
to keep the Debian Git branches in a separate repository, and all of that
was just annoying and tedious and didn't feel like it accomplished much.
Just pushing the same branches everywhere is easy and seems to accomplish
the same thing.
On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
wrote:
Quoting Andreas Tille (2024-04-10 22:44:25)
I do understand the argument that lots of different workflows
adds
friction. But I'm just still using what used to be _the_ standard
one
(insofar as we ever had such a thing). Putting everything in
salsa/git
doesn't standardise workflows in itself. I think Ian/Sean
identified 12
different git-based methods in their dgit review.
I agree that different workflows are not helpful. We have DEP14[1]
... but we have no efficient processes to
a) accept DEPs
b) dedicate to accepted DEPs
or teach gbp about DEP14. See this git-buildpackage bug from *six*
years ago:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
DEP14 is a candidate, I can't see that there was any consensus to accept it. Just because there is a DEP there is no need to implement it without having any consensus on it.
And what's the advantage? When an nmu happens the person doing it normally doesn't bother to push to salsa anyway. At most I get a patch in the bugreport, or I have to diff the packages and import the diff.
Hi Philip (2024.05.21_10:05:59_+0000)
Attempts at top-down imposition of new methods on Debian strike me as
being unlikely to induce joy in anyone involved.
Yeah, that doesn't fly in community projects like Debian at all.
However, there is a gap between getting a DEP approved and getting the
rest of the project to fully embrace it. That's something that takes
some leadership in the project. DPLs are in a great position to help
drive these changes forward.
And what's the advantage? When an nmu happens the person doing it normally doesn't bother to push to salsa anyway.Yes, because it's unfortunately too expensive to:
At most I get a patch in theSending the nmudiff to the bugreport is mandatory per the devref NMU
bugreport, or I have to diff the packages and import the diff.
IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on Salsa we could require the NMUer to add at least a MR.
On Thu, 2024-04-11 at 22:52 +0000, Bill Allombert wrote:
When a change leads to a RC bug a month or three after having be
part of a package, fixing the problem falls on the maintainer and not
on the change author. Even correct changes can trigger latent bugs
in software.
Yet another reason why using Salsa and its CI *and having autopkg-
tests* is so important - contributors can test their changes before
even asking to merge them.
And yes, its up to the 'expert' maintainer
of the package to ensure there are proper tests in place. Because even
that expert is a human only and we all make mistakes.
You can run autopkgtests locally, you do not need Salsa for that.
On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
On Thu, 2024-04-11 at 22:52 +0000, Bill Allombert wrote:
When a change leads to a RC bug a month or three after having be
part of a package, fixing the problem falls on the maintainer and not
on the change author. Even correct changes can trigger latent bugs
in software.
Yet another reason why using Salsa and its CI *and having autopkg-
tests* is so important - contributors can test their changes before
even asking to merge them.
You can run autopkgtests locally, you do not need Salsa for that.
And yes, its up to the 'expert' maintainer
of the package to ensure there are proper tests in place. Because even
that expert is a human only and we all make mistakes.
Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in electricity
and in carbon emission, that we cannot completely ignore.
In any case, it is not realistic to expect tests to detect all kind of bugs, alas.
You can run autopkgtests locally, you do not need Salsa for that.
Also, Debian runs autopkgtests on all packages that provide them, and
makes passing them on all supported architectures a requirement for testing migration.
Uploading to check autopkgtests is an absolute waste of ressources. I
really hope nobody uploads a package without running the tests
somewhere else.
It could be argued that testing migration is a CI process.
Its a CI process at a way too late stage.If the archive is a VCS then uploading an untested package to experimental
Also, uploading to test a merge request is not the right thing to do.
It could be argued that testing migration is a CI process. >> Its a CI process at a way too late stage.Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*
Hi,
On 5/23/24 04:32, Andrey Rakhmatullin wrote:
It could be argued that testing migration is a CI process. >> Its a CI process at a way too late stage.Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to experimental to run tools is pushing a commit to run CI.
*shrug*
Yes, but unironically: experimental is a side branch, unstable is a MR,
and testing is the main branch.
It is entirely valid to be dissatisfied with the turnaround time of the existing CI, but what we're seeing here is the creation of a parallel structure with as-of-yet unclear scope.
Can we define the scope as "quick-turnaround unofficial validation",
because that's the niche that is currently underserved?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 32:09:08 |
| Calls: | 6,908 |
| Calls today: | 2 |
| Files: | 12,376 |
| Messages: | 5,428,085 |
| Posted today: | 1 |