[Freeipa-devel] Organizing upstream development in Trac

[Martin Kosek]

On 02/10/2014 01:28 PM, Petr Viktorin wrote:
> On 02/10/2014 01:22 PM, Martin Kosek wrote:
>> Hello,
>>
>> 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
>> history.
>>
>> As agreed on the meeting, we need to improve the situation, this is the
>> proposal:
>>
>> 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.

Makes sense.

>> This means that each month, a developer should watch following 3 milestones (in
>> this order):
>> * 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.

By the way, few examples why I consider also changing names of the already
closed milestones.

"0.7 iteration - December FC" actually means "FreeIPA 2.0.0 - 2012/1"
"2013 Month 01 - January" actually means "FreeIPA 3.2.0 - 2013/1"

In these 2 examples, the FreeIPA version is unclear. I would also like to use
just one format of version milestones instead of several others we used in the
past:

2.1 - Sprint 1. May
3.0 Y11 06 Iteration June
3.0 Trust Effort Iteration 02 August Y11
2014 Month 1 - January (3.4)
...

When fixed, ordering of milestones in Trac should be much clearer and one
should be also able to quickly see where the fix landed (and not have to
investigate git).

Current (updated) proposed examples are:

FreeIPA 3.4 - 2014/2
FreeIPA 3.4 - Backlog
FreeIPA 3.3.5 (maintenance)

Martin