On 02/10/2014 07:28 AM, Petr Viktorin wrote:
On 02/10/2014 01:22 PM, Martin Kosek wrote:
FreeIPA core devel team had a discussion about how to organize our
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
development gets behind schedule, there is a lot of moving tickets
moving them to $month+1 milestone, causing confusing churn in the
As agreed on the meeting, we need to improve the situation, this is
1) Monthly release milestones will only contain a limited set of
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
important features and bug fixes, i.e. FreeIPA 3.4 Backlog. When
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
for bug fixing current release (we currently have 2014 Month 2 -
(3.3.x bug fixing)). I am thinking this does not need be divided to
these tickets need to be done asap anyway. So I would name it simply
3.3.5. Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is
that it is more difficult to see the exact version where the patch
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
* 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
make the milestone clear, but I am open to other suggestions.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list