On 07/15/2013 07:42 AM, David Tardon wrote:
On Fri, Jul 12, 2013 at 02:17:28PM +0000, "Jóhann B. Guðmundsson" wrote:
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
How?
If a package fails to build (on PA), there are several means to resolve
it less severe than dropping the package (provenpackagers, unresponsive
maintainer process, escalation to FESCo).
What do you mean how?
It's the packagers/maintainers responsibility to ensure his or her
component(s) work in the distribution proven packagers should not be
used to clean up other maintainers mess in the distribution because they
aren't paying attention to their component or do not have enough time to
maintain it.
since they would have ensure those packages that are not "properly
maintained" would build for their architecture before they would
become an primary architecture.
They have to do it for all packages anyway. There is no requirement that
a maintainer be able to fix arch-specific build problems himself and
upstream might not be interested.
I would think their time in the project would be better spent on
components that are actively maintained but you apparently dont.
I have not said anything like that. I just think your definition of the
meaning of actively maintained (or properly maintained) is completely
unrealistic. That is why I write it in quotes.
Well obviously I dont think it's unrealistic that packagers and
maintainers actually maintain their component in the distribution.
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.
Could you try to use some punctuation? It is quite hard to parse your
paragraph-long sentences...
No I cannot not.
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]
Sorry, but that example is unconvincing. AFAIK there is no policy saying
that every package must be kept at the newest version at every price.
There might be a very good reason why it has not been updated.
(Conversely, you have not provided any reason why it should be updated
in the bug...) And syslinux is not exactly a key part of the distro.
Never said they did or have so stop twisting my word to somehow aid the
point you are trying to make.
An example: there has been a new release of mdds. I have not updated it
in Fedora, because there has been an API change and libreoffice 4.1 does
not build with it. By your reasoning this means mdds is not "actively
maintained"...
Seriously, world is not black and white, even if you are trying to see
it that way.
Irrelevant the point was to show that he did not respond to the bug
report this whole time not whether he went all the way and update the
component in the distribution and he is just one sample of many.
but he also
ignores infrastructures tools [2] that exist for the sole purpose to
notify maintainers about new upstream releases ( and this is just
The tool exists to _notify_ maintainers about new releases, not to
_force_ them to update.
Clarify when I did sat the tool was supposed to be used to force
maintainers to update?
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.
This is disrespectful to Peter.
Really how is pointing out that Peter is overworked disrespectful to
Peter himself, something that he himself might not realize?
Do you honestly think this is healthy for him or for the project in whole?
I am not his nanny, so I cannot tell him what is good for him. And I am
not in the habit of extrapolating from one accidental sample,
This general problem in the distribution and not limited to Peter
himself so don't try to make this about him.
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.
This is completely unrealistic. There is no metric to measure a
maintenance cost of a package.
Yes there is you can set a baseline and measure against that like.
* Dealing with a single simplest bug report takes/costs x amount of
your time.
* Updating your component to the latest upstream release takes/cost x x
amount of your time.
etc...
And how could anyone know how much time
he will be able to spend regularly on the project this week? Next month?
Six months from now? The packagers here are _volunteers_. We need to
motivate them, not force arbitrary rules on them.
Illogical conclusion but feel free to motivation people as much as you
want but it will not increaser the free time they have to spare to
dedicate to the project.
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.
You have just sketched a perpetuum mobile.
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.
This is what you claim, but you have nothing to prove it. I claim that
the process you envisioned would result in increasingly disgruntled
maintainers and a decrease in the number of users, as Fedora starts to
drop packages they use.
How can you claim that I have nothing to backup my claim while it's
quite obvious that fewer component that individual maintains results in
him being able to dedicate more of his free time to only maintain those
component resulting in better maintainership of the component he
maintains which in turn results in more happier users of that/those
components, while you dont back up your own claim?
In any case i'm not following how I was somehow being "inconsistent"
with myself with my response
I try to restate it, then.
On one side:
1. you have proposed to drop packages that fail to meet some arbitrary
maintenance standards
2. you have proposed to limit the number of packages a person can
maintain, to make sure that maintainers are not overloaded.
On other side:
A. you are fine with adding a whole new primary architecture, which
contradicts point 2/ from the previous list (by increasing
maintenance load for _all_ maintainers)
B. you propose that the criterium for doing this is that all packages
build, which very probably contradicts point 1/ (that something
builds does not mean that it _works_ too. And if it does not work, it
shifts the responsibility to make it work on its maintainer, which is
against point 2/ again).
tl;dr: You aim to increase 1/ quality of the package base and 2/
healthiness of the maintainers. Inclusion of ARM as PA immediately
decreases both of these. Therefore, by supporting inclusion of ARM as
PA, you are contradicting your previous claims.
I'm not contracting anything.
If they are dealing with arm spesific bugs yes it might depending on how
much assistance the arm community provides, if not no they are dealing
with the same amount of bugs against their component regardless of the
number of architect it runs on.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
