Hi, >> 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.
This is only for a case when member should have push access to the main git repo. But now this is not necessary if we use GitLab feature Merge Requests. Any member of Salsa may "fork" any public git repo in one (or two) mouse clicks. Then do any necessary changes in this "fork" and send Merge Request (MR) in two mouse clicks from web-page of this "fork". Let's look at an example of git repository AliothRewriter [1]: 1) Go to page [1] and click on "Fork". (One more click will be required if you have at least Master level of access in any Salsa group.) 2) Next, in local system: git clone g...@salsa.debian.org:<your-login>/AliothRewriter.git cd AliothRewriter # For the future: git remote add upstream https://salsa.debian.org/salsa/AliothRewriter.git git pull --all # git checkout -b qt-kde-team nano definitions/qt-kde-team.conf git add definitions/qt-kde-team.conf git commit -m "Update qt-kde-team.conf" git push origin qt-kde-team 3) Go to page [2] --> "Branches" --> "Merge request" --> "Submit merge request" And it is ready! 4) If during reviewing of MR "upstream" has requested any changes, then: nano definitions/qt-kde-team.conf git commit --amend -a git fetch upstream git push origin qt-kde-team -f And thus MR is updated automatically. Very fast and simple way from my point of view. Salsa members who have write access to this git repo may push their commits directly into working branches. In case of independently maintained package a write access should have al least Maintainer and Uploaders. In case of team maintained packages it depends on team rules. If you have another workflow in mind, please share your thoughts in more details. [1] https://salsa.debian.org/salsa/AliothRewriter [2] https://salsa.debian.org/<your-login>/AliothRewriter -------------------------------------------------------------------------------- >> 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. Hmm, a nice idea. I will adopt it in my next uploads. -------------------------------------------------------------------------------- >> 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. Some of them really "should". Few examples from my personal experience: 1) Package xembed-sni-proxy [1]. Project initially have been developed on GitHub [2], but later it was moved in KDE and has become the part of plasma-workspace. 2) Package qtcurve [3]. Project initially have been developed without VCS, then its development was moved to GitHub [4] and now it is a part of KDE [5]. [1] https://tracker.debian.org/pkg/xembed-sni-proxy [2] https://github.com/davidedmundson/xembed-sni-proxy [3] https://tracker.debian.org/pkg/qtcurve [4] https://github.com/QtCurve [5] https://cgit.kde.org/qtcurve.git Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
