[katello-devel] Proposal: Feature Tracking and Release Planning

[Tom McKay]

----- Original Message -----
> From: "Bryan Kearney" <bkearney at redhat.com>
> To: katello-devel at redhat.com
> Sent: Wednesday, November 14, 2012 9:09:28 AM
> Subject: Re: [katello-devel] Proposal: Feature Tracking and Release Planning
> 
> On 11/14/2012 09:05 AM, Tom McKay wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Petr Chalupa" <pchalupa at redhat.com>
> >> To: katello-devel at redhat.com
> >> Sent: Tuesday, November 13, 2012 10:39:18 AM
> >> Subject: Re: [katello-devel] Proposal: Feature Tracking and
> >> Release Planning
> >>
> >> I would like to use Github for features (and bugs) but so far from
> >> what
> >> I read We cannot do that because of the missing advanced search
> >> capabilities on Github.
> >>
> >> What about to create a service which would keep github and
> >> bugzilla
> >> synchronized (may be even rally - only features)?
> >>
> >> There are gems which should make it simpler.
> >> Taskmaster
> >>     https://github.com/hybridgroup/taskmapper
> >>     http://ticketrb.com/
> >> Rally
> >>     https://github.com/RallyTools/RallyRestToolkitForRuby
> >> Github hooks
> >>     https://github.com/github/github-services
> >>
> >> I would be happy to look into what would be possible.
> >>
> >> Petr
> >>
> >> On 10.11.12 0:55, Eric Helms wrote:
> >>> Observations:
> >>>    - Users coming into IRC channel and inquiring:
> >>>      * When features are planned to be released
> >>>      * How features are being developed
> >>>      * How to request features
> >>>    - No cohesive discussions, or feature plans to point users or
> >>>    developers to
> >>>
> >>> Motivation:
> >>>
> >>> - Users and developers have little insight into what the project
> >>> is
> >>> working on or targeting for next release (Roadmap is too broad -
> >>> https://fedorahosted.org/katello/roadmap)
> >>> - Users and developers have little insight into the design and
> >>> discussion of features
> >>> - There is no clear historical record of feature design
> >>> - Currently not easy for developers to participate in feature
> >>> design discussions
> >>>
> >>> Proposal:
> >>>
> >>> 1) Use Github issues to track design and implementation of
> >>> features
> >>> 2) Use issue labels to categorize features, e.g.
> >>>        - R&D
> >>>        - Feature
> >>>        - Polish
> >>>        - Proposal
> >>> 3) Use milestones to align a particular set of features for next
> >>> release
> >>> 4) Keep milestones small and focused (release early, release
> >>> often)
> >>> 5) Release when all issues aligned to a milestone are completed
> >>> 6) Pull requests relative to a feature can be aligned to a
> >>> milestone
> >>> 7) Backlog milestone to track things that need to get done and
> >>> feature requests
> >>>
> >>> Questions:
> >>>
> >>> Q: What about timed releases?
> >>> A: If there are no new features, or the code base is unstable,
> >>> enforcing a timed release makes little sense
> >>>
> >>> Q: What if a long time has lapsed between releases?
> >>> A: Take the current milestone, split off the un-completed
> >>> features
> >>> and cut a release based off the completed features to that point
> >>>
> >>>
> >>> Benefits:
> >>>
> >>> - Users can be pointed to the backlog and milestones to see what
> >>> we
> >>> have planned and priority
> >>> - Users can be pointed to discussions as features are being
> >>> designed and implemented
> >>> - There will be a record of design and feature discussion and
> >>> implementation
> >>> - Feature discussions can be used as input to update
> >>> documentation
> >>> (related to Petr's proposal around Yard documentation)
> >>> - A clearer way for users to request and track the development of
> >>> their features
> >>> - Community will have a clear view of where the project is headed
> >>> and when it plans to get there
> >>> - Github issues live with the project (one-stop shopping)
> >>>
> >>>
> >>> Please discuss, and ask questions so that I can feedback loop
> >>> into
> >>> the proposal and put to a vote.
> >>>
> >>>
> >>>    -Eric
> >>>
> >>> _______________________________________________
> >>> katello-devel mailing list
> >>> katello-devel at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/katello-devel
> >>>
> >>
> >> _______________________________________________
> >> katello-devel mailing list
> >> katello-devel at redhat.com
> >> https://www.redhat.com/mailman/listinfo/katello-devel
> >>
> >
> > Petr,
> > Eric, Jordan, and I have been talking about making an app to manage
> > issues/bugs across the various tools. Eric thinks that the Aeolus
> > team may find the idea useful too as they are transitioning from
> > RedMine to github issues yet still need to coordinate with
> > bugzilla. We'll be sure to include you (and the wider email list)
> > if anything makes it beyond talk.
> > Tom
> >
> 
> What is wrong with bugzilla besides not being github?
> 
> -- bk

The reason I am interested is that bugzilla does not handle cloning and cross-referencing of BZs well for our development model. By that I mean that there are four products in bugzilla to coordinate across: katello, headpin, CFSE, and SAM. If a community BZ is opened in katello, we need to clone it into CFSE and SAM. At that point it gets flags and keywords, someone gets assigned to it, etc. All these actions on one of the copies of the BZ are not reflected in the related BZs. Nor are the changes readily visible in the others. 

My idea is to make a bugzilla dashboard with a table where a row represents a specific issue. Columns in the table would represent that issue in the various places (SAM, CFSE, katello, headpin). This would allow easy editing of flags and ways to note when a BZ in one product changes that should also change in the other product. The columns could link back to not only bugzilla but also github issues.