Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Tuesday 09 September 2008, Cornelius Schumacher wrote:
> On Tuesday 09 September 2008 19:47:30 Aaron J. Seigo wrote:
> > this feast/famine cycle is driven by being allowed to work on features in
> > certain times but not others. this doesn't actually stop feature
> > development, though, it just diverts it elsewhere.
>
> That's actually a good thing. 

it is good that feature dev doesn't stop; but not so great for stability and 
it doesn't provide a reliable pace that works for everyone. right now 
development is very "lumpy" with too many features being merged twice per 
cycle (start and pre-freeze) and too many branches happening once per cycle 
(during freezes).

> When approaching a release feature
> development has no place in the branch which is going to be released.

yes...

> Of course we should make it easy to integrate feature development which
> goes on in parallel to a release period, and of course we also need to make
> sure that there is still enough focus on the release and not all
> development diverts elsewhere.

yes...

> > while disallowing feature work may seem to be a good thing, the idea
> > being to focus people on bugs, it turns out that it actually makes the
> > code base wobble in stability a lot during feature feasts.
>
> Introducing new features always will affect stability, no matter how often
> and when it's done.

it's about how easy and quick it is address the defects introduced.

> Feature peaks like we see them now can have very negative effects on
> stability as they in some cases can change too much different things at
> once.

exactly... 

> But a continuous flow of incoming features can also have very
> negative effects, as it also means a continuous flow of incoming bugs,
> which might make it hard to stabilize code, even if the bugs are not really
> related, but just make it more difficult to work on the code.

fewer independent variables, though. trivial example: assuming continuous 
usage, bugs that are noticed today are most likely caused by features 
committed closer to today. i use that pattern to track down problems in trunk/ 
all the time =)

put another way, if i have N features to integrate and i integrate them one at 
a time it's easier to test each feature than if i integrate all N features at 
once. not only do i have only one thing to concentrate on at a time as a human 
being, the features don't have the risk of interfering with each other.

you can certainly screw up serial feature integration but you have to try a 
lot harder in my experience ;)

> > bug/stability doesn't
> > happen due to feature freeze, it happens most or less when i post a mail
> > to the list saying "ok! let's see if we can kill N bugs!" or something
> > similar to that. i do this in response to upcoming releases. if i don't
> > issue the call, the bug fixing pace seems to remain about constant
> > regardless of the period of the devel cycle.
>
> That's an important aspect. Imposing rules or disallowing certain actions
> might be necessary in some cases, but it doesn't get stabilizing and bug
> fixing done. For that we need to create an atmosphere which encourages
> that, e.g. by team efforts to address bugs.

yep. the bug days, btw, have been awesome for this. major +1s to that effort.

> > now, i'd prefer to see it go:
> >
> > * Spring branches are merged when features are "ready" into a Summer
> >
> > * Summer goes through rapid cycles of "1-2 weeks of devel and Spring
> >
> > * Autumn branch should be in a relatively good situation due to the
> > Summer
> >
> > * When KDE branches for release (call this the Winter branch), we will
> > put
>
> I really like the terminology. That's a very suggestive way to describe
> what branch is used for what purpose. I suppose that helps a lot with
> getting people to understand which branch is meant for what, which is a
> very important point in the development process. Communication is one of
> the most important aspects of all this.

yes, communication is absolutely critical.

> > with the proposed system, we'd have:
> >
> > * Plasma team on Summer with some Spring mixed in here and there, feeding
> > into Autumn. We'd catch as much or more of the issues ourselves.
>
> So this would be equivalent to the current work or private branches
> (Spring), and a new branch (Summer) which collects all the new code,
> probably per subteam.

right... 

> This is the element I would see as the most beneficial of the season
> branches approach. We currently don't have a very well defined and
> practical approach to work on bigger changes in a coordinated way without
> affecting other developers.

i know; and it drives me nuts some days =)

> But are we able to maintain four branches in parallel?

it's not about maintaining four branches, though. it's really one shared 
branch that is always Mostly Up To Date (Autumn), and then branches for each 
subproject hat would benefit from it (Spring and Summer branches). but you 
wouldn't run Plasma's Summer branch unless you were crazy about plasma 
development.

globally we only maintain two branches: Autumn (current devleopment) and 
Winter (current stable), just as we do now. the difference is that instead of 
freezing trunk, we branch it and trunk continues on.

for me personally, i'd end up managing Plasma's Summer and Autumn branches 
with other Plasma teammates; i'd end up pulling changes from various Spring 
branches to test and eventually to integrate. i wouldn't need to actually 
*run* Plasma's Autumn branch because it would be the Summer branch from the 
last merge point (so 0-2 weeks ago); at most i'd have to pull changes 
committed first to Autumn or Winter into Summer. for everything not-plasma, i'd 
be running the Autumn branch (well, except kdelibs if it had a Summer branch 
as i contribute to that =)

this still requires an SCM that makes this non-frustrating, and i absolutely 
wouldn't do it with svn.

i understand that this may all sound a bit confusing, but mostly because it's 
different. it took me a while to understand how it could work after reading 
what little bits were available on the 'net about this way of working, 
listening to others more familiar with distributed SCMs than i am talk about 
it and then pondering it now and again. now it seems relatively straight 
forward to me. 

going back to what you said about communication: unless we communicate 
*clearly* how things work, this will fail no matter how clever it is. 
personally, i'd set the "clearly" metric as:

* no more than 3 normal length paragraphs of text
* 3-6 explanatory images/graphs (the ones in the dot story were a good start)
* clear enough that one read through is enough

we may have a different set of information for new / casual devleopers ("just 
use Autumn") versus regularly commiting application developers versus project 
maintainers ... 

i think it can be done. i couldn't personally write those three paragraphs 
yet, though. maybe after another 10lbs of email and more reading about how 
other projects with centralized repositories that usie a distributed SCM 
handle it ..... 

but if we can't write those 3 short paragraphs + a handful of illustrations, 
we won't be able to make this fly, imho.

> With a better suited
> version control system this might be possible, but it probably still
> requires more effort than we have now,

depends on the subproject, for Plasma it would be the same or even less work. 
but that's because use review board, svn mv and svn merge a lot. and that 
might be why i like this idea so much: we are already somewhat close to this 
way of working, only with tools that aren't really built for it ;)

for those projects that it would be more effort to maintain spring/summer 
branches, they could probably just stick with "autumn, winter when branched 
for betas/rcs, back to autumn on release". this would make it the same as the 
current system for these projects.

> and it certainly will blur the focus of many developers.

i wonder if this could be made simpler with proper communication.

> That's why I really would like to maintain some release rhythm for the
> overall development. 

yes, that would need to be part of the new system as well .. it just wouldn't 
be enforced using technical limitations but social coordination (the FOSS 
version of project management? =)

> It would provide focus to our developers and make a
> good use of our rather limited resources. So when approaching a release the
> focus would move from Summer to Autumn and finally to Winter. We could

with a decent SCM, one shouldn't need to be too aware of the switch between 
Summer and Autumn. cherry picking commits with git is pretty easy, people can 
make pull requests and switching between branches is rather painless (even 
with local modifications in your branch! you can commit changes locally, stash 
them, etc..)

i think the shift between Autumn and Winter will be the more key point, and i 
wonder if we can't hijack application developers for this....

> still accommodate people working on new features in Spring branches, but
> the overall attention should be on the work which results in the concrete
> next release, which in the end is all that matters.

yes; and at least in Plasma i know that in accomodating Spring branches and 
allowing work to continue in Summer and even Autumn, we'll have more people 
paying attention to release code because they aren't concerned about feature 
development time.

> > * KDE core development community on Autumn, catching what we miss.
>
> This would be equivalent to the current SVN trunk.

yes.

> > * KDE application developers on Winter branches, helping additional
> > stability testing.
>
> This would be equivalent to the current stable branches which are branched
> off trunk when a release is done.

yes.

> > * KDE users using released version.
>
> This obviously wouldn't change.

right =)

> > * Plasma team won't have to worry about developer sprints matching up
> > with release schedules quite so much
>
> With Spring and Summer branches this seems to be no problem. I remember
> doing something like that with a "osnabrueck" branch in KDE PIM as well.

yes...

> > * people following trunk/ get bitten less often with "zero day" bugs due
> > to new feature commits
>
> This would be the effect of the new Summer branch. If there actually are
> enough developers caring about Summer, this would probably work.

well, the Autumn branch, but yes.

> > svn will likely _not_ work for the proposed situation very well, a
> > centralized git system should work rather well however.
>
> Yes. git makes handling multiple branches much more easy than svn. Of
> course it is also possible to do this in svn, but it requires more work.

in our (plasma team's) experience it's not possible enough to be practical. 
it's just too difficult to switch between branches, merge into trunk, pick 
specific revisions from branches, temporarily try branches with each other, ... 
it's livable if there is only one branch per set of files (multiple branches on 
the same set of files == pain, pain, pain), the branches are relatively short 
lived (over a month and it's painful) and the branch deltas remain reasonable.

at tokamak we routinely *lost* commits during branch merging. svn makes it far 
too easy to do that, and far too hard to track down the lost commits.

i experienced the same issues with kconfig branches pre-4.0.

git isn't magical, but it doesn't make me want to throw my computer against 
the wall quite so often. =P

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080909/16ad14cc/attachment.sig>