From: Rolf Leggewie <no2spam@nospam.arcornews.de>
To: openembedded-devel@openembedded.org
Subject: RFC: aggressive usurpation of bugs.oe.net by Angstrom
Date: Wed, 30 Jan 2008 18:03:23 +0100 [thread overview]
Message-ID: <fnqakr$ffa$1@ger.gmane.org> (raw)
Hello,
I have witnessed some aggressive usurpation of the bug-tracker by
Angstrom devs recently, especially concerning meta-bugs. This has to
some extent brought back the bickering we all try to avoid.
I want to discuss this with you but cannot offer an immediate solution.
I think the whole structure needs some reconsideration to make sure
that different distributions don't step on each other's toes or one
distribution claims the BTS all for itself. The information in the bug
tracker is there for all to share and make OE better.
The problem - which I have been considering for almost a year now -
stems from the fact that OE vs. distribution vs. on-device is not
clearly distinguished. bugzilla also does not allow marking two entries
for field X.
* there are issues at time of compilation, but they can be
distro-specific, host-specific, foo-specific or generic
* there are issues on-device and they can be device-specific,
distro-specific, foo-specific or generic
* It is also possible that one bug exists in A* 2007 and Sharp ROM,
but not in A* 2008. Currently, this is impossible to mark correctly.
We don't clearly distinguish and our field labels reflect that, making
it hard for people to carve out the bugs that affect them as well as not
step on one another when trying to resolve the problem for their
specific distro. launchpad for example does this much better, but
generally sucks even more with regards to fields and searchability.
The problem partly stems from the fact that bugzilla is usually not used
in a cross-compile environment (what does the Hardware field mean?, what
does OS mean?). We have tried to work around this with meta-bugs in the
past but it becomes increasingly difficult.
So much for the status quo. I think we eventually will need to rework
the labels and fields and communicate their meaning more clearly, but I
cannot present "the" solution yet. Suggestions and discussion welcome.
Regards
Rolf
next reply other threads:[~2008-01-30 17:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-30 17:03 Rolf Leggewie [this message]
2008-01-30 18:18 ` RFC: aggressive usurpation of bugs.oe.net by Angstrom Rolf Leggewie
2008-01-30 18:38 ` Paul Sokolovsky
2008-01-30 21:41 ` Rolf Leggewie
2008-01-30 23:56 ` Paul Sokolovsky
2008-01-31 9:49 ` Rolf Leggewie
2008-01-31 11:00 ` Paul Sokolovsky
2008-01-31 11:08 ` Rolf Leggewie
2008-01-31 12:28 ` Richard Purdie
2008-01-31 13:36 ` Paul Sokolovsky
2008-01-30 20:00 ` Koen Kooi
2008-01-31 14:07 ` Paul Sokolovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='fnqakr$ffa$1@ger.gmane.org' \
--to=no2spam@nospam.arcornews.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.