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

List:       kde-release-team
Subject:    Re: Proposed adjustments to our release cycles
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2012-06-18 17:08:33
Message-ID: 14413029.QIyjqfRY1f () xps
[Download RAW message or body]

El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gr=E4=DFlin va escri=
ure:
> 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 do=
ing
> > packages almost weekly or byweekly given the release dates won't probab=
ly
> > align)
> =

> I would say we need proper Jenkins support for that. It must be as simple=
 as
> clicking one button to have the tarball fall out of the CI system and
> already know whether it compiles or not.

This is cool, i totally support that, just don't see it there, do we have a=
ny =

volunteer for the work?

> =

> >  * 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 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 branch it should be fine. On the other hand nobody should commit
> without a review anyway, so just commit and push without proper
> communication with the core developer group is so wrong in the first place

That's news to me, I've been commiting for 10 years to KDE cvs/svn/git and =
the =

code i have pre-review is clearly under 5%, if mandatory pre-reviews are pa=
rt =

of the plan, please clearly state so.

> =

> >  * 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 n=
ot
> > be used by people compiling the application. We've have some bad
> > experiences with "expected versions on the stack" so i hope you're
> > understanding this is not a theoretical scenario.
> =

> Also here: proper Jenkins support. CI needs to scream at you if you commit
> something which does not compile.

Compiling is not enough, let me remind you of the 4.8.4 kdelibs crashes =

misteriously if not un against the "proper" soprano problem.

Cheers,
  Albert

> =

> Cheers
> Martin
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]