RFC: Upstream (and other) bug/feature tracking

Jason Guiditta jguiditt at redhat.com
Tue Jun 5 13:20:02 UTC 2012


On 04/06/12 18:34 -0400, Matt Wagner wrote:
>On Mon, Jun 04, 2012 at 04:56:59PM -0400, Jason Guiditta wrote:
>> This is an attempt at getting some feedback on requirements for our
>> various bug/feature tracking needs.  I have deliberately omitted the
>> 'options' section, so we can focus as a group on requirements only at
>> this point.
>>
>> At the moment, we have or need a way to track both types of issues
>> from the following standpoints:
>> * Upstream project
>> * Fedora releases
>> * RHEL/product releases
>
>In addition, to me there's a distinction between new feature development
>and bugfixing. New features generally (always?) happen upstream, and
>often involve nested tasks -- a feature with individual tasks, perhaps.
>Does this seem like a valid distinction to make?
>

Agree they are different types, the intent was to address both.

>To add what hopefully seems obvious: whatever we use for upstream bug
>tracking really has to be totally open and public. If we enter a bug,
>anyone should be able to see it without signing up or logging in
>(with the possible exception for critical security bugs or whatnot?),
>and anyone in the world that wants to contribute to our project by
>reporting new bugs or offering to take existing tasks should be able to
>do so easily.
>

+1 - note this would not be a departure from our current (poorly
documented) setup.

>> This is the list I have so far, with some feedback from others, though
>> not as much as I would like.
>>
>> == upstream tracker ==
>>
>> * report code level stuff here.  This really needs to track what is
>>   in github/master at any given point in time.
>>
>> *relate this upstream bug to something released -either fedora
>>  or rhel (relation could be established by this system or the
>>  other system as long as it works)
>
>Oh, interesting. I think this would hold up as we (hopefully) start to
>package for more platforms. If we packaged for Debian, for example, I
>think we'd want to relate tasks to a Debian-specific bug tracker.
>

This is a good point.  While I dont really think 'we' will be doing
such packaging ourselves, this could be a reason to choose one system
over another - something that integrates with as many other types of
trackers as possible seems like a big plus for this kind of scenario.

>> * ability to define features that are comprised of many tasks
>> * set some kind of due date to allow mapping to sprints
>
>I'd either make this vaguer to say "mapping to sprints" (arbitrarily
>defined), or expand it to include not just due dates, but also
>components, since we currently have Infra and Conductor with parallel
>sprints. Whether the tracker has a native concept of a Sprint with
>"project" and "due date" attributes or whether it's just a tag or
>something we add doesn't matter a ton to me.
>
How about:
* set up mutliple target releases that features may be mapped to (this
   could be a sprint, milestone, whatever term is chosen).
   
>> == Fedora ==
>>
>> * Choose a place where someone can report a bug against a fedora
>>   rpm, instead of always reporting it against the product
>>
>> * report fedora bugs here (or clone them from product) --
>>   needs to track what is in the fedora rpms
>>
>> * We already have existing BZ components, listed here:
>> ** https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=aeolus-configure&resolution=---&list_id=62611
>> ** https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=aeolus-conductor&resolution=---&list_id=62649
>> ** https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=aeolus-all&resolution=---&list_id=62644
>> ** https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=rubygem-aeolus-cli&resolution=---&list_id=62672
>> ** https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=rubygem-aeolus-image&resolution=---&list_id=62674
>
>Should we expand this to be distro-agnostic? If we talked about Debian
>packaging (and I keep just using that as an example), I think that we'd
>probably want something that Debian users could use easily -- i.e.,
>something that integrated with existing Debian infrastructure. So I
>think the same is probably true for Fedora. (Even though, if you read
>between the lines and infer a particular option/product from this, I
>have no love for that option.)
>
The scope of this feature is upstream and currently supported distros.
I we can keep things open for the future great, but a decision there
is not a requirement at this time.

>> == CloudFormsCloudEngine (details out of scope here) ==
>>
>> * report product bugs here (tracks what is in the product RPMs)
>>
>> -j
>
>
>What I find interesting about this email is that it doesn't tackle what
>I think the biggest problem right now is -- patch management. Perhaps it
>should be integrated with this, perhaps not. While I don't have any
>particular love for Redmine or Bugzilla (both of which we use today),
>neither of them is agonizingly bad IMHO. On the other hand, the lack of
>an easy way to tell who is reviewing a patch, what patches need review,
>etc. _is_ agonizingly bad right now, IMHO. Should this be a separate
>discussion, or does it make sense to bring the two together?

That is a separate feature, and is account for here:

https://www.aeolusproject.org/redmine/issues/3253

Fwiw, I didn't reference it initialy, which is probably why you asked,
but this email is in fact part of the output of a feature for the
current sprint:
https://www.aeolusproject.org/redmine/issues/3284

-j

>
>-- Matt



More information about the aeolus-devel mailing list