<div dir="auto"><br></div><div dir="auto">If you have comments, please share them here or on the draft itself.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Otto</div><div dir="auto"><br></div></
Hi all,
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list.
This is continuation to the 'single maintainership' discussions earlier
this year. I also think that more unified and open collaboration processes could help decrease maintainer burnout, lower barrier for existing and new maintainers to help with multiple packages, and overall perhaps also
improve quality of uploads by having more attention on the source code
prior to upload.
If you think this proposal makes sense, please press the thumbs up button.
If you have comments, please share them here or on the draft itself.
Hi Otto,
Quoting Otto Kekäläinen (2024-07-28 00:38:40)
Hi all,
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list.
anybody reading the source code can easily view everyindividual change and
to review when and how a specific line of code was changed, and reason about why it was changed.
the package should at least be mirrored on Salsa for the sake of
facilitating collaboration
Run Salsa CI at least once before every upload to ensure minimal level of quality
While collaboration can happen based purely on developers submitting patch files as email attachments directly to each other, to mailing lists or in bug reports, it does not scale well.
nor even that they must spend time doing code reviews
Allow changes to be reviewed before uploads to Debian
..I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
Sorry, but I disagree that the only true collaboration is Salsa-rich collaboration. Where are my options to mirror the data at Salsa, as I
can do with mailinglists and Debbugs, to work with it also offline?
Then it makes no effort to define communication channels. Before making some time consuming change, it's usually better to just ask if that's a good idea..
Then the document should enforce a particular commit style. I've seen several people who do a bunch of unrelated changes in a single commit.
Run Salsa CI at least once before every upload to ensure minimal level of quality
Can you tell me how to do a CI for python3-motor, given that it's a client for
a proprietary database?
Testing GUI packages, or fonts packages, or clients is generally very difficult
if not impossible. What's the plan in those cases?
While collaboration can happen based purely on developers submitting patch files as email attachments directly to each other, to mailing lists or in bug
reports, it does not scale well.
It scales better than having to open salsa, find out the git:// url, add a new
remote in the local git, diff the patch locally, then of course I can't just merge the patch locally because salsa doesn't know about that, so I have to go
again on salsa and click to merge.
All of this with salsa being not fast nor responsive by any definition of those
terms.
Allow changes to be reviewed before uploads to Debian
I guess this means that we should have some mandatory waiting time from the last commit to the upload. How long would this time be? Would it apply even if
we're talking about fixing a libc upload that will break any system where it gets installed?
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
..Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
Sorry, but I disagree that the only true collaboration is Salsa-rich collaboration. Where are my options to mirror the data at Salsa, as I
can do with mailinglists and Debbugs, to work with it also offline?
First of all, thanks for maintaining 650+ packages in Debian.
You have for sure developed an optimal workflow for yourself.
I also do a lot of email based stuff myself and often work offline.
Note that GitLab does allow responding by email to notifications and
to carry reviews by email. Depending on configuration, one could even
submit patches by email[1]. There are also command-line tools that
allow various actions without having to use the browser [2,3].
I do however understand that people who already have an optimal
workflow are probably not keen to change it unless the new workflow is
vastly superior, and GitLab/Salsa isn't always perfect in all regards.
I do however believe that in the grand scheme of things promoting the
five key principles outlined in DEP-18 would benefit Debian as a
whole.
Also, I can see that you are already following principles 1 and 2 of
the proposal by having almost all of your packages in git and on salsa.debian.org. As the DEP-18 draft text says, strict enforcement is
not a wise tactic in the context of fostering collaboration, and I
would not expect you to move away from what you are doing now, as it
works for you and benefits Debian with 650+ packages. In your case
following the principles 3, 4 and 5 would probably not be appropriate
in cost vs benefit. For example running Salsa CI or asking for code
reviews prior to upload would probably just slow things down too much
without the gain in your case.
However, I would still argue that DEP-18 would be useful as a general guideline in Debian and in particular for team maintained packages and important packages (as discussed in the "end single maintainership
thread"). Having such principles published would help maintainers (at
least new maintainers) to align on a set of basic principles that help
drive more collaborative development.
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list.
This is continuation to the 'single maintainership' discussions earlier this year. I also think that more unified and open collaboration processes could help decrease maintainer burnout, lower barrier for existing and new maintainers to help with multiple packages, and overall perhaps also improve quality of uploads by having more attention on the source code prior to upload.
If you think this proposal makes sense, please press the thumbs up button.
If you have comments, please share them here or on the draft itself.
Hi Otto,
Quoting Otto Kekäläinen (2024-07-28 00:38:40)
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn
This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list.
thank you for working on this.
This is continuation to the 'single maintainership' discussions earlier this
year. I also think that more unified and open collaboration processes could help decrease maintainer burnout, lower barrier for existing and new maintainers to help with multiple packages, and overall perhaps also improve
quality of uploads by having more attention on the source code prior to upload.
A slightly related topic: what is everybody's opinion on maybe starting with some of the basic items of DEP-18, lets say items 1-3, and prescribe them to only a very small set of packages in Debian. And which set of packages in Debian should *especially* have easy open collaboration enabled if not the set
of source packages producing our Essential:yes packages? So why not start with
the source packages in the Essential:yes set, have them adhere to better collaboration standards like packaging in git on salsa and with salsa CI enabled?
Quoting Otto Kekäläinen (2024-08-01 07:30:18)
You have for sure developed an optimal workflow for yourself.
Then I have failed: I have strived towards a collaborative workflow.
Just not a web-centered collaborative workflow, but an email- and chat-
based one.
Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
run a CI before uploading, even a very basic one is just fine, better
than nothing.
Thanks for the remider ! I will have a closer look at Salsa CI instead
of trying to understand how to run autopkgtests locally.
Would there be a way to get Salsa upload and tag the package if the CI
tests pass and the changelog signals a release? Or does somebody has a script which can screen a Salsa group for ready uploads, and run clone
&& buildpackage && dput automatically ?
run a CI before uploading, even a very basic one is just fine, better
than nothing.
Emails are actually a barrier against collaboration, and activelyNo, email is the only inclusive collaboration platform.
hinder it by preventing new people from joining in. Please understand
To pick a random example, a less well known, less used, less popular distribution like Nixos has 7000+ contributors listed on Github. ItAnd I highly doubt that they vet their contributors the same way that we
On 1 Aug 2024, at 20:43, Charles Plessy <plessy@debian.org> wrote:
Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
run a CI before uploading, even a very basic one is just fine, better
than nothing.
Thanks for the remider ! I will have a closer look at Salsa CI instead
of trying to understand how to run autopkgtests locally.
Would there be a way to get Salsa upload and tag the package if the CI
tests pass and the changelog signals a release? Or does somebody has a script which can screen a Salsa group for ready uploads, and run clone
&& buildpackage && dput automatically ?
Cheers,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy
The vast majority of people who
are forced to use emails do so for work via a
work-mediated/administered interface that tries to make it somewhat >tolerable, like Outlook or Gmail.
On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi <bluca@debian.org>
wrote:
The vast majority of people who
are forced to use emails do so for work via a
work-mediated/administered interface that tries to make it somewhat >tolerable, like Outlook or Gmail.
This must be the least accurate statement about Outlook that I have
ever read. Outlook does not have a single feature that makes email
more tolerable in any way. Au contraire. The feature called threading
is incompatible with the rest of the world and not even very useful in
an outlook-only environment, the search function finds everything but
the mail you're looking for, and Outlook's disability to quote
decently is notorious for having led to the whole world generating
only top-posting replies.
Outlook is essentially responsible for making email so much worse
today than it was in the 1990s.
Even Salsa's and github's praised way to communitate in an MR is
VASTLY inferior to a decently threading mail client like mutt or even Thunderbird.
I violently disagree with the rest of the message as well and am not
willing to spoil the rest of my day by replying in detail. I'd prefer learning a bit more Slowfoxtrot later tonight.
To pick a random example, a less well known, less used, less[...]
popular distribution like Nixos has 7000+ contributors listed on
Github.
On Thu, 1 Aug 2024 at 18:16, Marc Haber <mh+debian-devel@zugschlus.de> wrote: >>
On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi <bluca@debian.org>
wrote:
The vast majority of people who
are forced to use emails do so for work via a
work-mediated/administered interface that tries to make it somewhat
tolerable, like Outlook or Gmail.
This must be the least accurate statement about Outlook that I have
ever read. Outlook does not have a single feature that makes email
more tolerable in any way. Au contraire. The feature called threading
is incompatible with the rest of the world and not even very useful in
an outlook-only environment, the search function finds everything but
the mail you're looking for, and Outlook's disability to quote
decently is notorious for having led to the whole world generating
only top-posting replies.
Outlook is essentially responsible for making email so much worse
today than it was in the 1990s.
Even Salsa's and github's praised way to communitate in an MR is
VASTLY inferior to a decently threading mail client like mutt or even
Thunderbird.
I violently disagree with the rest of the message as well and am not
willing to spoil the rest of my day by replying in detail. I'd prefer
learning a bit more Slowfoxtrot later tonight.
Again, please understand that outside of the bubble of tech nerds of
the 70s/80s, saying out loud phrases such as "The only right way to >collaborate is reading and writing emails is in my terminal" means
getting looked at like being a dinosaur just escaped from a museum.
The rest of the universe just doesn't work like that, sorry. There's
nothing wrong with being a dinosaur for an individual of course, we
will all become one at some point, but optimizing for making dinosaurs
happy from the simple perspective of demographics is a sure way for a
project to slowly slide into irrelevance. The fact that the project >membership has just about managed to remain flat while the tech sector >absolutely exploded in size should send shivers down everyone's
spines.
On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi <bluca@debian.org>
wrote:
On Thu, 1 Aug 2024 at 18:16, Marc Haber <mh+debian-devel@zugschlus.de> wrote:
On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi <bluca@debian.org>
wrote:
The vast majority of people who
are forced to use emails do so for work via a
work-mediated/administered interface that tries to make it somewhat
tolerable, like Outlook or Gmail.
This must be the least accurate statement about Outlook that I have
ever read. Outlook does not have a single feature that makes email
more tolerable in any way. Au contraire. The feature called threading
is incompatible with the rest of the world and not even very useful in
an outlook-only environment, the search function finds everything but
the mail you're looking for, and Outlook's disability to quote
decently is notorious for having led to the whole world generating
only top-posting replies.
Outlook is essentially responsible for making email so much worse
today than it was in the 1990s.
Even Salsa's and github's praised way to communitate in an MR is
VASTLY inferior to a decently threading mail client like mutt or even
Thunderbird.
I violently disagree with the rest of the message as well and am not
willing to spoil the rest of my day by replying in detail. I'd prefer
learning a bit more Slowfoxtrot later tonight.
Again, please understand that outside of the bubble of tech nerds of
the 70s/80s, saying out loud phrases such as "The only right way to >collaborate is reading and writing emails is in my terminal" means
getting looked at like being a dinosaur just escaped from a museum.
The rest of the universe just doesn't work like that, sorry. There's >nothing wrong with being a dinosaur for an individual of course, we
will all become one at some point, but optimizing for making dinosaurs >happy from the simple perspective of demographics is a sure way for a >project to slowly slide into irrelevance. The fact that the project >membership has just about managed to remain flat while the tech sector >absolutely exploded in size should send shivers down everyone's
spines.
Now that you have added personal insult while not adding anything for
the cause, I recuse myself from continuing this situation. I am happy
that I don't need to collaborate with you in my Debian efforts.
On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
[...]
To pick a random example, a less well known, less used, less[...]
popular distribution like Nixos has 7000+ contributors listed on
Github.
Just to pick on this particular point, because I see this metric
used all the time by projects trying to inflate public impressions
of their size: you're aware that GitHub counts someone as a
"contributor" even if all the do is leave a comment on a bug report,
right? By that gauge, Debian is probably orders of magnitude larger.
saying out loud phrases such as "The only right way to
collaborate is reading and writing emails is in my terminal"
Just to pick on this particular point, because I see this metric
used all the time by projects trying to inflate public impressions
of their size: you're aware that GitHub counts someone as a
"contributor" even if all the do is leave a comment on a bug report,
right? By that gauge, Debian is probably orders of magnitude larger.
saying out loud phrases such as "The only right way to
collaborate is reading and writing emails is in my terminal"
Please. This feels like trolling.
You're literally making up a quote and then you reply to it.
Nobody said that. This is not useful.
Also, there's IRC/matrix for more real time communication, but I challenge you
to follow those long threads on d-devel on something like teams or slack.
On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
[...]
To pick a random example, a less well known, less used, less[...]
popular distribution like Nixos has 7000+ contributors listed on
Github.
Just to pick on this particular point, because I see this metric
used all the time by projects trying to inflate public impressions
of their size: you're aware that GitHub counts someone as a
"contributor" even if all the do is leave a comment on a bug report,
right? By that gauge, Debian is probably orders of magnitude larger.
I'm not, no, I thought it was committers/authors? But I haven't really
looked it up so you might very well be right. Where did you find that defined?
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled
"DEP-18: Enable true open collaboration on all Debian packages".
Also, there's IRC/matrix for more real time communication, but I challenge youDiscourse. Or some other "forum" software. IMO online forums and mailing lists are pretty similar in core functions (threaded conversations), they just differ in UI.
to follow those long threads on d-devel on something like teams or slack.
Issues with Salsa/GitLab:
1. It is so slow that it makes me want to close by browser and do
something else instead
[...]
5. Did I mention how slow it is?
One particular thing noticed in some cases (and I hope they are not
many) is the lack of use or especially updates of the Vcs-* fields in d/control. I think is important point to packaging repository from the tracker if present and to update it if moved, this can help
collaboration and reduce possible waste of time doing things that are perhaps already done by others (or WIP) but which have not yet been uploaded.
I think that both email and systems like salsa/github/gitlab etc. are useful, both with pros and cons. Forcing people to use only one or the
other could be counterproductive at the moment. One thing that I think
would be useful is to have certain, fast and simple information for each package about which actual collaboration methods it uses and prefers.
For example seeing a package it would be very useful to know immediately
if it wants a collaboration only through bugtracker and patch, only
through vcs or both are accepted. If managed in a team point more easily
to information about the team and any pages with details (for example on wiki).
Before a certain way of doing things can be mandated or "warmly
recommended", the technology has to be as flawless as possible - and
today I wouldn't call Salsa "flawless", would you? Issues with
Salsa/GitLab:
1. It is so slow that it makes me want to close by browser and do
something else instead
2. It doesn't support email-based workflows
3. It has a lot of features we don't need. Or rather, it has more
features we *don't* need than we do.
4. Its user interface is confusing, it's often hard to find what I'm
looking for
5. Did I mention how slow it is?
6. It is developed by a company who's philosophy and interests are
misaligned with Debian's
7. The product it tries to mimic, GitHub, is also misaligned with
Debian's philosophy and interests
While performance is something we could reasonably do something about,
all the other points are part of GitLab by design, and we're stuck with
them.
But the point isn't that much about being able to use emails
specifically, it is about having the possibility of having a software
forge which is interoperable with a wide range of tools and can stay
out of the way if wanted. With GitLab, you either use the full package
(which includes browsing, reviewing, and commenting) or you get a
sub-optimal experience. But it doesn't have to be this way.
I'll now talk a bit about SourceHut. Not to suggest that we should use
that instead, but just to point out how things *can* be done.
I agree that Salsa is sometimes a bit sluggish (https://salsa.debian.org/salsa/support/-/issues/395),
but I hope we can do something to improve it and it is now a permanent reason to not use Salsa.
Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
I think that both email and systems like salsa/github/gitlab etc. areI guess that you mean something like this:
useful, both with pros and cons. Forcing people to use only one or the
other could be counterproductive at the moment. One thing that I think
would be useful is to have certain, fast and simple information for each >> package about which actual collaboration methods it uses and prefers.
For example seeing a package it would be very useful to know immediately >> if it wants a collaboration only through bugtracker and patch, only
through vcs or both are accepted. If managed in a team point more easily >> to information about the team and any pages with details (for example on >> wiki).
```patch
--- a/debian/control
+++ b/debian/control
@@ -60,6 +60,7 @@ Standards-Version: 4.7.0
Homepage: https://github.com/oxigraph/oxigraph
Vcs-Git: https://salsa.debian.org/debian/oxigraph.git
Vcs-Browser: https://salsa.debian.org/debian/oxigraph
+Contact: https://bugs.debian.org/oxigraph
Rules-Requires-Root: no
Package: oxigraph
```
In principle I find that an interesting suggestion, as I can imagine
such information being helpful in understanding if debbugs is used only
by "dinosaurs".
I see two problems, however:
a) Maintainers will be bothered to add that new field to every package
(or at least a substantial subset) for it to be of practical use.
b) Which other answers exist for that field? I mean, is it ok in Debian for a maintainer to not use Debbugs? Is it ok in Debian for a
maintainer to also use another issue tracker and not replicate whatever
is collected elsewhere in Debbugs?
Or perhaps I am missing the point of your suggestion, and you do not
mean where *bug* chatter goes, but instead where *non-bug* conversations go. If that is the case, then I believe we have a field already for
that, called "Maintainer:". If you mean neither issue tracking nor the main contact information for a package, then please elaborate what you
had in mind, because that's pretty essential to get clarified before discussing any further...
contact field don't exist now right? even if the contact field maybe
doesn't give you an idea, maybe something like "contributing" that links
to the bugtracker, to the repository MR/PR or a wiki page or site with
any details (especially in case of a group)
maybe I'm not good at explaining myself, I think the problem is that if
a contributor, maybe even new or who wants to make even occasional contributions on specific packages is not able to find in a simple and
fast way about the package on which he wants to contribute as he should
(or is better to do), in some cases you can understand in short time by looking a bit at the bugtracker and the vcs while, looking for any wiki pages if he is part of a team but in many cases it is not simple/fast to understand how he should contribute for that package in order to get the
best result. using patches on bugtracker or vcs (like salsa) is just one part, then there could be more
you could say to force everyone to use the same system, in theory it
would solve the problem, but in practice I find it difficult and perhaps
more harmful. I try to summarize: the contributors are people and not machines, moreover many do it as a passion in a little free time and not
as if it were a job.
If someone thinks that these speed/reachabilityare not important because >> they are used to even longer times for many operations, for exampleIf you mean psychological stress, then I find your reasoning flawed, as that is about a *perceived* lack of time (or other pressure), not necessarily actual lack of it. Possibly but not necessarily.
regarding the bugtracker, tracker, upload etc., unfortunately we live in >> an increasingly frenetic and continuously worsening world (this world
causes more and more stress and less and less time available).
If you mean stress on the Earth, then I find it highly unlikely that we
can solve that crisis by speeding things up. Instead we need to find
ways to *reduce* the *amount* of computing we do, and find ways to time that computing in ways that fit more optimally with the availability of needed resources (e.g. consume less electricity when there is less wind
and sunny, to reduce stress on green parts of related electricity grid).
Please elaborate what kind of stress you are really talking about, and again please consider the topic of the conversation (see above about changing Subject: line).
this is complicated to explain, I'm not good at explaining nor in english^^'
staying on the subject of DEP-18 I think it could be relevant on stress based on if/how it will be done and applied and what I wanted to bring attention to is not to consider only the possible benefits on the
quality of the packages that it could bring but also the cost that it
could have on the people who contribute and try to be balanced
it is unfortunately common to think of profit at the expense of people,
in the case of Debian it would not be for profit but the impact on contributions can be significant.
the ideal thing would be that it increases the quality and also makes it
more efficient and less stressful to contribute but I fear that this is utopian and it is much more likely that there will be fewer results than hoped for and a higher cost (on the people who contribute)
Quoting Otto Kekäläinen (2024-08-02 17:23:51)
I agree that Salsa is sometimes a bit sluggish (https://salsa.debian.org/salsa/support/-/issues/395),
what kind of hardware do you have? For people like me who are on slower
hardware, the web experience is absolutely not funny and "a bit sluggish" doesn't begin to describe it. It is hard to find any other website I'm visiting
that is slower than gitlab. For example, when I run this on my Firefox I get a
score of 1.53: https://browserbench.org/Speedometer3.0/#summary
You now said "I hope we can do something to improve it and it is now a permanent reason to not use Salsa." twice:
Did you typo it twice or do you actually mean that it's now a permanent reason
to not use salsa?
I am not suggesting salsa use because I think it's the best thing since the invention of sliced bread. But personally, I rather use something suboptimal if
it means that we can more or less agree on a "default" and I think that the current situation (submission of patches by mail and the debian archive is the
bts) is deterring to newcomers. I know that most people probably have faster machines than I. As it was pointed out elsewhere in this thread, Debian work already implies a lot more waiting than "a few seconds" for salsa to finish loading a page or finish yet another animation, so meh. With the glab tool I think I can be happy enough.
My problem with DEP-18 is that people who have zero problem with using
git and are also not fundamentally against using salsa, but have
reservations surrounding *which parts* of salsa to use and the
consequences for related already used tooling.
I am also not against being welcoming to newcomers, but I am concerned
if the focus on tose unreasonably reshapes the tooling for all of us.
Essentially, my concern is that DEP-18 reduces a spectrum of options to "either you are for or against true collaboration".
Leaning more on Gitlab is not the "true" choice, but the pragmatic one, because yes, we have invested in it, and some parts of it might be made
to better use for use.
I imagine that some in the silent crowd hesitate to chime in due to that lumping together the use of git and the use of Gitlab into an
all-or-nothing choice. I think you intended that reduction, for the
purpose of simplifying the conversation. I don't think that
simplification is helpfull, however.
I am not suggesting salsa use because I think it's the best thing since the invention of sliced bread. But personally, I rather use something suboptimal if
it means that we can more or less agree on a "default" and I think that the current situation (submission of patches by mail and the debian archive is the
bts) is deterring to newcomers. I know that most people probably have faster
machines than I. As it was pointed out elsewhere in this thread, Debian work
already implies a lot more waiting than "a few seconds" for salsa to finish loading a page or finish yet another animation, so meh. With the glab tool I
think I can be happy enough.
This I think summarizes well the opinion of most people I have spoken
with. GitLab is not perfect, but it was chosen and we have been using
it for 5+ years mostly successfully. Most packages are there and we
should state that it is the recommended option. Currently the second
most popular option is to use GitHub, or not use any vcs at all.
A lot of this thread has gone into people expressing their dislike for
Salsa. Most people still use Salsa - I guess the silent mass isn't
chiming in in this thread that much now. Some people probably have
very optimized email workflows, and nobody can argue against the
statement that a pure email workflow for sure is simple, and has its elegance. But it also has shortcomings such as no lack of
metadata/status, no built-in way to run CI and share the code+logs+CI
results etc.
Following the principles 1 (use git) and 2 (use Salsa) allows for the
next principles 3, 4 and 5 to take place. I would be curious to hear
more views about them.
DEP-18 summary (https://salsa.debian.org/dep-team/deps/-/merge_requests/8): 1. Have package source code in version control, using git
2. Host package source on Debian's code forge Salsa
3. Run Salsa CI at least once before every upload to ensure minimal
level of quality
4. Allow Merge Requests to be submitted
5. Allow changes to be reviewed before uploads to Debian
My plan is to summarize the discussion and update the proposal in the
coming days, incorporating as many views as possible. I will also in
the next update include additional relevant context info such as
tag2upload, glab and examples of how to easily work with both Debian
bug tracker and MRs in parallel.
Please share your views, and also +1 or -1 the proposal on Salsa so we
can incorporate that too in measuring the support of this.
Remember that DEPs are soft rules - unlike General Resolutions (GRs) -
and maintainers who have specific reasons to not want to use git or
Salsa will not be forced to do so.
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages".
Hi Otto,
thank you for your initiative,
one problem I have with NMUs in team-maintained package is that they
often bypass Salsa… Would it make sense to add to the DEP a request
that NMUs are started from and pushed to the default branch?
Hi,
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)
If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.
NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve
collaboration in Debian, IMHO.
Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it)
* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to
allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.
[1] https://wiki.debian.org/LowThresholdNmu
Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
* Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
(If there is no Collaboration-Policy, it is safe that sending merge
request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy
because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.
It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack
with incomplete communication in some cases.
Hi,
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)
If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.
NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve
collaboration in Debian, IMHO.
Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it)
* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to
allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.
[1] https://wiki.debian.org/LowThresholdNmu
Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
* Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
(If there is no Collaboration-Policy, it is safe that sending merge
request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy
because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.
It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack
with incomplete communication in some cases.
A lot of this thread has gone into people expressing their dislike for
Salsa. Most people still use Salsa - I guess the silent mass isn't
chiming in in this thread that much now.
Il 03/08/2024 14:40, Kentaro Hayashi ha scritto:
Hi,
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team maintained packages under https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)
If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.
NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve
collaboration in Debian, IMHO.
Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it)
* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to
allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.
[1] https://wiki.debian.org/LowThresholdNmu
Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source.
* Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
(If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy
because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.
It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack
with incomplete communication in some cases.
Hi, this I think is can be useful (beyond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaboration-Policy that point a file or url,
this I think that can decrease the possible annoyance and in the case of teams or even single maintainers having a single policy file to point to
and update in a simpler and faster way (especially if there were the
same policies for dozens of packages or more, there could be also
hundreds or thousands)
Il 03/08/2024 15:59, Jonas Smedegaard ha scritto:
Quoting Fabio Fantoni (2024-08-03 15:39:00)annoyance maintainers for update it on many package, with a url that
Il 03/08/2024 14:40, Kentaro Hayashi ha scritto:What annoyance are you referring to?
Hi,Hi, this I think is can be useful (beyond the example use of
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team maintained packages under
https://salsa.debian.org/debian/.
If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)
If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.
NOTE: The following idea might be out-of-scope in DEP-18, but specific >>> use-case to improve
collaboration in Debian, IMHO.
Here is just an idea: put collaboration policy metadata in debian/control.
(The following idea assumes that non-maintainer DD tend to hesitate to >>> commit/merge it)
* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note >>> in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to >>> commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to >>> allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.
[1] https://wiki.debian.org/LowThresholdNmu
Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
* Because other DD (non package owner) can commit/merge, then ship >>> NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
(If there is no Collaboration-Policy, it is safe that sending merge >>> request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or
Collaboration-Policy-Merge: no policy
because DD has maintainer rights on salsa.d.o and can commit/merge >>> it in reality.
It might worry too much, but it might be able to block an unfortunate
accident, a so-called package hijack
with incomplete communication in some cases.
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaboration-Policy that point a file or url,
this I think that can decrease the possible annoyance and in the case of >> teams or even single maintainers having a single policy file to point to >> and update in a simpler and faster way (especially if there were the
same policies for dozens of packages or more, there could be also
hundreds or thousands)
point to an external file can be update once for even on tens, hundreds
or more packages it could be set on
Are some new contributors annoyed by the lack of formalized rules for collaboration?not only new but also any contributors that want to contribute on other package, also about that I tried to explain something in one of my
previous mail
Are some maintainers annoyed by how some new contributors initiate collaborative contributions?I don't know how likely it is, I hope it's very rare
As a maintainer, I can imagine getting annoyed by *non-collaborative* contributions done in ways that I feel leaves an extra burden on me.
One description for that is "drive-by contributions", meaning that
someone contributes without having the time to *collaborate* on it,
to align the contribution with how the package is maintained.
But since this whole thread is about "true open collaboration", I
assume that you are talking about *collaborative* work, and then I
cannot recognize what is the kind of annoyance you are referring to.
There is a lot of other information that may vary on how to contribute
in certain packages or teams beyond what is already listed, here only
some example:
Debian Python Team - https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Java team - https://www.debian.org/doc/packaging-manuals/java-policy/
Rust team - https://wiki.debian.org/Teams/RustPackaging
go team - https://go-team.pages.debian.net/packaging.html
I imagine that some in the silent crowd hesitate to chime in due to that lumping together the use of git and the use of Gitlab into an
all-or-nothing choice. I think you intended that reduction, for the
purpose of simplifying the conversation. I don't think that
simplification is helpfull, however.
the2. Standardizing around a single (or small number of) workflows will make some people unhappy. But that is an acceptable price to pay because of
general benefit to the project *as long as the correct solution is adopted*. Unity is more important than minority opinions on this particular issue.
Keep in mind that unhappy people quit.
I don't think that unity is so important that we're willing to sacrifice project members.
What exact issue are we trying to fix?
At the bottom, is it ok for a package to have a single maintainer or not?
If as a project this has to change, I think a vote is warranted.
2. Standardizing around a single (or small number of) workflows will make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project *as long as the correct solution is
adopted*. Unity is more important than minority opinions on this
particular issue.
I have three feelings.
1. Debian workflows are too fractured. The project would be better if we asked people to standardize around a single (or a small number) of workflows. To do so, the workflow would need to be flexible enough to handle the wide range of technicalneeds of all the packages and upstream configurations.
2. Standardizing around a single (or small number of) workflows will make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project as long as the correct solution is adopted. Unity is more importantthan minority opinions on this particular issue.
3. I do not yet have the wisdom to ascertain what the correct solution is. Until I do, I applaud those who attempt to push this discussion forward, and I follow it closely, but I haven’t commented. I think adopting an incorrect mandated (or maybeeven recommended) workflow is worse than the fractured status quo.
Number 3 is why I haven’t previously commented. In regards to DEP-18, I don’t know if it is the correct way to go for many of the criticisms that have already been expressed. But, if it isn’t DEP-18, I think it will eventually be something.And, although this might not be a popular opinion among some, I think Debian should get to the point that there is one workflow (or a very small number of workflows) that all packages are expected to follow, both for packaging and for collaboration.
one problem I have with NMUs in team-maintained package is that they
often bypass Salsa… Would it make sense to add to the DEP a request
that NMUs are started from and pushed to the default branch?
2. Standardizing around a single (or small number of) workflows will make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project *as long as the correct solution is adopted*. Unity is more important than minority opinions on this particular issue.
Keep in mind that unhappy people quit.
I don't think that unity is so important that we're willing to sacrifice project members.
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
one problem I have with NMUs in team-maintained package is that they often bypass Salsa… Would it make sense to add to the DEP a request that NMUs are started from and pushed to the default branch?Only if DEP-18 also includes an easy way to find the workflow used by the repo, which I'm not seeing there (which may be my fault).
something like wrote here can help for you?
https://lists.debian.org/debian-devel/2024/08/msg00058.html
https://lists.debian.org/debian-devel/2024/08/msg00062.html
I think something like this could be useful, even in a possible future where all packages would use git and salsa; but from the answers received so far
it seems to be considered a useless thing. I would be curious to know the opinion of more people.
currently you find such information from a simple search and/or looking
a bit in the source, in the possible git in a few minutes only in part
of cases, in many other cases instead it requires more time, the
possible contact of the maintainer, attempts (and then eventually feel
that it would be better to "improve" your contributions using other
methods).
My problem with DEP-18 is that people who have zero problem with using
git and are also not fundamentally against using salsa, but have
reservations surrounding *which parts* of salsa to use and the
consequences for related already used tooling.
Hello, I like the dgit idea, produce a git repository for people who want to use git and let other use whatever they want.
Maybe uploading a paquage to Debian could push automatically into dgit. (maybe
this is already the case)
It's similar but different: I'm talking about workflows to build a package from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
And yeah it could be a metadata field.
1. Debian workflows are too fractured. The project would be better if we asked people
to standardize around a single (or a small number) of workflows. To do so, the workflow
would need to be flexible enough to handle the wide range of technical needs of all the
packages and upstream configurations.
2. Standardizing around a single (or small number of) workflows will make some people
unhappy. But that is an acceptable price to pay because of the general benefit to the
project as long as the correct solution is adopted. Unity is more important than minority
opinions on this particular issue.
3. I do not yet have the wisdom to ascertain what the correct solution is. Until I do, I
applaud those who attempt to push this discussion forward, and I follow it closely, but I
haven’t commented. I think adopting an incorrect mandated (or maybe even recommended) workflow is worse than the fractured status quo.
It's similar but different: I'm talking about workflows to build a package from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
And yeah it could be a metadata field.
1. Debian workflows are too fractured. The project would be better if we asked people to standardize around a single (or a small number) of workflows. To do so, the workflow would need to be flexible enough to handle the wide range of technical needsof all the packages and upstream configurations.
2. Standardizing around a single (or small number of) workflows wil make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project as long as the correct solution is adopted. Unity is more important thanminority opinions on this particular issue.
Keep in mind that unhappy people quit. I don't think that unity is so important that we're willing to sacrifice project members.
I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be writtensuch as to account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to specify their preferred collaboration methods in a machine-readable way, for example through a "Collaboration-Policy" field in debian/control.
Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-sort`, then which options)? Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review.
NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve
collaboration in Debian, IMHO.
Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it)
* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to
allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.
My overall impression is that this is a bold attempt, but the document could do
with some copy-editing to whittle it down, make it more focussed, and possibly
narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be done further down the line in a follow-up DEP?
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So we rely on the central salsa instance.
I do not know if I am clear but I have the fear that this
centralisation will make us forget that de-centralisation is sort of "central" to the Debian way.
PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> writes:
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So we rely on the central salsa instance.
fwiw, i dont think that a properly scoped DEP would change any of
that. eg, it could be written to be only about what goes into the
archive and not say anything about using schroot locally, or whether
salsa is gitlab or something else. but maybe i misunderstand
I do not know if I am clear but I have the fear that this
centralisation will make us forget that de-centralisation is sort of
"central" to the Debian way.
I suspect that if the DEP was clearer in scope and aims, these concerns
would not actually arise
On 02/09/2024 06:38, Richard Lewis wrote:
PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> writes:
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So we rely on the central salsa instance.
fwiw, i dont think that a properly scoped DEP would change any of
that. eg, it could be written to be only about what goes into the
archive and not say anything about using schroot locally, or whether
salsa is gitlab or something else. but maybe i misunderstand
I do not know if I am clear but I have the fear that this
centralisation will make us forget that de-centralisation is sort of
"central" to the Debian way.
I suspect that if the DEP was clearer in scope and aims, these concerns would not actually arise
Debian infrastructure is "centralized" in many ways. The power to decide which
packages go in the archive and which do not is "centralized" in the FTP team, and you must upload to a "centralized" machine for them to review. buildds build
the public facing packages, debci runs migration reference tests, they are all
"centralized" on a few hosts and in a few people. Packages are distributed from
a single source (mirrors don't have the say of the content). Even the very list
you are posting to is hosted on a centralized machine. How would storing packaging sources on a centralized code hosting instance be different than package distribution? How would a centralized CI be different than buildds and
debci?
The more important decentralization is in the decision process. Not everything
is fit for decentralization; don't push it only for the sake of it.
GitLab isn't perfect, sure, but it's an implementation detail of having a centralized code hosting and CI. I'd personally expect the CI to be basically the same as debci (maybe even merge the two or make salsa delegate CI to debci),
but that's another topic.
I don't say that Debian must work for jungle developers, nor that we
must all use email and not different forms of collaboration requiring
better connectivity. My point is that Debian *allows* collaboration
also without heavy realtime connectivity that most of us take for
granted in our working environments, and I fail to see why the few
points that are centralized is a reason for giving up on all the others
as well.
Well, I didn't mean we should *give up* decentralization. I mean we shouldn't give up *centralization*. These examples are to prove centralization actually works and is quite common, sometimes necessary.
Besides, *you* are the centralization point when you are the only maintainer. With a centralized code hosting, you exchange being SPOF with redundancy and team work :p
Hello,
Well, I didn't mean we should *give up* decentralization. I mean we shouldn't
give up *centralization*. These examples are to prove centralization actually
works and is quite common, sometimes necessary.
It would be great if we could run the salsa-ci pipeline localy easily, in chroot via sbuild or whatever.
Do not get me wrong I like the fact that we have these pipelines in salsa, it is a great plus for Debian.
I Just see that the salsa-ci pipelines does not gives somethimes exacly the same result than my current sbuild + autopkgtest run locally.
So I need to iterate also on salsa-ci to fix my autopkgtests.
It would be great if the "quality-pipeline" could be decouple from salsa and could be run locally / salsa / what ever other infra.
We have plenty of quality tools, but it is not easy to run them all in a row during the package preparation.
The discussion was summarized in a separate "Summay" email by me on this list, and a comment in the MR (which merges the two discussions) and it
just happened that the next day it was also covered in https://lwn.net/Articles/986480/
I am currently writing revision 2 of the proposal. I will notify when published.
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
********************************************************************************of all the packages and upstream configurations.
Summary of mailing list discussion in https://lists.debian.org/debian-devel/2024/07/msg00429.html
## Overall Sentiment
There was a broad consensus that Debian workflows are too fractured
and would benefit from more standardization and unification. However,
there were differing opinions on the right approach to achieve this.
Soren Stoutner expressed this sentiment clearly:
1. Debian workflows are too fractured. The project would be better if we asked people to standardize around a single (or a small number) of workflows. To do so, the workflow would need to be flexible enough to handle the wide range of technical needs
than minority opinions on this particular issue.2. Standardizing around a single (or small number of) workflows wil make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project as long as the correct solution is adopted. Unity is more important
Similarly, Andrey Rakhmatullin argued that while some may resign, "thesuch as to account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to specify their preferred collaboration methods in a machine-readable way, for example through a "Collaboration-Policy" field in debian/control.
'1000 DDs status quo' problem also means that more people leave than
join _anyway_. Not the unity per se, but having significantly lower
barriers to start contributing" is important.
## Git and Gitlab Usage
Multiple participants noted that most other Linux distributions use
Git as the primary version control system, often with GitLab or GitHub
for collaboration. Debian's multi-branch approach with pristine-tar
was seen as somewhat unique.
There were differing views on whether Debian should move closer to the
more common Git-based workflows used elsewhere, or maintain its own
custom approach, which of git-buildpackage and dgit are the most
common ones (both with multiple ways to use them).
## Mandatory vs Optional Policies
Some participants, like Salvo Tomaselli, felt DEP-18 was too
prescriptive in mandating specific tools and workflows, and that a
more flexible, optional approach would be better:
Keep in mind that unhappy people quit. I don't think that unity is so important that we're willing to sacrifice project members.
Others, including Soren Stoutner, argued that standardization was
important, even if it made some people initially unhappy, as long as
the right solution was adopted: "Unity is more important than minority opinions on this particular issue."
## Maintainer Workflows
There were concerns that requiring specific Git and Gitlab practices
could create burdens for existing maintainers, especially
single-person maintainers. Sean Whitton described his own preferences
as a maintainer:
I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written
## Performance and Reliabilitysort`, then which options)? Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review.
Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as
important. In response, Otto Kekäläinen noted that the Salsa admins
had posted about upcoming hardware upgrades and other improvements to
address these issues at
https://salsa.debian.org/salsa/support/-/issues.
## Machine-Readable Metadata
Fabio Fantoni and Niels Thykier proposed including more
machine-readable metadata about packaging workflows (e.g. in
debian/control) to help automate contributor onboarding. Niels Thykier outlined some specific examples of information that could be captured:
Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-
## Overall
There seemed to be general agreement that improving collaboration was important, but the right approach was still being debated.
## Mailing list participants
- Jonas Smedegaard
- Salvo Tomaselli
- Luca Boccassi
- Charles Plessy
- Marco d'Itri
- Sean Whitton
- Marc Haber
- Jeremy Stanley
- Shengjing Zhu
- Noah Meyerhans
- PICCA Frederic-Emmanuel
- Fabio Fantoni
- Kentaro Hayashi
- Tobias Frost
- Gioele Barabucci
- Blair Noctis
- Andrea Pappacoda
- Soren Stoutner
- Andrey Rakhmatullin
- Paul Gevers
- Niels Thykier
- Simon Richter
- Chris Hofstaedtler
- Johannes Schauer Marin Rodrigues
********************************************************************************
Summary of the 70+ comments in this https://salsa.debian.org/dep-team/deps/-/merge_requests/8
There were some differing viewpoints on this many parts of the
proposal, but also lots of support.
**Opposition to using Salsa/GitLab:**
* mirabilos strongly opposed using Salsa, stating "Salsa is inherently
a nōn-free tool...I strongly believe forcing people on GitLab is an
SC/DFSG violation."
* Joachim Zobel had the opposite view of caring purely about usability
and asking "Why is maintaining a Debian package on GitHub against
DEP-18?"
* Salsa could be viewed as a middle ground between the above options.
* Helmut Grohne raised concerns about lack of consensus, saying "Given
that there are at least two competing hosting options with similar
adoption, I question the unilateral choice of one of them."
**Concerns around merge request process:**
* Louis-Philippe Véronneau pointed out "MRs really don't work well
with some of the current git workflows...reviewing such contributions
is a ton of work."
* Simon Richter argued "The entire DEP except for this paragraph very carefully avoids making any technical recommendation...If this DEP
should be useful at all, it needs to make a technical contribution."
* A future version needs to list examples of packages that have
reviews before upload to paint a picture how it works in practice (and
that it is doable)
**Support for using GitLab/Salsa:**
* Guido Günther said "Fragmentation...is an issue so recommending
salsa makes a lot of sense from Debian's PoV."
* Andreas Tille stated "We simply loose people who are frustrated that
its impossible to do Debian wide changes easily...Its simply not
sufficient for say running Janitor like tools on random Vcs locations
outside Salsa."
* Blair Noctis argued "At this stage of the free software movement
we...need more hands to compete with non-free things...Machines and
tools should adapt to people, not the other way around."
**Other viewpoints:**
* Chris Hofstaedtler asked "Please provide a clear definition of what
this DEP wants to achieve. Right now it lives off a headline of "true
open collaboration" without defining that."
* Bastian Venthur noted "DEP-14 is not accepted yet, but in the
candidate state since 2020."
* The discussion surfaced well what are the shared pain points in the packaging workflow beyond just collaboration struggles. Work should
also continue on DEP-14, git-buildpackage, Salsa CI and other tools to decrease the general friction, and in many places simple documentation updates/overhaul is due to avoid unnecessary fragmentation in
workflows that isn't intentional so that we later can more clearly
focus on discussion the pros and cons of the intentionally different workflows.
Thanks to Salsa Admins, recently when I used salsa it went much better.
While unfortunately I still had many cases where packages.debian.org did not load the pages or took a long time, several cases still for wiki.debian.org too (even if maybe less), am I the only one who notices or maybe the other DD/DMs do not use them or use them very little?
Hi all,
I published a complete rewrite of the earlier draft as:
https://salsa.debian.org/dep-team/deps/-/merge_requests/12
DEP-18: Encourage Continuous Integration and Merge Request
based Collaboration for Debian packages
If you are in favor of having this as a DRAFT in the DEP directory,
please give it a thumbs up.
I published a complete rewrite of the earlier draft as:
https://salsa.debian.org/dep-team/deps/-/merge_requests/12
DEP-18: Encourage Continuous Integration and Merge Request
based Collaboration for Debian packages
If you are in favor of having this as a DRAFT in the DEP directory,
please give it a thumbs up.
I think it's falling between two stools: are you giving project
improvement ideas or a personal view of how to package (which seems very perscriptive and im afraid not clearly argued)?
I think the you could edit it to something much shorter
that said:
- all packages should be available in git via salsa.debian.org
- salsa CI should be enabled
- (sensible) merge requests on salsa should be accepted
this first doesnt preclude people having other workflows as well, but
the 3rd ensures people can take advantage of modern approaches
I published a complete rewrite of the earlier draft as:
https://salsa.debian.org/dep-team/deps/-/merge_requests/12
DEP-18: Encourage Continuous Integration and Merge Request
based Collaboration for Debian packages
If you are in favor of having this as a DRAFT in the DEP directory, please give it a thumbs up.
I think it's falling between two stools: are you giving project
improvement ideas or a personal view of how to package (which seems very perscriptive and im afraid not clearly argued)?
I think the you could edit it to something much shorter
that said:
- all packages should be available in git via salsa.debian.org
- salsa CI should be enabled
- (sensible) merge requests on salsa should be accepted
this first doesnt preclude people having other workflows as well, but
the 3rd ensures people can take advantage of modern approaches
Thanks for reading DEP-18. I am trying to help Debian here by
accelerating the convergence on common practices to make it easier for
people to collaborate using Salsa. These are not personal views, but
based on the analysis of all team policies in Debian and from
collecting stats from Debian packages, using for example data points
that 13573 packages in Debian have explicitly a debian/gbp.conf file
already.
Hi all,
I published a complete rewrite of the earlier draft as:
https://salsa.debian.org/dep-team/deps/-/merge_requests/12
DEP-18: Encourage Continuous Integration and Merge Request
based Collaboration for Debian packages
collecting stats from Debian packages, using for example data points
that 13573 packages in Debian have explicitly a debian/gbp.conf file already.
I guess those data points include how many packages use salsa, with
various Gitlab features enabled.
Since various Gitlab features are enabled by default, did they also
somehow include whether the package actually used the feature or not?
collecting stats from Debian packages, using for example data points
that 13573 packages in Debian have explicitly a debian/gbp.conf file already.
I guess those data points include how many packages use salsa, with
various Gitlab features enabled.
Since various Gitlab features are enabled by default, did they also
somehow include whether the package actually used the feature or not?
This specific data point has nothing to do with Salsa. It is simply
the count of how many packages have a `debian/gbp.conf` file in the
Debian source package.
I support going even further: I think the Debian build infrastructure
should over time be moved over to Salsa pipelines. GitLab pipelines
offer a lot of transparency, security and reproducability benefits
compared to the current Debian buildds which in my perception operate
under a "trust us we know what we are doing but we can't be bothered to
be transparent about it" policy that doesn't inspire confidence in me.
On 11/21/24 9:51 AM, Simon Josefsson wrote:
I support going even further: I think the Debian build infrastructure
should over time be moved over to Salsa pipelines. GitLab pipelines
offer a lot of transparency, security and reproducability benefits
compared to the current Debian buildds which in my perception operate
under a "trust us we know what we are doing but we can't be bothered to
be transparent about it" policy that doesn't inspire confidence in me.
Generally everything is in publicly available git repositories, if you
know where to look (somewhere distributed between wanna-build, buildd, pybuildd, and dsa-puppet). The setup of the coordinator in particular
suffers from only having a single installation (not even a staging/test
one), though.
I agree in principle in that a lot of trust needs to be extended to the management and operation here - and we could do much better. I'm not
sure if pipelines are any better if the runner could equally tamper with
the builds. But everything is in git somewhere.
I believe that Otto's lets-standardize-on-salsa effort is fundamentally
a good thing. Let's help him flesh out the details.
Please also help Guido iterate on git-buildpackage so that it works
well, is easy to debug, has good docs etc. Based on discussions in
this thread there are a lot of people with misconceptions and
polishing the docs would be the best action item right now.
Please also help Guido iterate on git-buildpackage so that it works
well, is easy to debug, has good docs etc. Based on discussions in
this thread there are a lot of people with misconceptions and
polishing the docs would be the best action item right now.
Happy to help on that - What is the best way to do so?
Basically you can start by forking https://salsa.debian.org/agx/git-buildpackage on Salsa and then start
hacking away on the things you want to improve.
If you want to do Python coding, fixing this issue could be an easy
one to start with: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084672#12.
If you
want to help with the documentation, you could for example extend the
page that explains what the various gbp.conf options mean.
That said: There hasn't been much innovation in this space so far - in a
way that was usable by Debian. Making builds something based off tasks
(e.g. in a pipeline) when a package is uploaded rather than diffing the archive and trying to match the intent is something I would have wanted
to see for a long time.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 14:03:15 |
| Calls: | 9,665 |
| Files: | 13,712 |
| Messages: | 6,167,660 |