Kubuntu and other KDE distribution's use of KDE infrastructure

[Nicolás Alvarez]

2017-01-08 5:02 GMT-03:00 Valorie Zimmerman <valorie.zimmerman at gmail.com>:
> I'm writing at the request of the sysadmins, who would like to hear
> from the community about distributions' use of KDE infra.
>
> I'm part of the Kubuntu community and will use it as the example I know best.
>
> Kubuntu has some KDE wiki pages, found at
> https://community.kde.org/Kubuntu - for which we are very grateful.
> Ubuntu has a wiki we used to use, but between the awfulness of
> MoinMoin and the spam attacks on it, we love being at home at the KDE
> wikis.
>
> For some time we've been using notes.kde.org as well, and are planning
> how to use share.kde.org now that notes is closing down. We'll need to
> set up a Kubuntu group so that all Kubuntu team members who need
> access can actually access the shares. One of the advantages of using
> KDE infra over piratepad or so, is that we can add a password if
> necessary, and share among other KDE packagers if necessary.
>
> We are also interested in having a Phab instance for Kubuntu mostly
> for the todo/workboard. Right now, we're using Trello, but would
> prefer to use Free software if possible. And the beauty of Phabricator
> is that we can keep more of our "stuff" in one place. For instance, it
> includes a wiki as well, which we might use for packaging
> documentation. Very slick to have all our packaging stuff in one
> place.
>
> However, the sysadmins would like the KDE community support for this,
> since it could be seen as a "slippery slope." In addition, Ben
> Cooksley said, "we'll need to come up with some guidelines surrounding
> what distributions can ask us for, given the Manifesto / KDE Project
> rules.
>
> I would love to see more KDE distros getting cozy with the KDE
> community because I don't like to see fighting between packagers and
> developers, and communication is key.
>
> Our Manifesto [1] says: Being part of the international KDE community
> conveys certain benefits: ....Make use of KDE infrastructure for
> project hosting. I've noticed that some KDE projects do not use KDE
> infra, such as bugzilla, websites, and even mail lists. I thought the
> rule was that all KDE projects would move to KDE infra, so this
> surprised me.
>
> On the other hand, groups which are associated with the community but
> will never be "KDE projects" such as KDE distros, are not mentioned in
> the Manifesto. We do already host the KDE Packagers list [2], and
> Distributions list [3] which supports the Distribution Outreach
> Program [4].
>
> What do you say? Obviously we want to support KDE distributions. Where
> do we draw the line?

This is a general reply to the thread. With my sysadmin hat on: Giving
Kubuntu a Phabricator board is easy, takes negligible server
resources, takes little sysadmin human resources. I could just go and
do it.

The problem originating this discussion is: what do we do if another
KDE-related community (could be a community packaging KDE software for
another distro, or something else entirely) asks for a Phabricator
board too; after all, we helped Kubuntu with the Phabricator thing
before, right? Then someone some little space in our download servers
for beta packages or whatever. Not much storage, not much bandwidth.
Then someone wants to use share.kde.org. Then someone wants a VM to
compile packages for their distro. Then someone else wants
significantly more download server space.

Where do we stop? We have to draw the line somewhere, but I don't know
where. Perhaps making it case-by-case could be problematic, someone
could claim it's unfair to give X to Kubuntu and not give Y to them
because in their opinion Y doesn't need much more resources than X.
Must be Kubuntu favoritism!

But perhaps I'm being paranoid, and trying to define a strict policy
ahead of time will involve even worse bikeshedding and drama, and
case-by-case is good enough.

Maybe we just should create the Kubuntu task board and defer this
issue until the next such request comes. Maybe it will never come.

-- 
Nicolás
KDE Sysadmin Team