Hi Raphael, Am 02.05.2018 um 10:14 schrieb Raphael Hertzog: [...] > there are multiples similar issues mentioned in your bug report > and you are doing many shortcuts which make it not really actionable I tried to outline the broader picture first because I knew different paths exist to come to a conclusion. Now I'm assuming that you are not completely against the idea but you need some sort of clarification. Feel free to clone the bug into multiple ones because I'm not sure what tracker is already capable of. > The tracker is currently not the canonical place to store all those > values. The information contained in Packages/Sources files are the > reference. Currently they come straight from the source package and you > want to change this. This is only partly correct. My primary goal is to create a feature that allows maintainers to override the values/links of the VCS bullet point in the general section of tracker.debian.org. I imagine if this can be done for one item it should be feasible to generalize the idea but that's not a priority. At the moment I don't need tracker to store any extra data at all or modify existing data except maybe one predefined string: https://salsa.debian.org/ because this one is Debian's preferred VCS host and one or multiple group names which could be derived from salsa.debian.org and Gitlab's API maybe or entered manually by users in their profile. The source package name is already known to tracker. My idea is: It should be possible to select packages based on maintainer name or maintainer address. They ideally should all show up in my account under profile or I could also imagine that bullet points like VCS become editable as soon as 1) I am logged in and 2) I have activated the "edit feature" (Turn on editing? (yes/no) in my profile. Let's assume all my packages would show up under Profile/MyPackages. If I click on the name of one of my packages, it would be like I am in Django's famous admin panel and database entries became editable. For the sake of simplicity only the VCS field is editable now. There would be a selector and I could choose between VCS hosts. salsa.debian.org is the default and my source package name is already inserted. I would only have to choose the group name but maybe even that could be derived from the Gitlab API somehow. Now editing single packages is tedious. Back in "MyPackages" I can select all packages and enter "batch mode" to edit all packages at once. Something like ebay's seller cockpit where you can apply one value to multiple items. If I apply the new value for VCS Git/Browser link, it would show up for all my selected packages. My reasons: The Java team maintains 1000+ packages. Even if it would take only 5 minutes to change the values in debian/control including building the package, this is still a lot of wasted developer time. In the past we have already changed the VCS fields from SVN to Git, from git.debian.org to anonscm.debian.org, from git to https and now we have to do it again for salsa.debian.org. Every change requires a source upload. This is highly inefficient. In addition those changes were never applied at once but step by step when more important issues arose. So there are still packages with outdated links which are broken in tracker.debian.org. Since we have decided to move all packages to Git and salsa.debian.org in our java-team group, we now have a address which is simple to remember https://salsa.debian.org/java-team/mysourcepackage Such a feature would allow us to update all VCS links immediately where it matters most, in tracker.debian.org. > I don't think we want to have this data only in the tracker. We want > to keep it at least in Packages/Sources files. For this we probably want > to use the dak override mechanism to inject up-to-date data. > > So any realistic transition should involve tracker.d.o being able to > export the override data for dak, and being able to manage the data > on its own (while still importing/syncing with whatever is available > in the source package). In my opinion a solution for this bug would not require to get dak involved in any way. VCS fields are optional and are only used in qa.debian.org projects or developer tools. I find the VCS links useful for users who visit tracker to get an overview about a Debian package. As a developer I don't need them at all. I think importing tracker data into dak or other infrastructure is an interesting goal but it adds too much complexity at the moment. > Then not all fields are equal. While homepage is relative clear, the way > to handle maintainer/uploaders is probably different, do we want to > handle it as a simple text field or shall it be generated out of the > package subscription (for example by letting each subscriber choose a > role, eg "follower/lurker", "maintainer", "bug triager", etc.) > > Some of the fields might be set a the package-level, some at the > team-level (and here we come again to the problem of which team is the > authoritative team for the package). Perhaps let us focus on VCS fields first to reduce the complexity. Regarding access rights: Human maintainers are allowed to override the field in any case. If there is more than one human maintainer all can override the field. If the package is maintained by a single team, then only those with permission "owner" in salsa.debian.org are allowed to change the field. If this status cannot be derived from the Gitlab API, then we could create a team role in tracker and assign authorized DDs from those teams to it. I leave it open how this could be implemented. I believe the rule is that there is only one team per package which is the sole maintainer but there can be multiple Uploaders. Is there really a package and two different teams are responsible for it (listed as maintainers)? Then authorized DDs from both teams should be able to override the field. > So while it's great to have a bug report to have this conversation, I > believe that we want to split the problem further down (and possibly > open more bug reports) because right now this request is just too broad > and is lacking too many details to be actionable. I hope I could clarify some goals. I suggest to focus on the VCS links first and then it will always be possible to generalize the problem. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature