Feedback on secondary architecute promotion requirements draft

[Brendan Conoboy]

On 04/16/2012 02:20 PM, Matthew Garrett wrote:
> I think a better way to think about this might be lie the packaging
> guidelines - they provide a set of technical constraints, but they don't
> tell you how to be part of the packaging community. I see SAs in the
> same kind of way. Secondary architecture maintainers should be active
> members of the greater Fedora community. You should be talking about
> what you're doing, providing regular status updates on devel@, actively
> involving yourself in other technical discussions to make sure that
> decisions aren't made without consideration of your constraints.
> Basically, behave as if you're a primary architecture.
>
> If you manage that then I think most of the problems you're worried
> about go away. It'll be obvious to everyone whether or not you're ready
> to be a primary architecture at any given point. Don't worry about the
> details. Just be part of Fedora.

That almost sounds like an argument for scrapping the promotion 
requirements document entirely. Is that what you meant?  I understand 
where you're coming from philosophically, but we're talking about 
something more concrete.  Many people who are interested in SA2PA 
promotion requirements are working on Fedora 24/7 and they want guidance 
too.  As documents go I'm all for having a philosophical section on what 
the mindset is, but it should be matched with applied examples.

I think what you're trying to say above is "For a secondary architecture 
to become primary architecture, its team should have a demonstrable 
history of communicating with the greater Fedora community about what 
it's doing and how the greater Fedora community's activities are 
affecting it."  If that is indeed what you mean, please put it in the 
document and include some examples.  The word "communicate" doesn't 
exist in the current document.

I'm open to providing what I think are reasonable examples if they may 
ultimately make it into the end document.

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com