Kubuntu and other KDE distribution's use of KDE infrastructure

[Ken Vermette]

For my $0.02, any distribution or parent sponsoring KDE development by
becoming a member (€1000/yr for companies, €100/yr for individuals) could
see that commitment met with infrastructure on our end as an optional perk.
This helps justify their financial contributions, and it gives us more
opportunity to help our supporters. Or, if this runs afoul of something (I
don't know the legalities) establish this as a standalone service of some
type.

Supporters fitting this bill could make use of our infrastructure as long
as the distributions/flavors using that infrastructure ship Plasma Shell
and/or KDE applications. In this case Canonical could use KDE infra for
Kubuntu tasks, but not for Ubuntu tasks. In exchange they get a phab
instance, some share space, and we could see what other potential services
we may want to roll in, as feasible and requested. We would also want to
keep services offered this way as "standard", so we don't start making
exceptions. If one distro wants to, say, host ISOs on KDE infra, we need to
be prepared to allow all participating distros to do so - possibly saying
"no, that's not in scope".

The requirement for financial support draws the line for randos claiming
unfair favoritism. While it may initially sound harsh because not everyone
has cold hard cash, for hobbyist distributions without corporate backing I
personally believe €100/yr isn't prohibitive and it's justified in the
sense that it helps pay for the costs of power, bandwidth, and hardware.
Even if those costs are negligible now, in 10 years the costs could be
justified if we have several distros using it, especially if we expand the
offerings over time.

In this case, Canonical is a patron, so Kubuntu, under Canonical, would
fall under this this umbrella.

About the only issue is "what happens if they do not renew their
memberships/patronage?". It's not so nice to suggest that a community
project might need to pull the plug on some people occasionally, but at the
same time if we want to offer good serious services with support, we need
to demand a level of seriousness from those who want it. I love the
attitude of "lets just give it to em and we'll go from there", but I see
doing something like this up-front as just more sustainable and clear-cut...

On Sun, Jan 15, 2017 at 11:13 PM, Nicolás Alvarez <nicolas.alvarez at gmail.com
> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170116/4144973e/attachment.htm>