<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>