[rkward-devel] Some thoughts on switching project hosting

[Thomas Friedrichsmeier]

Hi,

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:

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.

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

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.

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

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?

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.

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

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

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.

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

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.

--

> how about something along these lines:
> 
>  - we make RKWard 0.7.x the first KDE FW5 release branch
>    - 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:

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
-------------- 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/20141005/0b2335fe/attachment.sig>