[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Kubuntu and other KDE distribution's use of KDE infrastructure
From: Ken Vermette <vermette () gmail ! com>
Date: 2017-01-16 17:51:11
Message-ID: CAFtcy6xpXv2LApRgOXGrLnfr+6ifwqVnucAS7BAutzTx7_Bs=A () mail ! gmail ! com
[Download RAW message or body]
For my $0.02, any distribution or parent sponsoring KDE development by
becoming a member (=E2=82=AC1000/yr for companies, =E2=82=AC100/yr for indi=
viduals) 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 =E2=82=AC100/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=C3=A1s Alvarez <nicolas.alvarez@gma=
il.com
> wrote:
> 2017-01-08 5:02 GMT-03:00 Valorie Zimmerman <valorie.zimmerman@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=C3=A1s
> KDE Sysadmin Team
>
[Attachment #3 (text/html)]
<div dir="ltr"><div><div>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.<br><br>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".<br><br>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.<br></div><div><br></div>In \
this case, Canonical is a patron, so Kubuntu, under Canonical, would fall under this \
this umbrella.<br><br>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...<br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 15, 2017 at 11:13 PM, \
Nicolás Alvarez <span dir="ltr"><<a href="mailto:nicolas.alvarez@gmail.com" \
target="_blank">nicolas.alvarez@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">2017-01-08 5:02 GMT-03:00 \
Valorie Zimmerman <<a \
href="mailto:valorie.zimmerman@gmail.com">valorie.zimmerman@gmail.com</a>>:<br> \
> I'm writing at the request of the sysadmins, who would like to hear<br> > \
from the community about distributions' use of KDE infra.<br> ><br>
> I'm part of the Kubuntu community and will use it as the example I know \
best.<br> ><br>
> Kubuntu has some KDE wiki pages, found at<br>
> <a href="https://community.kde.org/Kubuntu" rel="noreferrer" \
target="_blank">https://community.kde.org/<wbr>Kubuntu</a> - for which we are very \
grateful.<br> > Ubuntu has a wiki we used to use, but between the awfulness of<br>
> MoinMoin and the spam attacks on it, we love being at home at the KDE<br>
> wikis.<br>
><br>
> For some time we've been using <a href="http://notes.kde.org" \
rel="noreferrer" target="_blank">notes.kde.org</a> as well, and are planning<br> > \
how to use <a href="http://share.kde.org" rel="noreferrer" \
target="_blank">share.kde.org</a> now that notes is closing down. We'll need \
to<br> > set up a Kubuntu group so that all Kubuntu team members who need<br>
> access can actually access the shares. One of the advantages of using<br>
> KDE infra over piratepad or so, is that we can add a password if<br>
> necessary, and share among other KDE packagers if necessary.<br>
><br>
> We are also interested in having a Phab instance for Kubuntu mostly<br>
> for the todo/workboard. Right now, we're using Trello, but would<br>
> prefer to use Free software if possible. And the beauty of Phabricator<br>
> is that we can keep more of our "stuff" in one place. For instance, \
it<br> > includes a wiki as well, which we might use for packaging<br>
> documentation. Very slick to have all our packaging stuff in one<br>
> place.<br>
><br>
> However, the sysadmins would like the KDE community support for this,<br>
> since it could be seen as a "slippery slope." In addition, Ben<br>
> Cooksley said, "we'll need to come up with some guidelines \
surrounding<br> > what distributions can ask us for, given the Manifesto / KDE \
Project<br> > rules.<br>
><br>
> I would love to see more KDE distros getting cozy with the KDE<br>
> community because I don't like to see fighting between packagers and<br>
> developers, and communication is key.<br>
><br>
> Our Manifesto [1] says: Being part of the international KDE community<br>
> conveys certain benefits: ....Make use of KDE infrastructure for<br>
> project hosting. I've noticed that some KDE projects do not use KDE<br>
> infra, such as bugzilla, websites, and even mail lists. I thought the<br>
> rule was that all KDE projects would move to KDE infra, so this<br>
> surprised me.<br>
><br>
> On the other hand, groups which are associated with the community but<br>
> will never be "KDE projects" such as KDE distros, are not mentioned \
in<br> > the Manifesto. We do already host the KDE Packagers list [2], and<br>
> Distributions list [3] which supports the Distribution Outreach<br>
> Program [4].<br>
><br>
> What do you say? Obviously we want to support KDE distributions. Where<br>
> do we draw the line?<br>
<br>
</div></div>This is a general reply to the thread. With my sysadmin hat on: \
Giving<br> Kubuntu a Phabricator board is easy, takes negligible server<br>
resources, takes little sysadmin human resources. I could just go and<br>
do it.<br>
<br>
The problem originating this discussion is: what do we do if another<br>
KDE-related community (could be a community packaging KDE software for<br>
another distro, or something else entirely) asks for a Phabricator<br>
board too; after all, we helped Kubuntu with the Phabricator thing<br>
before, right? Then someone some little space in our download servers<br>
for beta packages or whatever. Not much storage, not much bandwidth.<br>
Then someone wants to use <a href="http://share.kde.org" rel="noreferrer" \
target="_blank">share.kde.org</a>. Then someone wants a VM to<br> compile packages \
for their distro. Then someone else wants<br> significantly more download server \
space.<br> <br>
Where do we stop? We have to draw the line somewhere, but I don't know<br>
where. Perhaps making it case-by-case could be problematic, someone<br>
could claim it's unfair to give X to Kubuntu and not give Y to them<br>
because in their opinion Y doesn't need much more resources than X.<br>
Must be Kubuntu favoritism!<br>
<br>
But perhaps I'm being paranoid, and trying to define a strict policy<br>
ahead of time will involve even worse bikeshedding and drama, and<br>
case-by-case is good enough.<br>
<br>
Maybe we just should create the Kubuntu task board and defer this<br>
issue until the next such request comes. Maybe it will never come.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nicolás<br>
KDE Sysadmin Team<br>
</font></span></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic