Feedback on secondary architecute promotion requirements draft

[Brendan Conoboy]

On 04/03/2012 08:21 AM, Peter Jones wrote:
[snip]
 > We need to
> make the whole process one with continuous feedback, or it's never going to
> work.
>
> So I'd expect that we don't want to specify anything all that precisely -
> I'd rather you come up with an implementation plan to satisfy each point,
> and then we (SA Maintainer and FESCo) decide together if it's satisfactory,
> and later decide that it has or hasn't yet been met, and if not what remedial
> steps should be taken.

Communication is really the piece which needs development in the 
proposed guidelines.  SA's tend to work quite independently so the 
proposal needs to spell out a few things that get everybody 
communicating at the right times and the right ways.  It's probably 
perfectly clear in many people's minds folks how these things should be 
handled, but if we could formalize them a tiny bit it would do wonders 
for filling in what's missing in the secondary promotion draft.

1. What does the SA2PA proposal need to cover?  MJG's 10 criteria give a 
general scope of what needs to be covered, so this is more or less done. 
  If I'm reading Peter's comments above correctly the guidelines should 
indicate that the SA2PA proposal must be generated by the SA team (as 
opposed to FESCo) and should address all 10 points.

2. How should an SA team propose to FESCo and the community that their 
SA is ready to be evaluated for PA track?  Is submitting a feature page 
the right way to start, or a discussion on f-d-l?  Whatever the right 
way is I'd like to see that information added to the proposed guidelines.

3. When should the SA team make their first proposal?  There is great 
potential for wasted effort bringing the topic up too early or too late 
in the SA's development, not to mention when in the primary release 
cycle such topics should be brought up.

4. How to keep FESCo and the community informed during the process. 
Presumably after #2 there will be feedback along the lines of "you need 
to do more on points x, y, and z".  If the answer is "FESCo will say how 
to keep everybody informed" then let's have the proposal state that.

Basically, I think the guidelines MJG has put together are good 
principles; they just need some procedural blanks filled in so SA teams 
know how to apply them and communicate with the greater Fedora community.

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