release schedule BoF

[Albert Astals Cid]

El Dimecres, 17 de juliol de 2013, a les 12:03:53, Jaime Torres Amate va 
escriure:
> Why not the other direction?
> 4 months to develop new features, 2 months freeze and fixing?

Because this doesn't move in the direction most of the people agreed we want 
(shorter releases, more candence).

Cheers,
  Albert

> 
> Jonathan Riddell <jr at jriddell.org> escribió:
> >Albert Astals Cid:
> >    idea is to shorten release
> >    we have now lots of freezes and a branch
> >
> >alex wants something shorter, suggested 3 months between release with
> >only 1 month of freezes
> >put all freezes together on same date, release beta 1, in two weeks RC
> >1, in 2 weeks more release
> >
> >    Frank from Dolphin says cool
> >
> >Lauren from KMail  says no, too hard to use feature branches
> >synchronise kdepim-libs -runtime
> >
> >    marketing harder
> >    aurelien said +1
> >
> >scottK said prefer if we first made sure master could be always stable
> >before trying shorter release cycle
> >rekonq man said would like to improve feature plan cos it sucks (only
> >used to get an extention to freeze)
> >
> >    vishesh said it sucks and he'd just move to KF5 if it happened
> >
> >sune agreed with scott that flow should be implemented before release
> >changes
> >aaron wrote lots, no time to read, he kind of agreed with new things
> >like separating marking from release
> >
> >    sune said not enough quality so need .4 and .5
> >    alex said some could distros care about maintaining old branch
> >
> >ingwa said no proof shorten release cycle will achieve it. we could do
> >it so then we get proof
> >we don't have an agreement, some say no some say yes, how do we move
> >forward?
> >
> >alex fiestas:
> >    quite cumbersome to do freezes
> >    idea is master is always ready, where you merge branches
> >
> >Kevin:
> >like the overall direction for shorter releases, worried about how we
> >get there
> >thinks we should try shorter by two weeks, then fix issues then make
> >gradually shorter
> >
> > would drop three month proposal and have a strategy to make it shorter
> >
> >graesslin:
> >    we can get rid of a few freezes immediately
> >    soft feature freeze is stupid
> >    soft translation freeze makes no sense
> >
> >ingo:
> >  if we shorten gradually every time all the critics will cry each time
> >  
> >    in our company we shortened from 4 weeks to 2 weeks, worked ok
> >
> >cornelius:
> >    we don't have the structures in place for short releases
> >
> >we force them to focus on stabalisation by freezes, if we give that up
> >then people will start to develop new features, if that works we are
> >more flexible, it is really a shift
> >
> >graesslin:
> >    add tag for notification of new dependencies
> >
> >tsdgeos:
> >    can someone please kick kdelibs people to fix the tests
> >
> >kevin:    subscribe the list to test failures
> >
> >ltoscano:
> >    translators ok with 1 month freeze
> >
> >suggestion to collapse all freezes
> >graesslin:
> >suggest get only 1 freeze, shorten by 1 month, fix tooling so every new
> >dep goes in log etc
> >
> >dario:
> >    only way to make this sensible is to enforce a commit policy
> >
> >albert:
> >    we want two things 1) collapsing freezes 2) fixing tooling
> >
> >will make two proposals, 1 a bit shorter, 2 same with less freezes 6 to
> >5 months
> >
> >dario:
> >    5 months is random, 4 months fit into a year
> >
> >jonathan:
> >    would prefer 6 monthly release because that fits in to ubuntu