On Thursday, June 9, 2011 18:07:33 Tom Albers wrote:
> - Original Message -
>
> > Weren't you the one proposing that subprojects should adopt their own
> > git
> > workflows? I'm quite puzzled about how problematic this would be.
>
> Since KDE is the community, how can we do a KDE 4.8?
a
On Thursday 09 June 2011 19:28:13 Tom Albers wrote:
> Hi,
>
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result
> in different release schedules, I propose we stop producing the central
> release sc
On Friday, June 10, 2011 17:24:57 Jos Poortvliet wrote:
> > In the end, you will be perceived for what you release - and here we get
> > back to this list. KDE lives from being a consistent whole. Eric
> > Hameleers already made some very valid points there. Breaking KDE up
> > does not help, and t
On Thursday, June 09, 2011 06:08:56 PM Tom Albers wrote:
> > Having KDE's own packages also released in an uncoordinated
> > fashion
>
> Wow. Who suggested that? That would make a mess indeed. I certainly did not
> ever suggest that. If you think so, pleas reread all my mails. I've
> suggested th
On Friday 10 June 2011 01:00:45 Andreas K. Huettel wrote:
> > I just read a very good novel where all such talk about "Software
>
> Collection"
>
> > or "Platform" was aptly called "commercial bulshytt". I think many of us,
> > including your "only-users", would appreciate it if you all there
> >
Hello,
On penktadienis 10 Birželis 2011 11:49:47 Eric Hameleers wrote:
> Again, monolithic tarballs or not, this is not the topic. Coordinating
> the release process for all the individual submodules is what is going
> to make or break KDE's acceptance. Do I have to remind you of the
> consequenc
>
> So forget about monolithic tarballs please. It is clouding the issue.
>
Exactly. Having a larger number of small tarballs can be just fine if done
properly. But, they should still have the same release schedule, version
number, and should be tested to work together. I.e. released as a wor
On Friday 10 June 2011 01:22:00 Kevin Kofler wrote:
> On Friday 10 June 2011, Scott Kitterman wrote:
> > Kevin Kofler wrote:
> > >OK, since a lot of context apparently got lost during the message
> > >passing, let
> > >me just state my (personal) position clearly:
> > >
> > >What I think is accept
Kevin Kofler wrote:
>OK, since a lot of context apparently got lost during the message
>passing, let
>me just state my (personal) position clearly:
>
>What I think is acceptable:
>* Module X wants feature Y, which is non-invasive and well-tested and
>does not
>change the user experience nor t
On Fri, 10 Jun 2011, Modestas Vainius wrote:
> On penktadienis 10 Bir?elis 2011 00:09:16 Eric Hameleers wrote:
> What do small tarballs have to do with this disintegration? I do understand
> that you dislike small well-split tarballs but, seriously, don't blame
> everything on them. It's only a di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09-06-2011 21:09, Eric Hameleers wrote:
> On Thu, 9 Jun 2011, Andreas K. Huettel wrote:
>
>> Dear KDE upstream,
Are you serious that you want to decouple the release of our
frameworks from
each other? THat would create a huge mess,
Hello,
On penktadienis 10 Birželis 2011 00:09:16 Eric Hameleers wrote:
> > That both makes no sense. Suggestion 1 fails completely with the "if they
> > like" part, since we all know already how much pain the "out of sync
> > kdepim" caused. Suggestion 2 fails with the "independent of the
> > sche
On Friday 10 June 2011, Scott Kitterman wrote:
> Kevin Kofler wrote:
> >OK, since a lot of context apparently got lost during the message
> >passing, let
> >me just state my (personal) position clearly:
> >
> >What I think is acceptable:
> >* Module X wants feature Y, which is non-invasive and wel
> I just read a very good novel where all such talk about "Software
Collection"
> or "Platform" was aptly called "commercial bulshytt". I think many of us,
> including your "only-users", would appreciate it if you all there upstream
> would just stick to KDE, because that is what everyone uses.
OK, since a lot of context apparently got lost during the message passing, let
me just state my (personal) position clearly:
What I think is acceptable:
* Module X wants feature Y, which is non-invasive and well-tested and does not
change the user experience nor the user interface in a significa
- Original Message -
> My main concern with disparate releases would be that it would be
> impossible
> to test all the possible combinations properly. Every distribution
> would end
> up with its own combination of versions, with the potential for
> incompatibilities nobody else can reprod
On Thursday 09 June 2011, Eric Hameleers wrote:
> Andreas, how I agree!
>
> This now, is _exactly_ what I was afraid for when I voiced my concern
> about the break-up of this relatively small collection of coherent
> source tarballs we are used to work with, into a fragmented and
> potentially dis
On Thursday 09 June 2011 Tom Albers wrote:
>
> I doubt the release schedule can keep that together. If the platform
> releases version 5, distro's need to package it and then ship 4 too and
> some kde modules will be compatible with platform 5 and some won't ever.
> So, however we turn it, I see w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 9 Jun 2011, Andreas K. Huettel wrote:
> Dear KDE upstream,
>
>> Since KDE is the community, how can we do a KDE 4.8? And then Platform will
>> call itself 5 if I understood correctly. So how do we call a new release
>> schedule then?
>
> I jus
Hi,
The release-team mailinglist is for release coordination, reaching consensus
and then announce the outcome on the appropiate lists. I think I started a
valid discussion, which can be discussed maturely inside the release-team, it
was not meant to be passed to a wider audience.
You have no
Dear KDE upstream,
> Since KDE is the community, how can we do a KDE 4.8? And then Platform will
> call itself 5 if I understood correctly. So how do we call a new release
> schedule then?
I just read a very good novel where all such talk about "Software Collection"
or "Platform" was aptly call
- Original Message -
> So what do you suggest? Having a central release at a certain date
> but let the modules decide when to the freezes?
Yes.
> Do beta version
> count as releases and are done centrally by the release team
Yes.
> or are
> they in the responsibility of the module mai
- Original Message -
> Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or
> whatever)
> and a corresponding release schedule called exactly that.
I think it is even more confusing to release kde sc 4.8 with for example,
platform 5, pim 4.7 and plasma 2. What exactly does 4
[Tom Albers - Donnerstag, 9. Juni 2011 19:28:13]
Hi
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result in
> different release schedules, I propose we stop producing the central release
> sched
(From a packager's and very, very long-term KDE user's point of view:)
> Since KDE is the community, how can we do a KDE 4.8?
[...]
> I think it's good for KDE to let each module set their freezes on their own
So you want the community to freeze? ;-)
(Really, guys, face it: Most of us still call
On Thursday 09 June 2011, Tom Albers wrote:
> kdebindings have troubles following it now and then
biggest problem for kdebindings is to adjust to API changes, but that was
solved with the API freeze. And anyway, kdebindings would have to follow
closely kdelibs. (I would be surprised if you can co
On Thu, Jun 9, 2011 at 13:12, Albert Astals Cid wrote:
> A Thursday, June 09, 2011, Ian Monroe va escriure:
>> On Thu, Jun 9, 2011 at 12:28, Tom Albers wrote:
>> > Hi,
>> >
>> > Since it seems some modules are going to have their own numbers and some
>> > modules will have a different (git) workf
A Thursday, June 09, 2011, Ian Monroe va escriure:
> On Thu, Jun 9, 2011 at 12:28, Tom Albers wrote:
> > Hi,
> >
> > Since it seems some modules are going to have their own numbers and some
> > modules will have a different (git) workflow, which will inevitably
> > result in different release sch
- Original Message -
> Weren't you the one proposing that subprojects should adopt their own
> git
> workflows? I'm quite puzzled about how problematic this would be.
Since KDE is the community, how can we do a KDE 4.8? And then Platform will
call itself 5 if I understood correctly. So ho
On Thursday, June 09, 2011 18:46:29 Albert Astals Cid wrote:
> > Even if this plan is vetoed away, I personally will not make a new
> > schedule, as I have no idea how to do that in the new setup and I've
> > little interest in studying the new setup.
>
> What do you mean by "in the new setup"? Do
On Thu, Jun 9, 2011 at 12:28, Tom Albers wrote:
> Hi,
>
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result in
> different release schedules, I propose we stop producing the central release
> sch
Hi Tom,
On Thursday, June 09, 2011 17:28:13 Tom Albers wrote:
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result
> in different release schedules, I propose we stop producing the central
> release
A Thursday, June 09, 2011, Tom Albers va escriure:
> Hi,
>
> Since it seems some modules are going to have their own numbers and some
> modules will have a different (git) workflow, which will inevitably result
> in different release schedules, I propose we stop producing the central
> release sch
Hi,
Since it seems some modules are going to have their own numbers and some
modules will have a different (git) workflow, which will inevitably result in
different release schedules, I propose we stop producing the central release
schedule as we have now.
So http://techbase.kde.org/Schedules/
34 matches
Mail list logo
