[kde-community] Proposal One: KDE (Core) Apps and Suites

Fri May 2 18:53:47 BST 2014

On Thursday 01 May 2014 15:22:49 Albert Astals Cid wrote:
> El Dijous, 1 de maig de 2014, a les 15:02:36, Luigi Toscano va escriure:
> > Albert Astals Cid ha scritto:
> > > El Dimecres, 30 d'abril de 2014, a les 21:36:14, Jaroslaw Staniek va
> 
> escriure:
> > >> [..]
> > >> 
> > >> I'd like to say thank you to everyone that shares personal opinion.
> > >> Here's
> > >> mine.
> > >> 
> > >> (While reading this please note that geek power users isn't a primary
> > >> audience for apps I am contributing to)
> > >> 
> > >> - 3 -
> > >> 
> > >> At project management level please also note a word from a Calligra
> > >> contributor. The project is so huge that there's even lack of manpower
> > >> for maintaining change logs or feature guides. Even specification of
> > >> essential file formats take thousands of pages combined. 400+ dialogs.
> > >> 400 services/types/plugins. I don't think syncing with joint releases
> > >> wouldn't add to the manpower. I would avoid anything that narrows
> > >> contributor base and user base.
> > >> Secondly, our choice of release schedule for Calligra is already
> > >> result of a nontrivial compromise. It's complex even now while we do
> > >> not have released our Frameworks to the public, something that in my
> > >> opinion can be expected as our differentiator.
> > > 
> > > Do you believe that splitting Calligra into something like 10 different
> > > releases would actually help with the lack of manpower?
> > > 
> > > I have the feeling that it would probably help "the big guys", but I
> > > don't
> > > think it'd have a global positive "value" for all the projects that
> > > compose
> > > Calligra at the moment.
> > > 
> > > But that is my "I have no clue about Calligra" opinion so I'd value
> > > yours
> > > 
> > > :)
> > 
> > I think there is a bit of confusion: the proposal about "unified release"
> > is about the Application part of KDE SC + any other application which
> > would join. A big project like Calligra is independent enough and it can
> > have a separate schedule as it is now. Did I get it right?
> 
> I don't know, I don't see an unification proposal in this email thread at
> all, i see an "suitification" proposal that reads as splitting of
> schedules to me.

Ok, perhaps what I wrote wasn't clear.

You can't make decisions if you don't first talk about what it is you want. 
So, I'm going to assume here that we want something that:
* little work for everybody
* is flexible for app developers
* gets software asap to our users
* works for the distro's
* is simple to understand

Now you can pick any of those and get a it perfect for that one. Eg, a yearly 
release for ALL KDE software is awesome for promo and the release team. Not 
very flexible and doesn't get software quick to our users. A release whenever 
a developer wants would do the opposite. Etc.

So, I thought to get rid of the X month schedule that apps have to fit into + 
separate releases for apps that don't want it. Especially now we have 
Frameworks AND applications AND Plasma AND Calligra AND amarok, AND bugfix 
releases, the current process results in multiple releases per month and a 
lot of work and boilerplate to be copied over (esp for bugfixes).

I would think it makes more sense to get everything a bit more in line, 
including the apps and suites that now do their 'own' releases: this way, we 
can give them the benefit of the release team/tools doing some of the work 
for them.

What I proposed is:
* Let's do regular releases
* ANY app (incl Calligra, as a suite or separate) can join each individual 
release point - or not.
* Each app keeps their own release numbering, however they like it. The 
releasing is just for the engineering and promo.

So, in this, we'd do something like a 'release point' every month.
Jan release comes with Calligra 2.6, Amarok 2.7, Plasma 2016.1, Kate 5.8, Ark 
2.2, Dolphin 2.3, KDE PIM 2.5, Frameworks 5.13 and so on.
Feb release comes with Frameworks 5.13, Kate 5.9, Kget 3.3, ReKonq 5.6, and 
so on.

Frameworks and Kate are on a monthly release cycle (that's really the plan 
for Frameworks, for Kate I just made that up). The others have different 
cycles - eg Plasma will release again in April with 2016.4, Ark might not 
release for another 8 months, Amarok comes in October etcetera.

I would also suggest that the stability releases go into this as well, taking 
care of that too. Could of course be on a separate date: do app releases in 
the 1st week of the month, bugfix releases in the 3rd week.

How does this fit the requirements?
* as little work as possible
 * we know there's a release every month. That might seem more often than 
now, but honestly - we DO have releases *multiple times* per month already. 
We would certainly have to adjust (or create) processes and scripts, but I 
bet this can be automated to a great degree. By also taking care of Calligra 
and Amarok and monthly stability, we get far less work, at least for the side 
(promo) I can see.
* is flexible for app developers
 * you can decide on a release date with a granularity of 1 month.
* gets software asap to our users
 * monthly is pretty quick :D
* works for the distro's
 * no clue, tbh.
* is simple to understand
 * Seems simple to me and I don't believe I'm very smart, so...

Now Albert already said:
>  * Having synched release schedules for "KDE Applications" like we have
>  done for 15 years allows me to know easily if an application is on freeze 
>  or not, if suddenly as a developer I have to keep track of 160 different 
>  release schedules, count me out of doing fixes in those apps.

That seems quite a big problem with my 'monthly' proposal. Maybe we can do a 
'middle way' and have a 3 or 4 month cycle for the majority of apps and have 
the rest (Calligra, Telepathy, Amarok etc) and the bugfix releases join the 
monthly releases. A bit of both... Monthly releases but every 3 or 4 months a 
bigger one so Ark, Kget etc can get their bugfixes to users easily and 
predictably.

> Cheers,
>   Albert
> 
> > Ciao
> 
> _______________________________________________
> kde-community mailing list
> kde-community at kde.org
> https://mail.kde.org/mailman/listinfo/kde-community