Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
> There are a few reaons to sync releases: > * Most of the devels of "KDE Applications" apps don't want to do the > releases > themselves after 15 years of a release team doing it for them > * 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. > * We have lots of applications with "no real maintainer" but I can still go > there, fix something that is i18n related and know it will be release next > month with the next "KDE Applications" release, with your plan of "everyone > releases its own stuff" my fix would never reach the user. +1 :) I can only say, with my Kate maintainer hat on: I have enough time, to fix the biggest faults, shout on people breaking the compile & tests, do some reviews and port Kate from KDE x to y. I don't have the time to think up release dates and package releases. I appreciate the work the KDE release team does in that area since ever! And I really think per application releases are just overkill for most applications. At the moment, I am happy to know: If somebody has KDE SC x.y installed, he has the state of Kate from that time. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Thursday 01 May 2014 14:50:44 Albert Astals Cid wrote:
> El Dimecres, 30 d'abril de 2014, a les 10:48:44, Jos Poortvliet va
escriure:
> > On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
> > > On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
> > >
> > > jospoortvlietstanburd...@gmail.com > wrote:
> > > > I think the idea of grouping releases ('Sigma'?) is a good one. How
> > > > about
> > > > we
> > > > start there. Let's give Applications more freedom, yet allow them to
> > > > be
> > > > part
> > > > of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they
> > > > should
> > > > be
> > > > part of the KDE Applications. Fold it all in there, with more
> > > > flexibility
> > > > thanks to more regular (but non-mandatory) releases. Yes, everybody
> > > > their
> > > > own
> > > > release numbers, no synchronization needed at all. Not every release
> > > > needs
> > > > every application, but perhaps for convenience of distro's we provide
> > > > everything in a tarball- just not with updated version numbers. They
> > > > can
> > > > ship
> > > > KDE Applications 2015.6 (?) and be sure to have all of them, but many
> > > > of
> > > > the
> > > > apps might not be different from those in KDE Applications 2015.2.
> > >
> > > I think the release numbers should be all the same and perhaps even the
> > > number of the "Sigma" release (also, we should come up with something
> > > else
> > > than "Sigma" before it catches on and stays...like "SC"...unless we
> > > want
> > > it
> > > to stay). Otherwise it will be a mess imho - "KDE Applications 2015.6
> > > contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1" --
> > > "KDE
> > > Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok
> > > 4.8.2,
> > > Kontact 5.4.1"are those own version numbers really that important?
> > > It
> > > could just as well be "Dolphin 2015.6" or "Amarok 2015.12" (or some
> > > other
> > > numbers), but unified. More coherent, more clear, more simple. The
> > > downside I see is that the apps' developers would need to commit to
> > > this
> > > new policy, which might hit some resistance.
> >
> > Look at what we try to do here: message that our applications are
> > separate
> > and independent. There is nothing about Ktouch that requires Amarok, and
> > Words is just fine without Kanagram. The fact that, on a release
> > engineering level, we release them in batches - that is irrelevant for
> > users. They just get the one app they want, be it for Windows, Mac,
> > Linux, Android...
> >
> > Delivering it as a 'suite' with the same version numbers gives the
> > impression they do belong together. But they don't - the only thing KDE
> > software has in common is the people who make it. Functionally, you can
> > use them anywhere, alone or in groups, separate or combined.
> >
> > Also - most apps wouldn't release with every sigma release, so more than
> > half our applications is out of sync most of the time. Having Kontact and
> > Gwenview 2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being
> > the latest version seems more confusing than Kontact 1.8, Gwenview 2.3
> > etc
> > etc on their own. That is what people are used too.
> >
> > I don't see a strong argument for syncing the release numbers, the
> > confusing part doesn't convince me. There's plenty of different version
> > numbers on your system atm ;-)
> >
> > But if anybody knows a good reason to sync, say so please.
>
> There are a few reaons to sync releases:
> * Most of the devels of "KDE Applications" apps don't want to do the
> releases themselves after 15 years of a release team doing it for them
> * 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.
> * We have lots of applications with "no real maintainer" but I can still
> go there, fix something that is i18n related and know it will be release
> next month with the next "KDE Applications" release, with your plan of
> "everyone releases its own stuff" my fix would never reach the user.
Agreed - but not what I was asking. Sorry, I was purely talking about syncing
the version numbers - not about doing releases together. That saves work and
is a good thing. The above would be an answer to Martin Klaptek when he said:
> To be honest I don't see the point of my application actually joining the
> joint release...
Cheers,
Jos
> Cheers,
> Albert
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
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 f
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Friday 02 of May 2014 19:53:47 Jos Poortvliet wrote: > * 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. Not at the same rate as it will go, I think: one thing is to release (these days) 4.11.something for workspace + 4.12.something (already stable) + 4.13.something, another thing is to have full mix-and-matched releases also of big stuff. I think it means a neverending run. Ciao -- Luigi ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
