[rkward-devel] Some thoughts on switching project hosting

[Mario Fux]

Am Freitag, 10. Oktober 2014, 20.38:30 schrieb Thomas Friedrichsmeier:
> Hi,

Morning Thomas

> On Wednesday 08 October 2014 21:26:52 Mario Fux wrote:
> > Sorry for the delay to answer this long email and with my answer it will
> > become even longer but I hope it helps and otherwise just ask and CC: me
> > for
> 
> no problem. This is not something to be decided in an instant.
> 
> Thanks for your answers so far, and for your offer to be our sponsor in the
> incubation process!
> 
> In a very short summary, I think, KDE's main advantages are:
> - Complete hosting solution
> - More focussed community
> - Very low entry barrier for those already involved in KDE
> While on github's side we have:
> - Potentially lower entry barrier for those not yet involved in KDE

Are you sure? I know that a lot of KDE projects get patches via ReviewBoard by 
people not yet having a KDE identity and developer account which seems to work 
quite well.

> - More flexibility at the cost of more fragmentation

Not that I want to talk bad about github, I know it not that good but I just 
want to understand. What's the flexibility of github that KDE doesn't have?

> I continue to lean towards heading for KDE.org. (Plus, perhaps a
> semi-official repo-mirror on github as an outreach to their community?).
> Fans of github, speak up.
> 
> Either way, I'd like to be aware of the main problems before we are
> half-way migrated. So I'll list the points that could be a problem on
> KDE.org (some already mentioned, and commented on, before). Not all of
> these are mission- critical to us, of course. @Mario, for those bits that
> you can't give a definite answer, what is the best place to ask?
> 
> Technical stuff:
> 1) There are a couple of known areas, where we don't comply with KDE's code
> policy, yet. Most of that is fixable, and we are certainly willing to work
> on that (e.g. our plugins are not currently translatable). However, the
> project is quite large, and some of this may take time, esp. when porting
> to KF5 is also on the list. What is the expected time frame for taking
> care of such technical problems. And will this block us from claiming
> rkward.kde.org, making releases on download.kde.org, and using mailing
> lists?

No, this won't block you.

> 2) Two other items on the code policy are a more fundamental problem to us.
> My worry here is not so much about uninformed commits to our repository,
> but it's quite important to know, will this non-compliance be tolerated,
> will it be a problem while under review.
> 2a) For one thing, we do have documentation in docbook format. However, the
> main in-app documentation is based on a custom XML specification.
> Essentially this is for consistency with the documentation format in our
> plugins (where using docbook would have too much of an overhead, and not
> allow certain features, such as dynamically filling in UI labels and
> info).
> 2b) A second thing is staying behind on new library features / continuing
> to use deprecated functions in KDE libraries. As explained, previously,
> this is because our user-base often has very old installations of KDE, but
> very new installations of R, and new versions of R often need new versions
> of RKWard.

I don't think that you'll get a problem with KDE about this. E.g. for KF5 
there is still kdelibs4support. I don't know what's the current plan for 
deprecating it (Kevin Krammer as the KF5 main guy might know). I think it's 
more likely that you get problems in and with distributions, if at all.

> Wiki:
> 3) The KDE wikis, yes I know the theory behind the division into three. But
> I've had trouble finding the info I needed, more than once, in big part due
> to this split-up.

You're right. Theory and practice are not the same as usually ;-).

> For RKWard, a bunch of pages would fit into more than
> one category (several into all three), and I don't think that would really
> help. I'd like to keep the wiki in one place (on rkward.kde.org, once that
> is available). Would that be considered ok? For a decentral MediaWiki
> installation, could KDE.org accounts be used for login?

KDE identify access works for all three wikis so it's possible. About the 
three wikis and an own for rkward that needs to be thought about. I think it's 
possible to have an own wiki but over time people will expect development 
stuff for rkward on Techbase and end user will of course search for end user 
documentation in Userbase.kde.org

> External ressources:
> 4) Some external ressources we might want to keep. The launchpad daily
> builds are useful in their own right, for instance, because they cover
> different series of Ubuntu (and different versions of KDE libraries, BTW).
> I'm not quite clear, what that means with respect to the manifesto's
> continuity
> requirements.

I don't see that this shouldn't work. In fact KDE has quite a good 
relationship with Kubuntu and IIRC they migrated some of their wiki content to 
one (or more) of KDE's wikis.

> Donations:
> 5) We never raked in too much cash, but we are currently accepting
> donations via PayPal and flattr. I once got paid to develop a specific
> feature, and - without getting anywhere near concrete - we have considered
> trying our luck with a fundraising campaign to finance focussed
> development of certain features/tasks. What's KDE.org's take on individual
> projects looking for revenue? (I see amarok is selling T-shirts, digiKam
> is accepting donations)

Yes, indeed, I think the last sentence makes it quite clear (and here start my 
opinion). KDE and mainly the e.V. needs to make this clearer. We have no fixed 
policy about this but I strongly think that we should be clearer here. But 
that's a problem with projects already part of KDE so Rkward would only bring 
some fundraising experience and could help to discuss and find a good solution 
or policy or agreement.

> Timeline and Procedure:
> 6) I think in any case, the first step for us would be moving to a git
> repository on git.kde.org (ok, probably some sort of formal application,
> too; where?).

That would be a sysadmin ticket on http://sysadmin.kde.org/tickets/ to open a 
ticket. And then of course you guys (if you don't have them yet) need 
identity.kde.org accounts.

> Using downloads.kde.org wold have a rather high wanna-have
> rank, as downloads are one area where SF.net tries particularly hard to
> spoil their reputation. The target state would probably be having all our
> services currently hosted on SF migrated to their counterparts on KDE.org,
> and being accepted in extragear.

This should then go through the review process. That means sending an email to 
kde-core-devel that you plan to move rkward from playground or outside ;-) to 
extragear (or kde-edu?) and then people will take a look, see if i18n works, 
code quality, etc. pp. This should and will be a constructive process of 
course.

> But from KDE's point of view, which
> services will be available to us at what stage in the process, and can you
> give any estimates on the timeline?

Normally the services you need you'll get. The only time factor are mostly the 
response time of the KDE sysadmins which is quite fast and great.

> Regards
> Thomas

griits
Mario