[rkward-devel] Some thoughts on switching project hosting

[Thomas Friedrichsmeier]

Hi,

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
- More flexibility at the cost of more fragmentation

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

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

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.

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)

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?). 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. 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?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141010/69e9ccde/attachment.sig>