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(a)iphitus.org> wrote:
> On Wed, Dec 3, 2008 at 9:33 AM, w9ya <w9ya(a)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.