[rkward-devel] Some thoughts on switching project hosting

Wed Oct 8 19:26:52 UTC 2014

Am Sonntag, 05. Oktober 2014, 22.07:25 schrieb Thomas Friedrichsmeier:
> Hi,

Good morning Thomas, Meik and Co

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 

> putting Mario in CC, as he might be able to clear up some details, esp.
> with respect to what hosting on kde.org would mean. (Mario was in BCC in
> my first mail, as I wasn't sure, whether that email address was ok to use
> in public).
> 
> On Sunday 05 October 2014 17:12:46 meik michalke wrote:
> > Am Sonntag, 5. Oktober 2014, 09:27:57 schrieb Thomas Friedrichsmeier:
> > > That _is_ a discussion worth having, but right now, my goal is to
> > > explore what hosting requirements we have, and how we would go about
> > > migrating in order to ensure a mostly smooth transition.
> > 
> > i'm glad this comes up :-)
> > 
> > i don't know so much about the infrastructure of KDE, but having seen how
> > smooth it is to host stuff on github, it sure is time to think about a
> > migration, carefully.
> 
> I think github and kde.org are probably not entirely mutually exclusive,
> although I'm not so keen on spreading the project across ever more service
> providers. But of course as git is a distributed VCS, boundaries are much
> less absolute in either direction.
> 
> I don't know too much detail about KDE's offerings and requirements for
> projects, myself, but here's an initial list of pros and cons, based on my
> understand so far:

First it might be useful to read of http://manifesto.kde.org (quite short), 
KDE incubator (https://community.kde.org/Incubator) and maybe the KDE Code of 
Conduct (https://www.kde.org/code-of-conduct/ and longer)
.
> Access control:
> - On KDE we won't have close control over who can commit - err push - and
> who can't. On the other hand, this might encourage contributions from the
> KDE community.

That's right. If you have commit access on the KDE infrastructure you can 
commit (almost, www is an exception) everywhere. But actually I don't know of 
any problems with this to this point in time. And we're still using VCS 
systems which can revert, right ;-)?

> Code policies:
> - On github.com we'd have all freedom. On KDE.org, applications are
> expected to comply with a few rules
> (https://techbase.kde.org/Policies/Application_Lifecycle). This could
> actually be a bit of a problem, as so far we have been deliberately _not_
> following certain developments in order to keep backwards compatibility
> with earlier kdelibs releases as much as possible.

I just took a short look at this Application lifecycle page and I think this 
makes sense and might guarantee a certain amount of quality. But for KF5 based 
application and the widening to more platforms (as well on the CI system 
builde.kde.org) some things might change. In general we're always open for 
discussion.

> @Mario: Background is that a good deal of our users is highly conservative
> about updating anything on their system _except_ jumping head-first to each
> new release of R.

I experienced this myself while using rkward for my diploma thesis in the 
recent months.

> Problem is that fairly often, new release of R required
> changes on our side. So our latest code always had to be both forward
> compatible with the latest R, and backwards compatible with pretty dated
> kdelibs. Of course, when porting to KF5, we'll have to make a clean cut,
> anyway. However in the not too distant future, we may again want to stay
> behind on some changes in KDE. Exactly how much of the problem is that?

Actually I myself would like to see some versions of kdelibs to be supported 
for a longer time (I'm a Debian user ;-) and I know of other people and 
projects (e.g. Calligra) as well but currently kdelibs and KDE Frameworks 
doesn't have too many human ressources ...

So at large it sounds like an interesting new project and usage example for 
KDE and I think these "problems" are solvable. But people with more technical 
knowledge (in particular about kdelibs) might help you better with this.

> Bug tracking:
> - On github, we'd have a separate tracker for ourselves. On kde.org we'd be
> yet another category inside a huge bugzilla. OTOH, this would make it much
> easier to forward kdelibs-/ktexteditor-related bugs, or even weed these out
> on submission (if they have been reported, before).
> - I don't think there are any fundamental differences regarding integration
> of bug tracking with wiki / commits / etc.

What about more manpower for bug triaging and Co?

> Web hosting:
> - KDE.org offers projects subdomains of kde.org (@Mario: Only once accepted
> into extragear, or already in earlier phases?).

I think we're quite flexible here as well. I'm currently incubating kdenlive 
and they used kdenlive.org till now. There code is already on KDE 
infrastructure but the mailing list is still on sourceforge and the tracking 
system is Mantis. So it's work in progress and a lot is possible. One of the 
end goals is just that the KDE sysadmin group has access to all the 
infrastructure (see Manifesto from above) for the worst case (which happens 
more often than wished).

> AFAICS we'd have pretty
> much all the flexibility we'll ever need, there. Not sure on the
> maintainance burden, though. Github seems much more reduced in comparison.
> I think for the project's main user-facing landing page, github just isn't
> shiny enough.

About git and KDE infrastructure. We're currently evaluating new systems for 
our git infrastructure. For review e.g several KDE projects use Review Boards 
and some started to test Gerrit. And our sysadmin are evaluating other git 
project software (don't know the correct term) like gitlab and Co. If you'd 
know of something else that scales. KDE (btw, "KDE" is the community and not 
the software) is meanwhile quite big and has a lot of different projects. Even 
some web software (js, php and Co) and GTk based software...

> Downloads:
> - @Mario, how exactly are KDE extragear projects expected to distribute
> (binary) files? Are there any limits on what / how much can be offered for
> download?

KDE has some kind of CDN, IIRC. Ben Cooksley knows a lot more about this 
myself. But IIRC we distribute quite some data. The biggest distribution 
software yet was afaik Ministro (the Qt Android library loader for Qt4). I 
don't think, this will be a problem. http://download.kde.org might tell more 
and has a mirror network behind it, I think.

> Wiki:
> - KDE has some central wikis (techbase, community, userbase), although the
> division between these has always been confusing to me. On github the wiki
> would remain separate. Probably we could host a custom wiki on
> rkward.kde.org, too.

Let's try to explain it in a few words:
- Userbase.kde.org: Enduser documentation
- Techbase.kde.org: Documentation for developers
- Community.kde.org: Wiki for coordination and organizational work

It's btw a Mediawiki and has some translation teams behind it.

> Translations:
> - KDE has a translations team, that hopefully will help us out. On github,
> we'd have to stick with a separate solution (currently
> translations.launchpad.org).

I think this could definitely be of value for you. Our translation and 
documentation team!

> Other tools:
> - KDE.org has reviewboard, which I like a lot. I don't have first hand
> experience with pull requests on github.

See above about Gerrit and Co. GCompris, another project in the incubator, 
tested the new gitlab based software.

> Community:
> - On KDE.org there's definitely more hope that skilled folks will help us
> with certain tasks. If it's not coding or documentation, it might still be
> packaging. IMO, that's probably the biggest selling point for kde.org.

Oh I think there are other selling points as well ;-). All in all the bus 
factor of your project goes down ;-), the translation and documentation team, 
our sysadmins, our community and support, our distributions network at 
download.kde.org, possible sprint funding, dot.kde.org as a good promo and 
news source, fundraising help, certain marketing experience, sprints.kde.org, 
todo.kde.org, our technical knowledge, build.kde.org, legal benefits via KDE 
e.V. etc. pp.

But I of course think as well that rkward would be of value for KDE. First 
it's a great piece of software in the edu and scientific field, then you've 
some experience with other platforms which I (and we) would like to spread 
more and you've some experience in using kdelibs and how to keep it 
compatible. And there is for sure more where we both could benefit.

> The brand:
> - Regardless of how we feel about either brand, we're technically bound to
> KDE for good, anyway.

As you might have seen KDE goes more and more in the direction of an umbrella 
project for different software (and art and book and ...) projects. Something 
like Mozilla or even more Apache but for enduser software.

> What I think so far:
> - Hosting on KDE.org seems rather natural for a KDE project targetting end
> users. The biggest question is whether we can and want to follow all rules
> KDE.org expects from us.

We and I'd love to have you closer and collaborate more. But I think at this 
point again it's really good to take a look at manifesto.kde.org. Short and 
quite precise and tells you fast if it's the right decision for you as a 
project to become part of KDE. With its benefits and commitments. But the 
manifesto as well is a living document.

Oh and if you don't like something about KDE. Please tell me and us.

> --
> 
> > how about something along these lines:
> >  - we make RKWard 0.7.x the first KDE FW5 release branch

Too bad you guys could come to Randa this summer. There were a lot of great 
KF5 guys. But there might be another edition of the Randa Meetings and Akademy 
next year.

> >    - it starts with a new git repo, no matter where
> >  
> >  - RKWard 0.6.x remains as the KDE 4 branch, at least as long as 4.14 is
> >  
> >    commonly used; it will however only get bug fixes, development
> >    focusses on 0.7.x
> >    - it stays on sf.net SVN
> >    - later on, it can be moved to git as well, which shouldn't be so
> >    painful
> > 
> > because there's no urgency
> 
> Mostly agreed, except for developing one branch in SVN and the other in
> git. Cherry-picking commits from the active development branch into the
> compatibility branch is actually one of the git-features that I am really
> looking forward to using.
> 
> An SVN on sf.net will in fact be needed for a while but it can simply be a
> mirror of the git-repo, or even just left in it's current state. After a
> rather short while it can be marked as out-of-date (by breaking any build-
> attempts with an informative message). Here's another sketch of the plan:

Oh and we've some persons that can help to migrate from svn to git. There is 
quite some experience.

> 0. Create a git repo, importing the current SVN.
> 1. Create a branch "kf5transition" for porting, and start hacking away.
> (This could even be done before we have a git repo, but we'll assume this
> order, here. All further steps assume the git repo is already created).
> 2. Create a branch "kde4" for the compatibility releases.
> 3. Point all people and scripts building from SVN to the "kde4" branch in
> git. 4. Break build-attempts from SVN trunk with a message pointing to the
> "kde4" branch in git. This is in order to catch those, we did not
> think/know about. SVN is left in this state, and gets no further updates.
> 5. Merge "kf5transition" into master.
> 6. Develop on master, cherry-pick easy and important stuff into "kde4".
> 
> > as a side node: github has wikis for its projects, and kind-of offers
> > downloadable binary files:
> > https://github.com/blog/1547-release-your-software but it's probably
> > easier to host bundles somewhere else.
> 
> Regards
> Thomas

So thanks for reading till here and just ask if I can clear any other things. 
Hope to hear soon from you and would be glad to be your sponsor for the KDE 
incubation process.

griits
Mario