Re: Feedback on secondary architecute promotion requirements draft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/18/2012 06:42 PM, Matthew Garrett wrote:
[snip]
What if some forms of the hardware are desktop capable, others are
not, but the community only has an interest in supporting headless
installations?

Then it's not fit to be a primary architecture.

Okay, please add examples like this wherever possible.

I believe a subsequent discussion on the matter has yielded the
value of 4 hours.  Can the guidelines include this, perhaps with the
caveat of "At the time this draft was approved, the agreed maximum
build time for a kernel was 4 hours."

No, because it's the kind of thing that's going to be influenced by
multiple factors. Each architecture seeking PA status should have this
discussion with the kernel team.

Huh? The whole point of this item is that it's architecture neutral- the kernel team for security reasons believes it important that all kernel builds take less than 4 hours from start to finish. Why would a new architecture change that number? There's a caveat in the suggested wording above. Don't understand the resistance.

Okay, you're clearly writing that with a do everything to be PA
while SA, then you'll have proved yourself mindset.  That's fine,
but it would help to spell this out.  You might just as well say all
architecture-specific issues are fixed before promotion may be
granted.  I'm not sure that's an achievable goal, frankly, but that
does seem to be what you're saying.

Becoming a PA won't magically produce extra maintainers. It's still
going to be up to the architecture maintainers to deal with ARM-specific
bugs in packages, if the package maintainer isn't able to deal with
them. So, yes, I think in this respect it's important for the SA to
demonstrate that it's not going to hold up development once it becomes
primary.

I'm nonplussed by the answer, but can't disagree with it either. This seems to make #5 and #8 the same thing. You just need to merge them by adding the changes you'd already agreed with below, and including something like "All packages that are architecture neutral or have been ported to ARM must build from the same srpm prior to PA promotion."

[snip]
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.

Okay, please clarify in the document.

Ok.

Thanks!

--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux