[Freeipa-devel] Organizing upstream development in Trac

[Petr Viktorin]

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.

> 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.

-- 
Petr³