Here are the short answer to your questions/comments/reflections from below.

- I have already answered, on the 29th, with a lengthy list of consequences. Some people have said the list is too long to read through !!
- I have already (in previous emails) pointed out that these very issues **were** discussed in the adoption of aurvotes and in the matters concerning sergej. On other occasions there have been TU discussions about other restrictions based on numbers of packages and appropriateness of whether TUs should be asked to submit packages for approval.
- As has already been discussed in the past couple of weeks, there is NO basis for any statistical standard. Your trust in Allan is noted, but even he has not come out and discussed any particulars. I would like to see the system proposed BEFORE I am asked to vote on its' acceptance.
- As has already been pointed out; NO ONE is suggesting waiting until the last gasp (or last breath) of a resources issue. The engineer joke was cute, but it IS over the top also.
- In fact there is NO resource issue. The folks in charge of such thing have commented in just the past few days as much. In fact they have pointed out that there is no looming issue either; not even in the not-so-near future.
- There are other alternatives, a few of which have been suggested in the past few weeks. It would have been nice if these had been acknowledged.

-FINALLY, by removing 10% or so of the programs in community, how do we SOLVE a resources problem that will not come up again within a few short months ? Then what, a 20% reduction ? *** You see the REAL problem is that this is a poor way to solve a resources problem. More effort AND expense and so forth than simply spending a small amount of money and beefing up some hardware.

Regards;

Bob Finch


On Tue, Dec 2, 2008 at 5:40 PM, James Rayner <iphitus@iphitus.org> wrote:
On Wed, Dec 3, 2008 at 9:33 AM, w9ya <w9ya@qrparci.net> wrote:
> (This should NOT require a reply, as it is merely some short observations.)
>
> Hey Allan and those who are still bothering to read all the emails on this;
>
> I decided to review some of the early emails leading up to your current
> proposal to modify the 'community' repo and how it is used. And I found this
> thread you forked and it seemed like a good idea to write you this personal
> but public reply. I am quoting your email in it's entirety below. I am going
> to ask you to do something at the end of this message, and I hope you have
> the courage and foresight to read through this email twice. I will NOT be
> mincing words, because quite frankly now is not the time to do so.

I've read it twice.

> But most importantly I can answer your concerns about server/system loading
> this way; It is not a concern because the folks that are in charge of
> maintaining such things say it is not a concern, and this just two days ago
> in another email thread about 'what belongs in the community repo'. Further,
> when things in the past have gotten overloaded, they have been fixed by more
> direct means than what you are asking about. i.e. Servers are upgraded,
> software is upgraded, connections and so forth are improved.

While size is presently not an issue, Arch will grow, [community] will
grow, and I think it's prudent to consider Allan's suggestions.

Back when the original TUR repositories existed, the TU's then used
them respectfully. Packages tended to be of a popular nature, and no
TU maintained an excessive number of packages. I recall I used your
repo a great deal.

Since then we've seen at least one situation where this trust has been
abused. If you remember WillySilly, who added literally every package
he built to the repositories. I don't recall how many he ended up
maintaining, but it was over 500. When he disappeared, that left 500
unmaintained packages. Many of them were of questionable value, some
poorly packaged.

As Arch's grown, we now have x86_64. This adds a new requirement -
most packages need to be built twice. This effectively doubles the
requirements for maintainers. WillySilly's over 500 questionable
packages, becomes over 1000.

We have always dealt with these problems when they came to our attention with needing to "think ahead" and so forth. When quality and server issues became apparent. we dealt with them. Why do we suppose we are not up to task now ?

 


This isn't about server resources, it's about _efficient_ use of both
maintainer and server resources. Resources are scarce, if we have a
temporary excess we shouldn't go blow it - we'll regret it later.

Again, this has always been dealt with in the past and there is NO reason to suppose we cannot in the future.
 


Consider my package NPPAngband. Recently in the census it became
clear, and not surprisingly, that there's very few users. It's an
awesome little game though (don't go install it, it's broken atm). At
first my reaction to removing it was negative, like yours. I thought
that there should be some allowance for 'pet' packages of questionable
value. After considering this, it became clear that this was a
somewhat selfish view. I struggle to find any real justification to
keep it there. The extra use of maintainer time and server resources
don't justify the insignificant number of people who use it and nobody
would mind at all if I moved it back to the AUR where it belongs.

O.k. and that is your decision. Since I knwo some of my packages do not receive any votes yet are used by dozens of people that have NOT placed aurvote unto there machines, including those who use DIRECTLY the archlinux install, I already know that your program mightbe used by many more people htan you suspect.

In fact much of my current repo is used by ham radio operators that are not interested in fiquring out how to install yaourt of aurvote and so forth. They jsut want a tool.. It is a BIG community that Arch should ignore because of a lfawed voting and statistical package that cannot be counted on to yeild useful data ?
 


> THE REAL QUESTION you are asking about is whether such a restriction and
> fundamental change makes sense. And the answer is, once again as it has been
> several times in the past years, NOT A NEW ITEM to vote upon. This question
> comes up quite regularly for the TUs to vote upon.

I recall no situation in the last 3 years where a baseline requirement
for package popularity has been voted.

I said, as you quoted above "restrictions" . You speak about "baseline requirements". I stand by my statement. And yes we did vote on whether someone should be allowed to enter certain things into the repo in the past. In fact the discussion/cum vote on whether sergej should be alowed to maintain his pacakges WAS a vote on "baseline" issues. That was recent too.
 


> You see Allan, the TU system is an experiment that can be found NO WHERE
> ELSE in computing I am aware of. NOWHERE else can a group of users be so
> involved and with the freedom to contribute as we, (individually OR in
> groups,) find it useful to do so. ONLY with this CURRENT system. We have
> ALWAYS sought to create the most freedom herein so we could get the most
> benefit. Quite frankly your proposal seeks to replace this with a system of
> rules for inclusion and voting for exceptions and one TU seeking the
> approval of other TUs before adding something and so forth. This is a
> FUNDAMENTAL change in the way things are. And the is NO GOOD reason to do
> so. You have been given several weeks to outline why, and you have yet to do
> so. Some future resource problem is not a good enough reason. And yes we
> HAVE discussed this very issue in past voting on other proposals.

I can't see how this proposal 'destroys' the TU system as you imply.
The vote requirement suggested by Allan is extremely low - it's
trivial for a package to get 10 votes.

It is a fundamental change for the reasons discussed inthe paragraph you quote above. I have NEVER seen fundamental changes such as these that do NOT lead to what I described.
 


> I want you to consider that we ALSO have been seeing some rather elitist
> behavior from those supporting your proposal too. It has been rather well
> established that there is no way to know what even a vote of 0 represents,
> let alone ANY number. Yet I have seen MANY messages talking about the
> "useless glut" of programs in community, and that if someone does not vote
> they do not "count" and what packages they use should not be "considered"
> for what programs are "allowed" to be in the community repo". Well if you do
> not know what people are using, how can ANYTHING be either "useless" or part
> of a "glut". All of this should be a concern to you. IS this what you want ?
> Are you so fed up with the way things are now that you are willing to be a
> part of such a disreputable thing ?

Allan is a professional statistician. He's qualified to analyse data
sets. We have a data set in pkgstats. If Allan believes there is a
correlation between votes and pkgstats package usage, I am more than
happy to take his professional opinion.

Then I am sure Allan will be happy to show us the statistical analysis and stand by it. To date that has nto happened. Instead what has happened in people on BOTH sides of this discussion have pointed out the manner and amoutn of error inthe surrent pkgstats and aurvotes. In some of these emails it has become clear that even as little as 3 votes can mean 3 or severla humndred actual suers. And we do NOT know which of those number extremes is most likely either.
 


> Quite simply, are you willing to let Archlinux remove the ONLY unique thing
> that separates it from other *nix distros. Are you willing to be a part of
> turning the "community repo and the TU/Aur system" into something that only
> a majority can decide what will be in it, when there is now space for all to
> contribute ?

10 votes is not a majority - it's an insignificant number of votes.
It's effectively 9, as the packager can vote himself.

This is a pythonic 'ask for forgiveness' situation, rather than 'ask
for permission' as you describe. If a TU believes he can justify a
packages place within the repository, then there's no issue with him
adding it. The TU makes the decision, not the masses.

Our system, as you know, is NOT one of asking someone else;'s permission. It is unique and has worked well. It has not failed. Your saying the TU makes a decision with the new proposal is wrong He gets to sak and others make the decision.

 


> So I will leave you with this comment; Please do not seek to "fix" something
> that is NOT BROKEN.

As easy as that cliche is to use, it doesn't always apply. Would you
prefer that airlines wait for aircraft to break before they consider
maintenance? I think in this situation we're really trying to avoid
future problems with excessive growth.

Engineer: Wing spar's not broken yet! My calculations say that it
might have one more flight left in it! Good to go!

Nonsense and you know it. No one is saying it is on the brink of failure or even close. In fact the folks here at archlinux that maintain the systems say there is no problem now and there is PLENTY of room for storage and growth.
 


> It is a fool's errand, and you will not be able to
> moderate or contain any unintended consequences from your actions any better
> than you have been able to contain any of the poor behavior your proposal is
> creating.

What consequences do you speak of? You've mentioned these, but failed
to outline what how these unintended consequences of Allan's proposal
would manifest themselves.

Yes i have. I got some nasty mail in reply too. A few days back, definately inthe past 8 days or so. Someone else asked and I answered this in quite some detail. It was not complete as there are MANY such issues and consequences.
 


> Your message that I quoted below begins with your concern about
> things getting out of hand. I hope you reconsider your proposal. Rescinding
> it now would show real courage and understanding; Wisdom beyond your years,
> so to speak.

Wisdom or just another manifestation of Clarke's first law?

> Best regards;

Cheers!

James

Bob F.