Il 03/08/2024 01:28, Jonas Smedegaard ha scritto:
Quoting Fabio Fantoni (2024-08-02 23:51:26)Il 02/08/2024 15:49, Jonas Smedegaard ha scritto: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)Yes, the contact field exists: https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer
I spent a lot of time writing but it seems I didn't manage to convey most of what I mean :(
DEP-18 doesn't seem to me to want to change existing contact methods but to standardize/improve the collaboration part regarding contributing to the development of packages, or am I perhaps missing something?
and I was just thinking about that part and thinking about how to contribute in a package then I did a more extensive and practical reasoning and it seems that in most of what I said I was unable to explain myself
in theory DEP-18 would be great and could produce great results but in practice I suppose there are not enough contributors and enough participation to make it possible (or at most it will be possible on a small part of packages) and so I was thinking about what would be a prerequisite to have more possibilities of contributors and contributions and also possible small improvements on the situation from which we start
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.We all do it as a passion in little free time and not if it were a job. Also Maintainers. What is the point of introducing additional ways to interact with maintainers than the ones that already exist and (as I understand it) is mandatory: A general contact *email* address, and tied to that a connection to the *Debbugs* issue tracker. If a new contributor is unable to contact a package maintainer through that main contact address, then I am concerned about their ability to help out. Don't get me wrong, I do understand how some people can be excellent coders or testers or translators without ever using email, but how can those who are fluent in Gitlab but unable to send and receive emails avoid being a burden in their offers for help to a software distribution which at its very core is email-based? As I see it, those maintainers in Debian - single persons or persons part of a larger team, who chooses to not only handle the mandatory communication channel of Debian, which is email, are free to act as proxies for communication at Gitlab, Matrix and whatever else, as long as they ensure that the communication is proxied (e.g. summarized) to the mandatory communication channels of Debian. It feels backwards to me to start with opening up for more channels, based on a concern for lack of free time, when effectively that is simply pushing the burden to the maintainers to invest the needed time instead. ...unless it is implied that conversations need not reach the current communication channels - which I would find problematic.
staying on the DEP-18 based on what you wrote I'll try another way to explain some concepts I have in mind: if many packages have maintainers who don't even answer emails or take a long time to answer, could making them use a system that requires more time and often has slowness and unreachability problems improve? Telling them that they should pass before each salsa-ci upload with the times that it can require (and that will get worse if it is used even more massively) and often has blocking problems can improve something?
In my opinion, first of all we should improve the system that we want to propose to use more
and before than proposing DEP-18, which I think is in theory very good in general I think we should first focus on other ways to make it more likely that those who try to contribute will stay, DEP-18 is thought to be able to help with this but I think having all the information you need in a simple and fast way always and help is in practice much more effective.
It seems to me that for the most part we only think from the perspective of expert and very patient DDs, who already know most of the information, who therefore have to use wikis and searches little, who even if they find themselves with wiki, salsa, salsa-ci, or other parts not working, very slow or with other problems, know and use workarounds via documentation and local tools.
and this does not help at all to increase contributors and contributions and without them you can also make the best possible system (as quality of packages it could produce), starting from DEP-18 or even more but you will not be able to have great results
you can also have a great system, a great CI, methods that can speed up some operations (like what will be done with tag2upload for example) but you still need people who do it (and more is better), who have the desire and the time to do it
Am I perhaps the only one who sees certain problems?I'm curious to know if I'm the only one who experiences things like this: spend more than 2 hours doing things that should be done in half an hour maximum if salsa, salsa-ci, wiki and packages worked well (example "extreme" but it actually happened to me a few weeks ago).
[comments on wiki disregarded]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)Yes, this is not about money. Maintainers contribute, and should ideally not be stressed by doing so. New contributors are certainly most welcome, and should not be stressed either. And their needs should not cause stress for maintainers. Is that also what you mean, or are you only talking about the needs of new contributors here?
The needs for any contributors
- Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
