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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
