[rkward-devel] Moving to KDE: Where exactly are we heading?

[Thomas Friedrichsmeier]

Hi!

I had hoped to write this mail, much earlier, but I was too busy...

Now that we have released RKWard 0.6.3 as the first release on KDE.org,
it's time to think about the next steps. In principle, those are - not
necessarily in this order:

- Decide which module we want to be in (see below)
- Move to "kdereview"
- Port to KF5

This mail is about the first of these steps. Here, basically, we have
the choice between "extragear/edu" and "kdeedu". Frankly, I don't think
I really understand the implications of either choice, I hope Mario can
clarify a bit. What I do understand so far, is:

extragear/edu:
- We'll continue to release on our own schedule
- Creating the releases is our own responsibility as before
- Compared to our current status, we could probably count on getting
  _some_ more attention from distribution packagers, but not necessarily
  a whole lot.

kdeedu:
- We'll release on the same schedule as KDE Applications. For what
  that would mean, see e.g. the 15.04 release schedule:
https://techbase.kde.org/Schedules/Applications/15.04_Release_Schedule
- The releases will be created for us, automatically, but this probably
  means we will have to make some adjustments to our existing
  release scripts. Mario: Exactly how are the release tarballs created?
- As far as I can see, we will also have to adjust our git
  branching schemes a bit (not big deal, of course: We'll have to
  follow the KDE naming conventions, _and_ make sure KDE/next is
  _always_ in a releasable state). I am not sure, whether inclusion in
  kdeedu would come with any additional expectations on our development.
- We could reasonably count on getting packaged quickly for most
  OS distributions - except, unfortunately, for the toughest ones: Mac
  and Windows.

So, going to kdeedu looks like somewhat more work, initially, although
probably not too much. So the key question seems to be, whether we
think it is an advantage to follow the release schedule of - most -
other KDE apps, rather than releasing separately as before. Some pros
and cons on this:

- Releasing with the crowd could get us more attention (as we'd be part
  of a large event getting much user and media attention).
- Releasing with the crowd could get us less attention (as we'll just
  be one out of many apps in the crowd, and in many cases the changes
  we have realized will not stand out too much).
- Releasing with the crowd could be a problem, in case we need to make
  an emergency fix for a new version of R. OTOH, the KDE release
  schedule already has monthly patch releases, so we could still
  address problems in a fairly timely manner.
- I am not sure, whether releasing with the crowd could make it harder
  for users to update RKWard _without_ updating all (or most) of KDE. I
  guess this is mostly a question of the details of packaging. It could
  be a problem on some distributions, however.
- As far as release testing is concerned, I tend to think that our
  current approach fits better, as it allows us to do a more direct
  package-feedback-fix-cycle, and I _believe_ our user-base is rather
  unlikely to participate in KDE/Applications release testing at large.

All this with a lot of uncertainty. ATM, extrager/edu would look
somewhat less scary to me, but perhaps that's just cowardice... Your
thoughts?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20150504/d38eb7e1/attachment.sig>