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

[Thomas Friedrichsmeier]

Hi,

On Mon, 04 May 2015 14:48:36 +0200
meik michalke <Meik.Michalke at uni-duesseldorf.de> wrote:
> i'd assume that we'd still keep our communications as is, so
> dedicated RKWard users would still be notified directly.

I guess that in any case, yes.

> i experience this the other way round: there's no backports of KDE
> for kubuntu 14.04 (trusty) since january, stuck at 4.14.2 :-/ if
> RKWard was only released with KDE, how would trusty users receive
> updates?

True, two sides to this problem:

1. Ubuntu 14.04 does not have (any?) kde 5 frameworks, officially. We
will hit this problem at any rate, after porting to KF5. In this case,
we'll simply be missing the basic requirements for providing an
up-to-date RKWard package. There seems to be a PPA for kf5 on trusty,
but that seems to be more bleeding edge, than we'd actually need:
https://launchpad.net/~neon/+archive/ubuntu/ppa/

2. Distribution packagers will generally be unlikely to worry much
about providing backports of RKWard, specifically. If/Where we want to
provide users with the option to upgrade RKWard beyond what's shipped
with their distribution, but not all of KDE, we'll have to continue to
take care of packaging, ourselves.
 
> > - 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.
> 
> can that be combined? keeping our own repository structure with
> backports to earlier KDE versions and internal feedback loops, but
> still release with the crowd anyway?

I think so, yes. At the expense of having to worry both about complying
with KDE release schedules & procedures, and feeding our internal
feedback loop, i.e. a bit more work. It will also still mean some
changes wrt our current release process. E.g. for KDE Applications,
feature and UI freeze is around one month before release, while so far
we've been working on shorter cycles (and occasionally sneaking in a
small new feature during testing).

Just an idea: Suppose we'd essentially follow our current standalone
release procedures,
- including creating, testing, packaging, and offering a release
  whenever we feel like it,
- but continuing to call the "final" release a "stable preview" (e.g.
  0.6.4-stable-preview),
- until the next opportunity to feed it into the KDE Applications
  release cycle,
- at which point it will see no further changes (possibly bugfixes,
  though), except for removing "stable-preview" from the version name.

Mario, would a scheme like this be considered ok'ish? (And do apps in
KDE Applications even come with a version number of their own?)

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/20150505/b908ccb4/attachment.sig>