Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
Hi Fabio,Quoting Fabio Fantoni (2024-08-02 14:31:04)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.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
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).I guess that you mean something like this: ```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)
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.
Another 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?
If 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)
Thanks for your inspiring input, - Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
