This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Moving ports architectures to libc?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 27 Jan 2014 18:12:37 +0000
- 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>
On Mon, 27 Jan 2014, Siddhesh Poyarekar wrote:
> On Sat, Jan 25, 2014 at 03:11:00AM +0000, Joseph S. Myers wrote:
> > One thing I failed to consider in my proposal: what do we do with the
> > "ports" Bugzilla component?
>
> We have an 'Architecture' field in the Red Hat bugzilla which I've
> found to be quite useful. I don't know if it is a customization or an
> existing feature in bugzilla that just needs to be turned on.
>
> It would be nice to be able to select multiple architectures though
> (which is not possible in the Red Hat bugzilla AFAICT), so maybe
> bugzilla flags or some other similar method may be a better idea.
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.
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.
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.)
--
Joseph S. Myers
joseph@codesourcery.com