Proposed adjustments to our release cycles

[Martin Gräßlin]

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
> > > 
> > > 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)
> > 
> > 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
> any volunteer for the work?
if nobody takes care about it, I'm happy to help, though I don't see any time 
for it till August
> 
> > >  * 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 part of the plan, please clearly state so.
Let me add that I meant "known code base". I am quite sure that you won't need 
a review request for Okular (though personally I would advise you nevertheless 
;-), but if you want to commit to e.g. kdepim it might be an idea to check 
with the core development team first.
> 
> > >  * 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
> > > 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.
True, which shows again how important it is to have unit tests as already 
pointed out in this thread. (Let's just assume that those problems would have 
been spotted with a unit test).

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120618/04e3a590/attachment.sig>