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@xxxxxxxxxxxxx> -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
