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

[Albert Astals Cid]

El Dimecres, 6 de maig de 2015, a les 16:46:35, Mario Fux va escriure:
> Am Montag, 04. Mai 2015, 11.34:08 schrieb Thomas Friedrichsmeier:
> > Hi!
> 
> Good morning Thomas and Co
> 
> > 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,
> 
> Congrats on this.
> 
> > 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:
> I'll try...
> 
> > 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.
> 
> And you'll get more help in i18n/l10n. But that counts for kdeedu as well.
> 
> > 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?
> 
> That's something Albert can tell you much better then me (or correct my
> following assumptions). To be released as part of kdeedu and thus a KDE
> Applications release (next one in August as 15.08):
> - You need to take care of the right version number (so either you follow
> the YY.MM release versions of KDE Application or you stay with your own
> version numbers but need to increase them at the right time too of course
> ;-). 
> - You need to take care of your master branch so it's in a releasable
> state at the right times (when the releases: beta, rc, etc. happen).
> - The release scripts of the release manager takes care of the rest of the
> release process.
> - On the promo/marketing side you should inform (there might be some changes
> on the promo processes in the near future) the kde-promo team about what
> changed and what's worth to be mentioned in the release stories, notes and
> announcements.

Also the rest of the kde+kdeedu world has to agree the application makes sense 
as part of kdeedu.

> 
> > - 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 think it's just master that should be in a releasable state (see above).
> 
> >   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.
> 
> You might want to bring this topic up on the kde-edu mailing list as well.
> If you want I can just CC: this list?

Be easier to start a new thread, it took me a while to understand what this 
email was about, and still not sure i got it all correctly.

> > 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).
> 
> To tell you a current secret: if you tell the kde-promo team about your
> great new stuff in a new release the chances are quite high the your Rkward
> release still stands out in a KDE Applications release. It's mostly hard to
> get information from the app people and teams about what's new in a release
> *kdepromoheadoff ;-)
> 
> > - 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.
> 
> And in the worst case you can still do an own release in between on your
> own, no?
> 
> > - 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.
> 
> This mostly depends on the distributions (Linux) and afaik most of them
> package the KDE apps in separate packages anyway. The KDE Applications
> releases are mostly a common release day and promo work. The apps still work
> separately quite well and of course on other workspaces like Gnome, xfce,
> lxde, etc. and even other OSs (there is working going on for MacOSX and
> Windows on our Contineous Integration infrastructure, MacOSX works already
> IIRC and Windows is a bit more work, so if you've some experience there
> helps and advice is welcome!).
> 
> >   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.
> 
> Why aren't both testing processes possible in parallel?
> 
> > 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?
> 
> In another email your wrote something about feature and UI freezes in KDE
> Applications releases. Please be sure to read the 15.08 release schedule as
> there were some recent changes about the freeze times.
> 
> And to copy from another email:
> > 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?
> 
> I think so. What do you think, Albert?

Dsitributions are going to hate that, you're giving them two things to package 
and they have to decide what to pacakge, and decisions don't make them happy 
(or i totally misunderstood what you want to do, that can also be :D)

Cheers,
  Albert

> 
> > And do apps in KDE Applications even come with a version number of their
> > own?)
> 
> See above about this.
> 
> Hope my email clarified and answered some questions. And otherwise don't
> hesitate to ask again ;-).
> 
> Cu
> Mario