Access level for members of Debian Qt and KDE Team group at Salsa

[Boris Pek]

Hi,

>> I think that package maintainers should have a Master level of access
>> to be able to create or to import git repos in the group [1].
>> Al least DDs. See Debian Science Team group [2] at Salsa as example.
>
> Yesterday we decided that, at least for now, only admins will be able to
> create repositories. We will grant Master access to the whole group to
> people who require it and we admins do trust him/her. Again this is for the
> time being, we can always review this decitions later.

Ok. In this case I may suggest you to use workflow similar to one in Debian
Perl Group [1]. They do not add extra members to the main group [2], but
allow members joining to specific sub-groups (for example, [3]). Though
it is only in plans; they have not done the migration from Alioth and it
is not even documented yet.

[1] https://salsa.debian.org/perl-team
[2] https://salsa.debian.org/groups/perl-team/-/group_members
[3] https://salsa.debian.org/groups/perl-team/modules/-/group_members

> I think it is possible to give Master access to specific repos, that should
> be the case for people maintaining specific packages in *-extras.

I think the Developer level of access or even per-package permissions are
fine for packages in KDE, Qt and Third-party sub-groups, because they are
maintained by a small group of members.

But with *-extras sub-groups the situation is a bit different. For example,
the "Debian KDE Extras Team" is not a real Debian team where package
maintainers discuss packaging issues, ask for package "sponsoring", etc..
This is just a set of packages in which maintainers decided to to set
"Debian KDE Extras Team" as Maintainer to accent that package is somehow
related to KDE (or Qt) and to see it at page [4]. (But nevertheless even such
approach is more convenient and solid in a long perspective than maintaining
such packages singly [5].)

Currently in Debian we have a tendency to maintain new packages in teams since
the beginning. And I believe that the number of packages in *-extras will be
growing in the future. Do you really want to be pulled each time when new git
repo is asked to be created there? Or when new uploaders will ask for push
access to specific git repos...

[4] https://qa.debian.org/developer.php?email=pkg-kde-extras%40lists.alioth.debian.org
[5] Main maintainers of a package may be busy or MIA and "team uploads" are
    more flexible than MNUs.

> I did not yet got to publish our results from yesterday, so info might be
> missing. I hope to do it soon.

Now I see changes at [7]. It has enough info for common idea about results.

Few questions and comments:
1) Are you going to import all git repos from [6] to [7] (semi-)automatically?
   Or package maintainers should do it them-self?
2) I am glad to see that pkg-kde-talk and pkg-kde-extras MLs will stay alive.
3) As for packages for KDE-extras and Qt-extras: apart from described not
   "core" projects there are a number of projects which are developed outside
   of KDE (or Qt) infrastructure [8], but closely related with KDE (or Qt).
   And they also could (or should) be maintained in Qt/KDE Extras Team.
   .
   From other side, there are some projects developed inside KDE, which do not
   use KF5 libraries but are based on pure Qt.
   .
   So I suggest do not use the location of source files as a criteria for
   directing packages into KDE-extras or Qt-extras sub-group, but use their
   dependencies for this purpose.

[6] https://anonscm.debian.org/git/pkg-kde/kde-extras/
[7] https://salsa.debian.org/qt-kde-team/kde-extras
[8] Yes, quite often such projects sooner or later are moved to KDE, and
    sometime even become a part of "core" projects.  But this is completely
    another question...

>> As a side note: could you add small description for the main Debian Qt
>> and KDE Team group at Salsa? (There are descriptions only for subgroups
>> for now.) At least a hyperlink [3] would be useful. (Until it will be
>> moved to Salsa pages.)
>
> We noted this today. I wrote down some ideas in gobby/Teams/KDE/salsa, but
> we might need to reconsider the use of kde-extras or at least define exactly
> what each subgroup is for.
>
> Yes, we missed that point yesterday I'm afraid.
>
> Thanks for chiming in!

Thanks for fixing this.

And few more side notes/questions:

Last night I have updated Debian Science Policy Manual [9] to reflect the
changes after moving git repositories from Alioth to Salsa. It might be
interesting to you.

The question is: do we have a similar policy manuals for Debian Qt/KDE
Maintainers and Debian KDE Extras teams? I failed to find them. Could you
give me a link?

[9] https://science-team.pages.debian.net/policy/

Best wishes,
Boris