On 02/10/2014 01:22 PM, Martin Kosek wrote:
FreeIPA core devel team had a discussion about how to organize our development
milestones better. Currently, all next release development tickets are put into
monthly milestones and then worked in based on priorities.
However, this does does not fly well with the non-critical tickets as when the
development gets behind schedule, there is a lot of moving tickets around,
moving them to $month+1 milestone, causing confusing churn in the ticket
As agreed on the meeting, we need to improve the situation, this is the
1) Monthly release milestones will only contain a limited set of scheduled core
critical feature that will be a priority for the developer to work on.
2) We will create a new "next feature backlog" which will contain the less
important features and bug fixes, i.e. "FreeIPA 3.4 Backlog". When developer
has done all his this-month tickets, he can start with the backlog ones,
according to priority.
3) Besides these 2 next-release milestone types, there will be a second train
for bug fixing current release (we currently have "2014 Month 2 - February
(3.3.x bug fixing)"). I am thinking this does not need be divided to months as
these tickets need to be done asap anyway. So I would name it simply "FreeIPA
3.3.5". Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing
that it is more difficult to see the exact version where the patch landed.
Please name it e.g. "FreeIPA 3.3.5 (bug fixing)" or "FreeIPA 3.3.5
(maintenance)" for clarity. Numbers have a tendency to get mixed up.
This means that each month, a developer should watch following 3 milestones (in
* current release bug fixing milestone: FreeIPA 3.3.5
* next-release monthly milestone: FreeIPA 3.4 - 2014/2
* next-release backlog milestone: FreeIPA 3.4 Backlog
If there are no strong objections, I will create new milestones, rename
existing ones and sanitize current distribution of 3.4 tickets. IMO this would
make the milestone clear, but I am open to other suggestions.
Freeipa-devel mailing list