Hi Vincent,
On Mon, Jan 16, 2012 at 10:09 AM, Vincent Massol <[email protected]> wrote:
> Hi devs,
>
> We've been quite bad at following the release strategy we've defined so far:
> timeboxing.
>
> We've been constantly slipping our release dates during all the past releases
> (and not by 1 or 2 days, but by 2 weeks or more).
>
> Personally I find this not professional of us and for me it means that the
> date we give are just a joke now. I don't even see why we're giving dates
> since they can only be misleading to anyone who would act on them… At the
> current slippage rate, we should only give a month estimation to have a
> chance of being correct ;)
>
> There's only one reason we're really slipping IMO: we've forgotten that we're
> doing time boxing.
I don't believe this is the only reason, not even the main one. I
don't think 3.4M1 was delayed because we wanted to do more. What I
know is that the build was unstable during the winter holidays when
most of the committers were offline so there wasn't anyone to
investigate and fix the failing tests on CI. You can argue that the
build was unstable because we don't do timeboxing, but even with
timeboxing you can have:
* integration tests failing because a commit in module A (which has
its own unit tests passing) has side effects on module B. If both
modules are under development, with lost of commits, then it's hard to
track which commit broke the build. Jenkins is not very helpful
regarding this.
* flickering functional tests, both due to bad test coding but also
due to the instability of Selenium (I don't feel it 100% reliable).
>
> Let me remind us what time boxing is and how it can be made to work:
> * It means releasing on a fixed date and releasing whatever is ready at that
> date.
> * The idea is also to do quick releases so that if a given feature is not in
> a release it'll be in the next one coming soon (we used to do 2 to 3 weeks
> releases at some points and recently we've been doing instead 3-5 weeks
> instead)
> * The reason for releasing often is because this pushes the bug fixes and new
> stuff to users ASAP and thus let them experiment with them and give us
> feedback (bugs, usability, etc)
> * The way to make timeboxing work is by having automated functional tests so
> that we can release safely knowing that our test suite will catch the
> problems if any. This means that whenever a commit is done, in the same
> commit there are tests proving that what is committed is working (and not
> several weeks later which would be anti-timeboxing).
> * it doesn't mean we cannot have a roadmap. What it means is that we should
> the maximum of what is in the roadmap in a given time slot. What's not done
> doesn't get released. This means that large features should be divided into
> small one that will fit. Developers need to think about what they're doing by
> constantly checking the release date and verifying what they can achieve for
> that date and make absolutely sure that what they have committed is working
> for that date (even if what they have committed is not finished).
> * Timeboxing is not about how many men/days you have available or whether
> people are on holidays or not. If you have less men/days you do less work. It
> doesn't change the release date.
You still need someone do to the release and we aren't that many
committers so if we all take the winter holidays (as it is normal)
then we have to adjust the release date.
>
> Basically you can only do timeboxing if you have good and automated quality
> control.
>
> The opposite of timeboxing is feature releases which lead to the following:
> * People committing not working stuff or without tests because they know
> they'll have time to fix it later on before the release (easy to think this
> since there's no release date, it's only when the features are done that
> it'll get released)
> * Release date become not important since they keep being pushed since what's
> important is to release planned features
> * Build failing all the time and developers not caring about it ("it can
> always be fixed later when we get close to the release date" - that's easy to
> say since there' no fixed release date)
> * Users seeing less frequent releases and giving less feedback to developers
> (thus helping less)
> * In general, quality dropping over time
>
> So we have several choices:
>
> 1) Forget timeboxing and do feature-based releases, i.e. we list features and
> we only release when they're done
> 2) Start doing real timeboxing again
>
> I've seen so many projects do 1) in the past with such bad results that for
> me there's no doubt that the only good strategy is 2). Especially for an open
> source project which has a strong community and we should be releasing stuff
> regularly and quickly to this community to get good feedback. Doing
> timeboxing is also a great way to improve the quality of our code.
>
> Timeboxing can only work fine if everyone agrees with it (we can revert stuff
> from a developer if it breaks things but it's a pain) and believe in the
> release date, so we'd need everyone's agreements.
>
> So WDYT, are we ok to resume doing timeboxing and go back on track?
I'm definitely for timeboxing.
Thanks,
Marius
>
> On my side I'm ok to do it and help enforce it. If we agree we should start
> now by releasing RC1 ASAP and give a new date for 3.4 final and release on
> that date.
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
