This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Moving ports architectures to libc?
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 28 Jan 2014 09:59:28 +0530
- Subject: Re: Moving ports architectures to libc?
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401212254020 dot 25161 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1401250256210 dot 16529 at digraph dot polyomino dot org dot uk> <20140127040439 dot GB2149 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1401271806180 dot 8452 at digraph dot polyomino dot org dot uk>
On Mon, Jan 27, 2014 at 06:12:37PM +0000, Joseph S. Myers wrote:
> The aim is that it's obvious in search results (preferably default
> results, though you can customize columns) which bugs are
> architecture-specific, and what architecture they are specific to. Hence
> the suggestion of [arm] at the start of bug descriptions.
I think there may be ways to configure the title to have additional
text based on attributes of the bug. But I agree that having the arch
mentioned in the title (regardless of whether we end up having an arch
attribute for bugs) would be useful.
> If a special field is used, it needs to be unambiguous that this is for
> architecture-specific bugs and *not* for the architecture the original
> submitter observed the bug on - it should only be set when confident the
> bug is architecture-specific.
Agreed. That's exactly how we use it in the Red Hat bugzilla. The
default value is 'all' and the reporter chooses an architecture if
they think the problem is specific to an architecture. Very rarely
have I seen cases where someone has chosen an architecture based on
which environment the submitter observed the bug on. Of course, some
help text explicitly specifying this would obviously help.
> I *don't* want multiple architectures selected on one bug. If the same
> bug appears in architecture-specific code for more than one architecture
> (which can certainly happen) then it's best to consider them as separate
> bugs, so when someone fixes the bug only for a subset of architectures
> they can close exactly the relevant bugs and it's clear what bugs are left
> for fixing on other architectures. (I don't really like retitling a bug
> to reduce its scope after parts have been fixed; it's confusing if the
> title of the bug after it was finally fixed only reflects the last case
> fixed rather than all the cases fixed for that bug.)
That's a good point. I agree.
Siddhesh