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

[Albert Astals Cid]

El Dijous, 7 de maig de 2015, a les 20:17:01, Thomas Friedrichsmeier va 
escriure:
> Hi,
> 
> this thread is pretty hard to read, indeed. I'll focus on the
> conceptual things for now, leaving the technical details for later.
> 
> On Wed, 06 May 2015 20:41:14 +0200
> 
> Albert Astals Cid <aacid at kde.org> wrote:
> > El Dimecres, 6 de maig de 2015, a les 16:46:35, Mario Fux va escriure:
> > > 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.
> 
> Yes, of course. Right now we're trying to figure out, where we
> think we _want_ to go.
> 
> > > > 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)
> 
> Well, so far I haven't really understood what I want to do, either ;-).
> I'm just exploring our options, here. But the plan would be to stick
> to the global release schedule as much as possible, of course.
> 
> Currently my main concern about this is that this might be not-so-ideal
> when it comes to getting testing feedback from our existing user base
> (rather specialized, rather UI-conservative). Thus, my general idea
> would be to make sure we have essentially finished our release testing
> _before_ the KDE Applications freeze. Then, to keep our testers happy,
> and to bridge the gap between this and the actual release, we'd offer a
> semi-official version roughly at this point.
> 
> Thinking about it, this semi-official version would not even need a
> different name, only we'd advertise this "beta" as a "pretty stable
> preview" on our download page, etc. Thus, also no need for any special
> treatment from distributions.
> 
> So, does that sound like a workable plan, or does this sound like we
> should be heading for extragear in the first place?

Honestly that seems a bit complicated setup that would confused users (or at 
least it would confuse me, "am I using the official release or the official 
official release"?

One of the main benefits of being in KDE Applications is the cadence of 
releases, but since you still want to do the releases on your own, i don't see 
what's the benefit for you, you'd also have your own freezes (i guess since 
you want to be "done" before KDE Applications freeze) which would be ackward 
when getting roaming commits fixing "easy" stuff since it'd not be breaking 
KDE Applications freeze but would be breaking yours.
 
> Also, one more question: _If_ we target inclusion in kdeedu, I suppose
> that will mean we should port to KF5 _before_ entering review? 

Not necessarily, we still ship kdelibs4-based software in KDE Applications 
releases.

> And does
> it make any difference, if we target extragear, instead? Should we take
> care of porting to KF5, first, in any case?

That's up to you, i'll say the sooner the better since you'll have less code 
to port :D

Cheers,
  Albert

> 
> Regards
> Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20150508/fb86d658/attachment.sig>