Feedback on secondary architecute promotion requirements draft

[Peter Jones]

On 04/02/2012 11:10 PM, Brendan Conoboy wrote:
> This is feedback vs the current version of the following web page:
> 
> http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29
> 
> It would be nice if the bullet points were numbers so they could be
> referenced numerically.

Done (but btw it is a wiki - you could easily have done this.)

>> Promoting an architecture to primary architecture status is a
>> significant responsibility. It implies that the port is sufficiently
>> mature that little in the way of further architecture-specific
>> changes or rebuilds will be required, and also that it has enough
>> development effort to avoid it delaying the development of other
>> primary architectures.
> 
> What is "...enough development effort to avoid..."? Perhaps this
> could be restated for clarity as a development effort is not a unit
> of measurement.
> 
>> as such there are various expectations that the overall Fedora
>> experience will be consistent over all primary architectures.
> 
> Can we quantify what the overall experience is that must be
> consistent? I understand Anaconda installations is considered a part
> of this... except when it's not for EC2 images. What I'm looking for
> is "These 10 things are partof the Fedora experience- any PA needs to
> provide at least 7 of them" or something like that.

I think this whole process is going to work a whole lot better if we *don't*
focus on having very precise and all encompassing criteria.  General criteria
will suit us much better.

The process for each of the items needs to be more like:

SA Maintainer: Here's what we plan to do to satisfy #3.  Comments or concerns?
FESCo: Well, tweak $THIS and $THAT, and it's looking pretty good
SAM: Okay, well that's a little problematic because $ARCH has a feature that
makes $THAT weird.
FESCo: Okay, just tweak $THIS then.

We're trying to make a general process; being two precise won't help for a
couple of reasons.  First, it leads to doing something you think is right
because of an error in the process document where we didn't consider something.
There's no way we're going to get this right thinking about it in abstract,
and also no way that everything we come up with while thinking of ARM is
necessarily going to apply when the next architecture comes along. So we know
we're going to be wrong about some things, and there will be some accidental
omissions. That has to be part of the process, and the process has to be built
around knowing that. Which leads me to the other reason - it discourages you
from talking to us along the way, and encourages you to go away, do something
and come back. While that's good in some situations, it's really *not* for
this, because it will lead to even more cases where a SAM implements something
because of following rules closely instead of what should happen. 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.

-- 
        Peter