On Sunday 17 June 2012, Cornelius Schumacher wrote:
> On Sunday 17 June 2012 Inge Wallin wrote:
> > The reasoning behind the move towards shorter release cycles is
> > exactly the opposite of how large organizations reason when they
> > select software. Remember the outcry when Firefox went to its
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:
> Hi all,
>
> During our sprint in Pineda de Mar, we sat down and thought about how our
> release cycles relate to the structures in our software, we came up with the
> following proposal we'd like you to consider and provide feedback ab
On Sunday, June 17, 2012 03:44:04 Inge Wallin wrote:
> As far as I could understand from the above the main ideas are:
> - Splitting the SC into 3 parts
> - Shortening the release cycles significantly.
Only the first one is subject of this proposal.
The length of the release cycles is an indepe
On Monday 18 June 2012 22:26:49 Alexander Neundorf wrote:
> Which "David" is the David in sebas email ?
David Edmundson.
> (also, which Alex ?)
Alex Fiestas.
Cheers!
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a
On June 18, 2012 07:21:29 PM Andreas K. Huettel wrote:
> > > know the current state of the release and commit new features or new
> > > strings when we are frozen, and that's with just one release schedule, i
> > > can imagine the mess with N different release schedules
> >
> > "Always summer in t
On Monday, June 18, 2012 19:21:29 Andreas K. Huettel wrote:
> > > know the current state of the release and commit new features or new
> > > strings when we are frozen, and that's with just one release schedule, i
> > > can imagine the mess with N different release schedules
> >
> > "Always summer
On Monday 18 June 2012, David Faure wrote:
> On Monday 18 June 2012 10:48:43 David Jarvie wrote:
> > I'd rather see a rule that we keep to a uniform release schedule,
> > but perhaps allow individual ad-hoc exceptions if there is a really good
> > reason.
>
> +1.
Which "David" is the David in seb
On Sunday 17 June 2012, Shaun Reich wrote:
> On Sat, Jun 16, 2012 at 9:44 PM, Inge Wallin wrote:
> > As far as I could understand from the above the main ideas are:
> > - Splitting the SC into 3 parts
> > - Shortening the release cycles significantly.
> >
> > It seems to me that a current trend
> > know the current state of the release and commit new features or new
> > strings when we are frozen, and that's with just one release schedule, i
> > can imagine the mess with N different release schedules
>
> "Always summer in trunk". As long as releases are not created from the
> master bran
(Missed k-c-d)
On Monday 18 June 2012 19.08.33 Albert Astals Cid wrote:
> El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gräßlin va escriure:
> > On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
> > > My concerns:
> > > * Need more people to do the tarball packaging/releasing (sinc
On Monday 18 June 2012 19:08:33 Albert Astals Cid wrote:
> El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gräßlin va escriure:
> > On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
> > > My concerns:
> > > * Need more people to do the tarball packaging/releasing (since if you
> > >
El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gräßlin va escriure:
> On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
> > My concerns:
> > * Need more people to do the tarball packaging/releasing (since if you
> >
> > propose to release that often you can't expect the same person
On Monday 18 June 2012 10:48:43 David Jarvie wrote:
> I'd rather see a rule that we keep to a uniform release schedule,
> but perhaps allow individual ad-hoc exceptions if there is a really good
> reason.
+1.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on K
On Monday, June 18, 2012 11:52:46 Myriam Schweingruber wrote:
> On Sun, Jun 17, 2012 at 3:16 PM, Sebastian Kügler wrote:
> > On Saturday, June 16, 2012 08:18:05 Maksim Orlovich wrote:
> >...
> >
> >> What continuous integration and automated testing? How many apps have
> >> any?
> >
> > That's th
On Monday, June 18, 2012 00:26:13 Albert Astals Cid wrote:
> * Need more people to do the tarball packaging/releasing (since if you
> propose to release that often you can't expect the same person to be doing
> packages almost weekly or byweekly given the release dates won't probably
> align)
>
Hi everyone,
On Sun, Jun 17, 2012 at 3:16 PM, Sebastian Kügler wrote:
> On Saturday, June 16, 2012 08:18:05 Maksim Orlovich wrote:
>...
>> What continuous integration and automated testing? How many apps have any?
>
> That's the point, we need to improve here. Some of this can be done centrally,
On Mon, June 18, 2012 5:36 am, Martin Gräßlin wrote:
> On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
>> My concerns:
>>
>> * Uncertainity on the "current release state". We have people that don't
>> know the current state of the release and commit new features or new
>> strings when we
> * The difficulty of coding for N releases. Since the releases an not aligned
> anymore, you have to maintain code and #ifdefs for new features that depend on
> new versions of parts X of the stack that may or might not be used by people
> compiling the application. We've have some bad experience
On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote:
> My concerns:
>
> * Need more people to do the tarball packaging/releasing (since if you
> propose to release that often you can't expect the same person to be doing
> packages almost weekly or byweekly given the release dates won't probab
El Divendres, 15 de juny de 2012, a les 13:05:44, Sebastian Kügler va
escriure:
> Hi all,
Hi
> During our sprint in Pineda de Mar, we sat down and thought about how our
> release cycles relate to the structures in our software, we came up with the
> following proposal we'd like you to consider a
On Sunday 17 June 2012 03:44:04 Inge Wallin wrote:
> As far as I could understand from the above the main ideas are:
> - Splitting the SC into 3 parts
Yep.
> - Shortening the release cycles significantly.
Nope. The presented numbers were totally made up and random just for
illustration, could
On Saturday, June 16, 2012 08:18:05 Maksim Orlovich wrote:
> How do you reconcile this proposal with our current troubles in 4.8.4,
> where you need certain particular combinations of two sets of
> libraries for things not to blow up? Your proposal increases the
> number of combinations in wide use
On Sat, Jun 16, 2012 at 9:44 PM, Inge Wallin wrote:
> As far as I could understand from the above the main ideas are:
> - Splitting the SC into 3 parts
> - Shortening the release cycles significantly.
>
> It seems to me that a current trend in larger free software projects is to go
which projec
On 06/16/2012 09:44 PM, Inge Wallin wrote:
My problem is with the second. While some people always want to have the
latest and greatest, I wonder what it will do to stability. You didn't write
anything above about how many bugfix updates any given version would receive.
The shorter the release c
On Friday 15 June 2012 Sebastian Kügler wrote:
>
> Opinions?
The predictability and synchronicity of our current six month release cycle
has a lot of benefits. It allows all contributors as well as consumers of our
releases to plan ahead and minimizes release overhead.
On the other hand it wou
On Sunday 17 June 2012 Inge Wallin wrote:
>
> The reasoning behind the move towards shorter release cycles is exactly the
> opposite of how large organizations reason when they select software.
> Remember the outcry when Firefox went to its current way of releasing.
> When Brazil rolls out KDE to
On Friday, June 15, 2012 13:05:44 Sebastian Kügler wrote:
> Hi all,
>
> During our sprint in Pineda de Mar, we sat down and thought about how our
> release cycles relate to the structures in our software, we came up with
> the following proposal we'd like you to consider and provide feedback
> abo
On Sat, Jun 16, 2012 at 7:21 AM, Marco Martin wrote:
> a part of the plan (kindof a consequency in the long term of the thing
> described here) is that it would mean aiming to a state where there are nover
> freezes (or well, master is always frozen, depends how you look at ;)
>
> master should al
>
> Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and
> Applications each with their own release cycles. Each of these releases
> would
> be a set of tarballs of the latest stable versions of the application (or
> codebase in more general).
> As an example, Frameworks could
On Sat, Jun 16, 2012 at 1:21 PM, Marco Martin wrote:
> On Saturday 16 June 2012, Shaun Reich wrote:
>>
>> and the freezes would have to be *very* well communicated, because
>> even now we run into issues with people not realizing that we're in
>> string freeze or feature freeze.
>
> a part of the
Ahoy,
On Fri, Jun 15, 2012 at 1:05 PM, Sebastian Kügler wrote:
> Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and
> Applications each with their own release cycles. Each of these releases would
> be a set of tarballs of the latest stable versions of the application (or
>
On Saturday 16 June 2012, Shaun Reich wrote:
>
> and the freezes would have to be *very* well communicated, because
> even now we run into issues with people not realizing that we're in
> string freeze or feature freeze.
a part of the plan (kindof a consequency in the long term of the thing
desc
This proposal looks like the X.org release cycle.
Each individual component can release as many versions as wanted, and
from time to time there will be a global release.
2012/6/16 Shaun Reich :
> i like where this is going..i've always wanted a bit more flexibility
> in releases...
>
i like where this is going..i've always wanted a bit more flexibility
in releases...
one thing to keep in mind (i realize it's a bit premature to say this,
but..) we'd definitely have to make sure we coordinate the various
freezes well, since there'd be a dedicated and specialized
freeze-timeline
Am 16.06.2012, 06:25 Uhr, schrieb Scott Kitterman :
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:
As an example, Frameworks could release updates every 2 months, while
our
application collection is updated monthly. New iterations of the
workspaces
come every four months. (Th
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:
> Hi all,
>
> During our sprint in Pineda de Mar, we sat down and thought about how our
> release cycles relate to the structures in our software, we came up with the
> following proposal we'd like you to consider and provide feedback ab
36 matches
Mail list logo
