Bugzilla usage (was: Re: kmymoney2)

[Ville Skyttä]

On Fri, 2005-02-04 at 11:11 -0500, seth vidal wrote:
> > Regarding this... I never liked using bugzilla from the very beginning, and
> > I find it much easier to reach a large "mostly passive" community through a
> > mailing-list than through a bugzilla. My ideal way of working would be :
> 
> I agree. But if you're going to open a bug - definitely do it in
> bugzilla.r.c :)

Agreed, except I have no problem with using Bugzilla.

> > 1) Make requests for new packages, or post links to packages in order to
> > submit them on the mailing-list (so maybe later on have a
> > fedora-extras-devel-list for that and use fedora-extras similarly to
> > fedora-list).

Good.

> I'd actually encourage things to work as:
> fedora-list for problems in fc or fe.

If that means that package maintainers need to subscribe to yet another
high volume mailing list (this one with a low S/N ratio, I guess),
personal opinion: no thank you.

>  fedora-extras-list for devel,
> requests for packages and itp messages, as well as discussion.

Fine, but see below.

> > 2) From there, let discussions and initial improvements and fixes take
> > place, everyone sees them immediately and may participate (see the snort
> > messages from the past 2 days).
> 
> <nod>

Disagreement.  This will cause too much traffic, and people cannot
choose to not receive stuff they're not interested in.  Example: my
Ctrl-D fingers are getting tired because of the Snort discussions.

I'd rather see discussion moved to Bugzilla earlier when the effort to
package or QA something starts, ie. when someone posts a "I'm interested
in helping out with this" response to a ITP/submission/request + a link
to the Bugzilla entry posted to the list so interested parties can
choose to track and participate; no need to broadcast this to everyone.

In the Bugzilla side, there's already a QA contact set for all Extras
entries.  I don't know where those messages end up currently, but that
could be a mailing list where people wanting to see all of that traffic
could subscribe to.  Bugzilla is smart enough to add an In-Reply-To
header to the mails it sends, so threads should work too.

> > 3) Once the package passes initial QA, then have the maintainer import it
> > into Extras, and have all that is needed created (CVS directory by the
> > import, bugzilla component...).
> 
> WORKSFORME

Ditto.

> > 4) Start using bugzilla from there on for that package, pretty much like it
> > has always been done for RH/FC.
> 
> yop.

Yep.

> > This will avoid bloating bugzilla with repeated RFE's regarding packages
> > that can't be included (think any package that seems ok but needs to link
> > to a patent encumbered lib to be useful),

Yes, but instead, we'll see mailing list archives bloated with this
stuff and repeated RFE's broadcast to the world via the lists.

With Bugzilla, it's somewhat better: one can add a keyword for requests
for packages that cannot be included.  Place the link to a query listing
these packages somewhere prominently, teach users to click & skim that
before placing such a RFE, problem solved.

If not Bugzilla, maintain a separate document.  Mailing lists are not
the answer for this, they're actually the worst choice when used alone.

> > and most of all from gazillions
> > of open submissions that will stay open forever (like in fedora.us).

IMO, this is a welcome feature, not a problem.  If something stays open
forever, it means there's not enough interest to include it.  Keeping an
open entry available somewhere in case interested parties surface later
helps in reducing dupes, and keeps track of past experiences.

> > I really hope to see Fedora Extras draw a clear line between "what's in" on
> > one side, and "what isn't yet / what will never be" on the other.

The "never" part is the same as for Fedora Core.  There are basic rules
on what cannot be included.  In addition to that, a list of packages
that fall under this category probably needs to be maintained somewhere,
see above.  Remaining two categories: what's in is what's in (unless due
to some changes it will move to the "never" category), and what isn't
yet is what's left after the "in" and "never" parts.  What clear lines
remain to be drawn _in Extras_?

> However, I do think that if you want something
> tracked over the long term it needs to be in bugzilla.

Right.