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

Thu Feb 15 14:50:08 UTC 2018

El miércoles, 14 de febrero de 2018 13:27:04 -03 Boris Pek escribió:
> 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.

Well, as far as we do understand if someone wants to provide a branch for 
reviewing then [s]he should be at least Developer, which means commit access. 
Not ideal, but a trade off. Of course, feel really free to correct me if I'm 
wrong.

> [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].)

Well, we are shifting a little from this definition (which still needs 
writing). The idea would be to follow the python's team rule on 
Maintainership: if the Maintainer field has a human being then ask that human 
being before comitting, if it has the team then everyone is entitled to 
commit.

again, things to review now that we are migrating. As pino is maintaining most 
of kde-extras now he might have something to say.

> 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...

Yes. This has proven not to be a problem so far. And as I said, if it becomes 
one, it can be reviewed.

> [4]
> https://qa.debian.org/developer.php?email=pkg-kde-extras%40lists.alioth.deb
> ian.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?

I think Pino is the right person to anwer this. So far Dmitry started trying 
with the Qt part and maxy with kf5, plasma and friends.

We still have SVN too.

> 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. .

Mostly "could". As long as it does not interferes with the main reasons of 
being (qt and KDE stuff), it's could.

>    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.

Right, Luigi Toscano has been telling me this recently. Again we need to 
settle this down yet. We might need another IRC meeting.

> [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.

Thanks. To say the truth I have read the science's policies some years ago and 
I really did not like them. I don't know the current content, but I do like 
the work in the way it's being showed.

> 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?

Sure, not the best but:

<http://pkg-kde.alioth.debian.org/changelogstandard.html>
<http://pkg-kde.alioth.debian.org/qmlmodulesnaming.html>
<http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html>
<http://pkg-kde.alioth.debian.org/descriptions.html>
<http://pkg-kde.alioth.debian.org/gitguidelines.html>

And more pages there.

-- 
Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer
a la comunidad SL como una sarta de fanáticos que viven dentro de un
tupperware.
 Pablo Di Noto - GrULiC

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20180215/7f078921/attachment.sig>