Added blocking label

Removed blocking label

mentioned in issue devuan-maintainers#17

why not useDevuan Projectand put the packages there? (aka/devuan/<package-name>)

How is having non-package projects in this group affect the release process? I guess having the global milestones here in/devuan/devuan-projectmakes it easier to track package issues globally--but only if the package projects are also in the same group.

I guess what we don't want here is an "upstream source code repository" (as opposed to a devuan package): wiki-only projects, or issue-only projects should be fine.

Other groups in/devuan-*:

• Doc Devuan
• Devuan Editors
• Devuan Security

We could simply reserve thedevuan-*namespace for internal project teams, and usedevuanas the public facing project for the core distro.

WDYT?

1. devuan-project already has a number of non-package projects in there.

2. it means that we'll need to code around non-package projects if we introduce automations like auto-builds for reproducibility, or walking the packages and doing automated update and build from upstream sources etc.

3. devuan-packages is obvious and self describing with regards to it's purpose.

---

For cross group milestones, raise an issue reference the other groups milestone ie:

Depends: https://git.devuan.org/groups/packages-base/milestones/graphics-for-beta?title=graphics+for+beta

1. Most of the non-package repositories are internal or private: that can be a criteria for matching the packages.

2. Coding around should be easy:

• devuan-maintainers and devuan-documentation can move out to /groups/devuan-doc
• devuan-repository-masters I don't know... Maybe we can tag projects (infrastructure, governance) and match that
• devuan-project itself doesn't have code repository beyond its README and that can be removed.
• others are private groups. That means we only need to avoid devuan-repository-masters (which could be a simple wiki without code, and if code is needed, it can be packaged)

3. OK. Devuan is pretty obvious too and it brings a central issue processing that we were missing.

4. devuan-doc, devuan-editors, and devuan-security are team-oriented groups, and it makes the whole thing consistent: package -> devuan; team -> devuan-$team

5. We can add more devuan-* groups as we need, their code there will be upstream, and can be packaged like any other upstream repository (including PPA)

1. We shouldn't need to filter at all and relying on internal or private sharing status is not in anyway clearly reflective of package vs non-package.

2. That's all unnecessary work to get around and is maintenance intensive - every time a new project is created we'd need to make sure it is tagged right etc.

Also Lumping governance, infrastructure and non-packaged documentation in with packages just muddies the waters and the milestones will mean less on face value. If we keep packages in their own group, we can track number of packages as well as RC Bugs for each release separately from infrastructure and governance issues.

3. I disagree with the naming - devuan is very meta and can mean multiple things from the project, to the community to the distrobution etc, whereas devuan-packages is very specific and provides a clear description of it's purpose - "this is where I'll find devuans sources used to build the packages"... hmmm maybe we should call it devuan-sources instead ;-)

4. using team oriented groups in gitlab seems somewhat superfluous, although there may be good cause to for meta-projects for them ase we already do for a place to handle issues and wiki where there is no packaging happening. Also security patches should always merged into and built from a branch in the official project and not kept in a fork. Otherwise those security patches may be lost to the main package.

So the working solution is to move all package sources todevuan-packages, at https://git.devuan.org/devuan-packages .

I guess this issue can be closed now.

Given that nobody seems to care I'll post a global gitlab message giving a last minute response and start moving in earnest tomorrow.

Once the move is complete I'll close the issue.

Here's a list of concerned groups:

• @pkg-x11
  • removed empty group
• @pkg-web
  • removed empty group
• @pkg-libs
  • movedlibvirt
  • removed group
• @utils
  • movedkbd
  • removed group
• @xul-ext
  • removed empty projectwiki
  • movedublock-origin
  • added issue devuan-packages/ublock-origin#1
  • removed group
• @dev
  • removed empty group
• @pkg-admin
  • movedsysvinit,init-system-helpers,upower,rsyslog,procps,gdisk
  • removed group
• @net
  • movedcups,simple-netaid,openssh,openvpn
  • removed group
• @xfce
  • movedxfce4-power-manager,xfce4-session
  • removed group
• @un-systemd
  • movedlogoutd @devuan-for-review
  • removed group
• @gnome
  • movedgvfs
• @devel
  • moveddh-make,devuan-lintian-profile
  • removed group
• @pkg-qemu
  • movedqemu,ksmtuned
  • removed group
• @d-i
  • movedhw-detect,preseed,firmware-reqdto @devuan-for-review
  • movedlive-build,base-installer,debian-installer,tasksel,debootstrap,main-menu,netcfg,pkgsel,jessie-support,choose-mirror,net-retriever,rootskel-gtk,rootskel
  • removed group
• @hardened
  • no devuan package (rename devuan-hardened?)
• @pkgs-multimedia
  • movedffmpeg,jackd-defaults,x265
  • removed group
• @doc-shipped
  • no devuan package (move to devuan-doc?) doc-shipped/iso-docs#1
• @webdev
  • no devuan package (move to devuan-editors? archive?)
• @pkgs-games
  • movedfortunes-devuan-quotes
  • removed group
• @pkgs-lsb
  • movedlsb
• @pkgs-utopia-substitution
  • nothing is built yet (rename devuan-something?)
• @packages-base
  • movedpulseaudio,util-linux,base-files,dbus,devuan-baseconf,util-linux,pinthread,udisks2,bash-completion,compiz,policykit-1,pcsc-lite,packagekit,devuan-keyring,tasksel,xfce4-session,cgmanager,network-manager,sane-backends,colord,cowdancer,lightdm,dput-devuan
  • removedinit-system-helpers(we already have it frompkg-admin)
  • removed obsolete repoold-xfce4-session
  • movedxfce4-power-managerto @devuan-for-review (seems to be younger than the one moved frompkg-x11)
  • removed group

1. Some of these groups might have non-package projects: these should stay where they are.
2. Packages moved todevuan-packagesshould becomeorigin, and developers should maintain their private or groups forks. This ensures the package source repository will always be up-to-date.
3. Empty groups after the projects are moved should be removed.

Remaining:

• @un-systemd: should logoutd be moved to devuan-packages or a personal repo?
• @gnome : move all but keep the group?
• @d-i : move all of them?
• @packages-base: pending review: xfce4-power-manager (seems to be younger than the one moved from pkg-x11)

Extra:

• @hardened : rename it to devuan-hardened?
• @pkgs-utopia-substitution: rename devuan-something?

@un-systemd/logoutd can go to @devuan-for-review

@gnome : move gvfs to @devuan-packages and create an issue for it's cleansing by milestone 1.0 RC - leave the rest there for now.

@d-i : hw-detect, preseed, firmware-reqd to @devuan-for-review the rest to @devuan-packages

leave @hardened as is... could be source for a derivative distro

OK, all done.

gitlab changes all done to match too.

I figured out that creating a new milestone with the same name as an existing milestone is a quick way to add a all the current group projects to the existing milestone of the same name - and it retains the existing issues too.

Status changed to closed

Removed awaiting feedback label