release schedule BoF

[Jonathan Riddell]

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