Alarms: 10 day Sprint

[Thomas Pfeiffer]

On 20.11.2012 12:03, Aaron J. Seigo wrote:
> On Tuesday, November 20, 2012 11:55:10 Thomas Pfeiffer wrote:
>> https://bugs.kde.org/show_bug.cgi?id=309989
>> https://bugs.kde.org/show_bug.cgi?id=309991
>
> afaik, neither of those bugs are a result of the activity related to /
> resulting from the sprint. we won't get every bug nailed within a given
> sprint.

Ah, so they were caused by post-PA3 but pre-sprint activity? In that 
case they are not relevant to the sprint, yes.
Seems like the changes which were done (or merged in) after the release 
but before the changes in process we introduced (always stable Master, 
focus sprints) caused some confusion (and bugs), but I guess that won't 
happen anymore in the next release cycle when the new processes are in 
place right away.

> the point of time boxing them is to allow us to focus on a number of
> components with time limits rather than use a "release when it is ready" focus
> as the driver (which results in some components being perpetually worked on,
> not always to their benefit, and others perpetually ignored).

I'd still say "release it when it's ready", but only related to the 
changes / new features introduced in a sprint. If we get the new 
processes right, the whole product should be potentially ready to be 
released before each sprint anyways, so as long as bugs introduced 
during a sprint a fixed before the end of it, we should be fine.

That brings me to another topic which I'll start a new thread for: 
Definition of Done / Quality.

> we will clean up these and other bugs in a separate (and possibly parallel)
> development process.

Yes, that makes sense, of course. For me as a non-developer they just 
looked like they were introduced with the sprint, because they were not 
there in PA3 and they were related to Files.
Sorry for the misunderstanding.