[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: No more release schedules.
From:       Tom Albers <toma () kde ! org>
Date:       2011-06-09 20:54:34
Message-ID: d2c484ee-e6d5-4c36-9d36-19ca84d1179c () contact ! kovoks ! nl
[Download RAW message or body]

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 now included kde-devel and kde-packager which was not intended. If the \
outcome is that it was a bad suggestion that's fine, it won't happen. But you \
approaching those lists is very premature and harms this discussion very much.

----- Original Message -----
> would appreciate it if you all there
> upstream
> would just stick to KDE, because that is what everyone uses. Nothing
> else.

Not on-topic for this list at all, nor relevant for this thread...

> Basically this is nothing but a dissolution of the KDE project as a
> whole.

Really, read my mails carefully. My plan is to facilitate a trend that is going on \
for a bit now, which i see accelerated by the platform 10 outcome. 

> Sure, we'll end up with a lot of projects using and enhancing kdelibs
> (or
> whatever becomes of that), but there will be no coherence anymore.

That's a very limited view. I think it's fine that modules have different scopes at \
different points in time, with different freeze and work flow requirements. Ignoring \
that would do KDE harm.  
> 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.

Yes, so facilitate this mechanism better. Now we let Allen do the pim releases \
basically on his own. He had to do all the hard work of tarballing, dealing with \
translations etc. Why don't we setup the r-t as a team which can facilitate the \
release whenever the module maintainer deams it needed. Of course based on a proper \
schedule.

> Suggestion 2 fails with the "independent of the schedules"
> part,
> because you can't release somthing that is not stabilized and tested.

Did I write anywhere that we would tarball some random branch at some random time? \
That's not the plan. Let the module maintainer set their own freezes, make their own \
schedule. 

Best,
-- 
Tom Albers
KDE
 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]