release schedule BoF

[Jaime Torres Amate]

Why not the other direction?
4 months to develop new features, 2 months freeze and fixing?

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

-- 
Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad