New tracker bugs for the use of ExcludeArchs in packages

[Thorsten Leemhuis]

Am Sonntag, den 29.01.2006, 15:58 +0100 schrieb Hans de Goede: 
> Thorsten Leemhuis wrote:
> > Am Sonntag, den 29.01.2006, 14:47 +0100 schrieb Hans de Goede: 
> >> Thorsten Leemhuis wrote:
> >>>> What if the ExclusiveArch is not a bug but a feature, for example say a 
> >>>> userspace support tools for certain hardware only found on certain 
> >>>> archs? Then there is no problem to fix, should one then still file bugs?
> >>> In the past I would have said "no" but a lot of other packagers
> >>> disagreed and convinced me -- so the answer is a "yes" from me now.
> >>>
> >>> Other people simply might not know that the package is "for certain
> >>> hardware only found on certain archs". So it should be written down
> >>> somewhere. A bug is the right place for it. And in such cases you simply
> >>> can close the bug after reporting (as I wrote in the first mail). 
> >>>
> >> I find this purely administrative overhead with little or no gain.
> > 
> > There is one thing in this discussion that I don't understand: It seems
> > I'm the bad guy now for a small modification (that several people
> > requested in the past) to a policy that we have for several month now.
> > Did I miss anything? All I requested was to link that bug to another.
> > Nobody complained before about the "Bugs need be filed for all
> > ExcludeArchs" rule that is there for a long time already.
> 
> This is in no way meant personal, you're the FESco chair, you're 
> speaking on behalf of FESco, I'm replying to FESco, not to you personal.
> <humor intended>
> Didn't you notice this big bullseye on your back yet ?
> </humor>

:-)

>[...] 
> > Hans, would you prefer if we handle the "ExludeArch because a package is
> > for certain archs only" handle in the spec files directly as comment?
> 
> Yes, that would be exactly what I want. That would also keep the normal 
> bugzilla components (everything but "Package Review" component) for what 
> they are meant: Bugs, not building on an arch where the package should 
> reasonably built is a bug, not building because it is useless is not a 
> bug. (Some might even built, but since they are useless why would one 
> built them?)

Well, there needs to be a place where is written "thinkpad-foo is not
build for x86_64 and ppc because their don't exists notebooks for that
arch (even if it might build on x86_64)". Do we all agree on that? I
think we do.

But I would prefer *one* place for this information rather then
splitting it into two. Why? Let's play x86-64 developer that wonders why
thinkpad-foo is in extras/4/i386 but missing in extras/4/x86_64:

Scenario a (everything in bugzilla):
- He jumps to the dep-tree view of the well know tracker bug (he has a
bookmark for it because he often needs it) an simply searches for
thinkpad-foo with his browser and finds the explanation

Scenario b (some notes in bugzilla, some in the spec file):
- He jumps to the dep-tree view of the well know tracker bug (he has a
bookmark for it because he often needs it) and finds nothing.
- He now either looks for the complete cvs checkout or the cvs
web-interface for thinkpad-foo reads the explanation there.

Scenario a is IMHO a lot easier for the x86-64 person. For the packager
it's IMHO not a big difference to add a explanation to a spec file or to
open a bug (and close it directly after that) (Maybe some people
disagree with me here). (Side note: Some people don't like longish
comments in the spec file because they clutter it.

Second example: Lenovo releases a notebook with x86_64 cpu.

Scenario a (everything in bugzilla):
- x86_64 developer stumbles about the closed x86_64 bug while he was
working in the tracker bug. He thinks: "Lenovo released a notebook with
a x86_64 cpu -- we need to reopen that" and does exactly it.

Scenario b (some notes in bugzilla, some in the spec file):
- He probably does not notice. If he does he need to open a bug.

CU
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>