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
> This is the list I have so far, with some feedback from others,
> 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.
* 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:
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)
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:
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