F20 System Wide Change: ARM as primary Architecture

[David Tardon]

On Mon, Jul 15, 2013 at 11:49:21AM +0000, "Jóhann B. Guðmundsson" wrote:
> 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 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.

As you want. But do not be surprised if people do not bother to read
them.

> 
> >
> >>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.

You used it to support your own claim. Therefore you must have meant it
that way.

> 
> >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.

It has exactly the same relevance as your own example. The point was to
show that you cannot apply the same measure on everything.

> >
> >>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?

When you implied that ignoring it is somehow wrong. Either the
maintainer is free to ignore the tool (in which case it is irrelevant to
mention it here), or he is not (and it seems that you think this is
true), in which case it effectively forces him to update.

> >>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.

You started it.

> >
> >>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.

The bug reports are rarely "simplest".

> * Updating your component to the latest upstream release takes/cost
> x x amount of your time.

No, it does not. Not all updates mean just uploading a new tarball and a
few trivial changes to the spec. There are new dependencies, build
problems 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.

Neither will shuffling them from a package to a package, as you proposed
in the paragraph that follows this.

On the other side, if Fedora starts to require from maintainers to fill
timesheets, to tell them how many packages they can maintain etc., it
will surely decrease their motivation.

> 
> >
> >>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?

That is a false fallacy. That a maintainer has fewer components does not
imply that he spends more time on each of them.

On the other side, it is quite obvious that if Fedora drops a package,
the users who want to use that package will leave Fedora (some will try
to find a replacement, but definitely not all).

> >
> >>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.

So again:

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 *because of ARM-specific bugs*.)

(Well, how else could inclusion of ARM as PA _increase_ the load on
maintainers? The bugs and build problems that are already present on
current PA's are, so to say, already there... I thought this was rather
obvious...)

D.