Well, given you don't wait the few hours to put this forward at the TU
meeting, I won't wait to respond to you.
w9ya wrote:
Hi all;
Some quick comments/corrections to Allan's Wiki page;
- His first question/answer about the purpose of the Community Repo;
<- The AUR was not in existence in ANY form for several years AFTER
the introduction of TU **BINARY** repos. While Allan (and others) may
truly believe that the community repo is designed strictly to be a
place for popular AUR contributions there is NO historical basis for
this belief. i.e. We the TU's, as WHOLE group, have *never* determined
this to be a sole basis OR requirement for binary packaging. Nor, in
the past when this has come up (and it has a few times), have we EVER
decided to make such a decision, as it was considered to be a bad idea
to do so for a variety of still pertinent reasons.
OK. So lets look at the revision of the AUR Truted User Guidelines from
July 2005:
http://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines&oldid=794
In the description of a TU: "He maintains popular packages". That is
the oldest (and unchanged since then) definition of a TU we have to go by.
For those of us that are historically unaware, can you outline your
"still pertinent reasons". In all your previous emails saying similar
things I saw no reason other that "it was never the way". Sure it
wasn't the way in the start (as there was no AUR) but things change.
AS SUCH, Allan's premise is flawed as is everything else on the page
is based on this erroneous premise of purpose.
(BTW, I have been told such historical examinations are "regressive"
and as such NOT "progressive". I will encourage you all to decide if
such an understanding is "regressive" or really just a useful way to
gain knowledge and understanding and prevent mistakes.)
- Allan goes on to discuss what a "popular" package is. There is
absolutely no way to determine what 3, or 20, or what any number of
votes truly represents for a variety or reasons. I have discussed just
why there can be no correlation in a previous email. Prior to sending
that email I asked for such a correlation and received none. I then
wrote that email where I outline the flawed mathematics, I have yet to
see a rebuttal. There is NO way to tabulate and correlate the votes as
to representing even a percentage of users. Do NOT let Allan or anyone
else tell you otherwise. It simply is NOT true at this time.
I gave a link to a plot on the wiki page showing the correlation between
number of votes and usage from pkgstats for my package. The correlation
is visibly high, with the exception of packages included as
dependencies. As we have no better numbers available to us, and the two
numbers we do have agree reasonable well, we might as well use what we have.
TO WIT; whether it is 3 votes (the original minimum suggested) or 20
votes; they are merely a number with NO MEANING. SO why should we
place ANY **ARTIFICIAL** meaning to them ? AND why are we using them
at all ?
- It is also worthy to note that in the course of a week or two since
this minimum number was first proposed it has changed from a
requirement of 3 votes to 20 votes. What will the number be next month
? Six months from now ?
The minimum of three votes is clearly flawed if you look at the pkgstats
usage and compare the number of votes. In fact, I linked to another
plot which clearly shows this. The number 20 was a guideline that was
around when I first joined as a TU and if you look at the pkgstats
results and try separating packages with more or less that 1% usage, the
optimal number of votes arrives very near to 20 so I stuck with it.
Why should any TU even want to contribute new and interesting BINARIES
when the number can change so quickly and by a small number of
"leaders" deciding for him/her ? Why should ANY TU spend time
*properly* vetting an AUR contribution through adoption only to have
it removed at a future date because it no longer had the require
number of votes ?
As I said in the wiki page, I was not proposing the enforcement of any
removal based on these numbers. I only proposed guidelines for getting
a package into the [community] repo.
FURTHER; when have we EVER let a small number of TUs make any
decisions for the rest of the TUs ? IS it wise to change the
successful TU system into merely a training ground for future DEVs and
all of the TUs merely "junior" DEVs grinding out packages because they
receive votes ? Where is the creativity in that ?
We have never let a small number of TUs decide. In fact, any change are
always required to reach quorum and a percentage of the vote as given in
the bylaws.
- Finally, but far from the least important consideration, is that we
are being asked to do this because of a lack of server resources. I
would like to remind everyone that this proposal will only delay the
day until this minimum number of votes is increased OR the servers
will need to be upgraded. I for one would rather like to contribute
some real hard cash and simply do the necessary infrastructure
upgrades and NOT set such a precedence of paradigm changes in a very
successful system. Changes that will be hard or virtually impossible
to remove once they are adopted, more especially because they will NOT
solve a resources problem for any useful length of time. Can ANYONE
truthfully assert that these changes will alleviate ANY resource
problems for any real length of time ? The only correct answer is no.
And so the folks presenting the TUs with this decision have said as
much in prior emails.
Resources are limited, no matter how much money you throw at a problem.
Every extra package uses bandwidth and disk space for both us and our
mirrors. And if you are only building for i686, it costs x86_64 TUs
time to build these packages.
We are talking about optimizing the use of our resources. Out of the
~2400 unique IP who submitted their package statistics, 97 packages in
[community] are used by no-one. That cannot be optimal when plenty of
packages in unsupported are having usages between 1 and 5%.
****** Oh yeah, DO NOT FORGET that there are no alternative proposals
to remedy the server problems because they have NOT been outlined in
enough detail to determine if this is the best or even a good proposal
to alleviate these vaguely declared problems. ******** i.e. WHAT
problems, or WHAT nature, and WHY are they NOW a problem ?
It is an optimal use of limited resources issue. Find a way to convince
me (and others) that serving packages out that from all indications
no-one or very few people use is optimal.
Thanks for reading this far. I hope every TU really asks themselves
whether this has been truly well thought out or not. Ask the tough
questions. Seek an understanding of just how this will help and
whether it is truly of merit or merely the beginning of other changes
that will result in a paradigm shift in our VERY successful and truly
unique TU/AUR system.
Which is why we are having a meeting. So we can discuss the relative
merits/demerits of the proposal.
Very best regards;
Bob Finch
THE **FIRST* TU.
Who still top posts....
On Fri, Nov 28, 2008 at 8:15 PM, Allan McRae <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The first TU meeting in a long time (over a year!) is on at 9.00pm
GMT, Sunday 30 November. Afternoon US time, early Monday morning
for me... we will keep a log for those who can't make it then.
Anybody needing the TU channel key, send me an email.
I have made a page[1] with what will be the main discussion topic
and what I propose to improve the community repo. Feel free to
make additions to the page (and sign them so we can tell who wrote
what), especially the final proposal.
Talk to you all then.
Allan
[1]
http://wiki.archlinux.org/index.php/User:Allan/Community_Repo_and_Pkgstats
