Post by Jonas SmedegaardHi Fabio,
Quoting Fabio Fantoni (2024-08-02 14:31:04)
Post by Fabio FantoniOne 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.
That's tracked as OLD key at https://qa.debian.org/cgi-bin/vcswatch -
also included in the Maintainer Dashboard for each package at
https://udd.debian.org/dmd.cgi
Whenever you stumble upon a package misaligned with its declared Vcs
metadata, please file a bugreport, and while doing so consider
encouraging the maintainer to use the Maintainer Dashboard.
Thanks for your reply, I know about there and is useful for found vcs
not working but vcs working/reachable but no longer used, in favor of
something else they are not identifiable.
The system is only able to notify partially for those not updated but it
is not possible to identify if you are working on another repository it
is not identifiable but it will be only if the vcs field will be
manually changed, so it is up to the maintainer to change it, in
addition there is a slight problem that it changes only with a new
upload, if a lot of time were to pass and a lot of work was done during
it would not be possible to notice immediately. In some cases you could
move the repository or notify the move inside but unfortunately in the
case of repositories on which you do not have permissions (for example
in abandoned packages and someone is about to adopt or recover them).
They seem quite rare but unfortunately they happen. Even if it was
recommended to keep them updated and if it changed update them
immediately doing a new upload just for that doesn't seem like the best
to me, could it be useful to have another way, or is there already one?
anyway this is just a minor thing and even if it were to improve it
would have little influence compared to what I suppose is what has the
most influence
Post by Jonas SmedegaardPost by Fabio FantoniI 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).
```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".
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)
how to do it on a technical level, inside debian/control or in another
way if it was better I don't think it would be a problem, to not disturb
the maintainers too much if you add something you can only put it
recommended and not mandatory.
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.
Post by Jonas SmedegaardPost by Fabio FantoniAnother thing that seems underestimated and I think it is good to
emphasize is the excessive slowness of the wiki.debian.org, it seems
much worse than salsa to me, and I think it's important to solve.
I don't think that the speed of wiki affects the use of Salsa.
Please stick to the topic - i.e. if you want to shift to another topic
then do so explicitly by changing the Subject: line in your email post.
I think it is part of the main problem that is being discussed, not only
should we try to increase collaboration but I think it is useful, or
perhaps even more relevant, analyze carefully what the ways can help to
increase the contributions.
Increasing collaboration may indeed lead to improvement but increasing
contributions and contributors could in practice lead to even greater
overall results.
creating a single recommended method or collaborative forced more bring
could bring more contributions in different but there is also the risk
that they decrease in parte for unfavorable or struggling contributors
with any new obligations (this is why I think it is better to suggest or
recommend rather than force in some delicate parts such as those being
discussed here)
I would say to also think in terms of number of contributors and number
of contributions.
as for new contributors it is important to find the information needed
to learn and especially for those who want to try even just with
something small and targeted to succeed, the time spent is also relevant.
both general information about the packaging, and specifics of some less
common parts, and specifics regarding the development of the individual
packages (and the eventual team)
I think finding information quickly and easily is quite important, being
able to make the first contributions quickly enough and without
technical obstacles (from errors, temporary unattainability, frequent
minor slowdowns and occasional major ones) I think has a great influence
on the possible arrival of new contributors or even just occasional
contributions on single packages and I think more than the method used
for example if I was a new contributor or occasional contributor and I
tried to contribute and I found myself having problems on the wiki,
salsa or even packages.debian.org (as happened a few days ago) I would
90% give up
while the possible improvement of the collaboration method proposed here
I suppose could only influence between 10-30% more possible
contributions, but focusing all or mainly on salsa without having less
problems and slowdowns on it I think would increase the risk more rather
than any patches on the bugtracker via email which has little effect on
the fact even if it takes minutes to process the emails.
To sum up, I suppose that such things entail a high risk of losing
possible new contributors and/or contributions (even occasional ones), a
medium risk for occasional contributions from those who have already
contributed previously and a risk also of decreasing contributions from
those who contribute normally.
if you want even just a practical piece of data on some cases in which
the slowness, unattainability and problems of salsa, salsa-ci, wiki and
in some cases other parts have influenced my contributions:
there have been a few dozen times when I had some time and desire to
contribute but due to problems with salsa I gave up as soon as I started
for that day, others (also dozens) when I had started but then within a
maximum of half an hour or an hour with problems I stopped (there is
already work that stresses me, I don't want to try to contribute on open
source projects, in this case Debian is the same)
there have been cases in which I continued and did it even if it took
more time, with the same amount of time I could have done more without
any problems, but I don't know how to quantify it
there have also been cases where I wanted to make occasional
contributions to help packages that I use but do not maintain because I
have seen them with RC bugs, not updated for a long time or some rare
case for other problems but I have been discouraged by the difficulty
and the time required (even though many were small things). in these
cases you might think that the main problem was the difficulty of
collaboration of that package, to a large extent yes but less than you
might think, having all the projects on salsa and preferably in a team
would have helped in several of these cases but not many (right now I do
not have enough memories to give a possible quantity)
another thing that I think is a perhaps underestimated obstacle for new
contributors, and contributions. DD that help those trying to contribute
on mentors, possibly also DM to give advice, information, start
reviewing, at least someone I saw recently tried to give some visibility
to this problem here. you could advise new contributors about git, salsa
contribution methods, direct them to a team, if the package they want to
add could be in a team (these things for example are related to what you
would like to do in DEP-18). but then much more useful in practice is if
contributors find help, answers and if they manage to make good
contributions get accepted (preferably in a not too long time).
getting back to salsa here's a tip that I think would be a great help in
understanding how to proceed with DEP-18: make quick polls open to all
DDs, DMs and possibly other occasional contributors (mostly multiple
choice). to be able to know how good salsa is considered, how useful
they consider its use, what the main problems are (here I recommend
something specific at least to know how much they impact performance and
service issues in practice)
another practical thing prerequisite of DEP-18, it talks about a massive
use of salsa-ci, but are there resources to make it possible, and that
it works well? some possible limitations seem to be explained here
already:
https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_511732
but even if it became only recommended, as I also think it is very
useful for most packages (It helped me a lot to avoid some mistake and
improve the quality of the packages in less time, at least when it works
properly and in a fairly short time), it would have a significant weight
on the hardware level. furthermore, excessively long times due only or
almost only to overloads or failures not due to the package would weigh
negatively on the maintainers and if it were forced it would be a
negative weight I think greater than forcing the use of salsa
another thing i wonder are there any plans for improvement, someone know
what is needed? This is for both salsa-ci and salsa and wiki. would you
say if there is a need and how to contribute? I can't find anything
specific and the generic page on how to contribute
(https://www.debian.org/donations) seems a bit vague and lacking in
information, or I'm wrong?
Post by Jonas SmedegaardPost by Fabio FantoniIf someone thinks that these speed/reachabilityare not important because
they are used to even longer times for many operations, for example
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 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.
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)
Post by Jonas SmedegaardThanks for your inspiring input,
- Jonas