RFC: Upstream (and other) bug/feature tracking

Matt Wagner matt.wagner at redhat.com
Mon Jun 4 22:34:43 UTC 2012


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?

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.

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

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

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

> == 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?

-- Matt



More information about the aeolus-devel mailing list