F20 System Wide Change: ARM as primary Architecture

["Jóhann B. Guðmundsson"]

On 07/12/2013 12:08 PM, David Tardon wrote:
>> I dont argue that this should be a blocker for architectures quite
>> >the opposite as far as I see it the only requirement for an
>> >architecture to be come a "primary" ( thou arguably those are
>> >outdated concepts as well ) is that all package currently build (
>> >with the execption if they simply cannot work on a spesific
>> >architecture ) and be available for the community to use as lego
>> >bricks to shape and present to the world as they image in for that
>> >relevant hw.
> It is only a few weeks you argued that we should drop all packages that
> are not "properly maintained". Before that, you wanted to limit the
> number of packages a person can maintain, (by your words) to ensure that
> he (or she) has enough time to maintain them. Now you think it is a good
> idea to add a whole new architecture, which means additional maintenance
> load for_every_  package. Could you try to be at least a bit consistent?


I still think...

We should drop all packages that are not "properly maintained" since it 
affect many communities including the hardware architects ones since 
they would have ensure those packages that are not "properly maintained" 
would build for their architecture before they would become an primary 
architecture.

I would think their time in the project would be better spent on 
components that are actively maintained but you apparently dont.

I still think...

We should limit the number of packages that individuals can maintain so 
that they can effectively maintain them and as has been pointed out many 
times with the arm architecture sub community that they are willing to 
help with arm specific bugs not general ones bug the ones but let's 
assume they don't which results in higher maintenance on the relevant 
component which would results in fewer components that individual could 
maintain since it would take more if his or her time to maintain it.

If you dont think maintainers are already overburden and them being so 
does not directly affect not only those maintainers directly but also 
the community in whole, let's just take Peter Jones for an example an 
newly re-elected FESCO member.

Not only does he not respond to bug reports like [1] but he also ignores 
infrastructures tools [2] that exist for the sole purpose to notify 
maintainers about new upstream releases ( and this is just one of his 
components which has 18 bugs assigned to it by my account )  but he 
thinks he has enough time to serve on fesco at the same time which 
requires him to do at least research into at least each ticket filed in 
the fesco tracker and review of system wide features and how ack/nack 
those features will affect the community in whole.

Do you honestly think this is healthy for him or for the project in whole?

My solution to address problem like this and prevent "burnouts" in the 
project ( although not officially concreted and proposed ) is that we 
implement a form of a time share program for the project ( which 
arguably should not be limited to package maintenance since this in 
essence does affect all participants in the project ) and maintainers 
simple sign in how much free time they have or are willing to spare 
daily/weekly/monthly in the project and based on those free hours he or 
she has, we should be able to calculate how many components he or she 
can maintain which could be one if it has an high maintenance burden or 
10, 20 100 with low maintenance.

As more sign up to co-maintain component the more free time do the 
existing maintainers get, which they in turn can use to (co ) maintain 
another component or spend elsewhere in the project.

Implementing something like this would have significantly reduce the 
number of components we have available with the increased stability and 
not only healthier project but healthier participants as well.

In any case i'm not following how I was somehow being "inconsistent" 
with myself with my response and if you have any proposal to solve the 
previous mentioned problem in the distribution I'm all ears.

JBG

1. https://bugzilla.redhat.com/show_bug.cgi?id=949328
2. https://bugzilla.redhat.com/show_bug.cgi?id=869540