[aur-general] TU Meeting

[w9ya]

A few points of rebuttal. Mostly too many unanswered questions.

I will outline these below, but for those of you that are becoming tired of
all this back and forth I can say this much:

1 - There are way too many unanswered questions about the methodology that
basis for why we are being asked to consider voting on this.

2 - At NO POINT have these questions, although asked, been answered
directly. Taken as a whole when answers are given they are mostly indirect
at best. I am begining to believe that this is because those making these
proposals do NOT have any these answers.

3 - Instead we are spending time go back and forth over the same material.
This is stupid IMHO.

4 - There is absolutely no reason for this back and forth on simple
questions like "show us your math. Please explain your assumptions. (Both
basic methodology questions.) Why are we being asked to do this now ? Can
you be more specific ?

5 - Since it has been declared that these are the first of many changes to
improve our resource utilization, what else is being planned or considered ?

6 - Numbers are being thrown around which have NO basis unless compared
against one another. But with possibly over 36,000 users of archlinux, maybe
MANY more; How can a programs like "google-earth" only be getting 400 votes
? How can this possibly be based on the the number of users ? There are
other such examples. NO ONE has explains what numbers like "3" and "20"
votes can represent ? If numbers like "3 votes" can mean either 3 users or
350 users; How can we be throwing around any **real** meaning from ANY
number such as "20 votes"  ?

7 - I have not updated "google-earth" since WAY BEFORE the pkgstats were
made available. How is it not premature to be using statistics generated by
it on such programs ? i.e. Can those asking us to use these numbers properly
"vet" them ? Can they explain how one month or even 4 moths is sufficient
time to understand the output of programs like "pkgstats" ?

8 - If we have so many unanswered yet basic questions; Why is it so
important to use them to "make changes" ?

9 - Voting can be faked. How is this being dealt with ?

10 - If we DO make these changes, we will be changing the system from one of
TU discretion and creativity to where the AUR users decide the work load and
output of a TU. The devs and the aur voters will be deciding what the TUs
do. The devs will be able to make decisions, as they do now, as to what is
included in their work without restrictions, and the AUR submitters will be
deciding on their own what to submit. BUT the TUs will be UNIQUELY
restricted however. How do the people proposing this plan to enlarge the TU
pool when this position will have the least amount of creativity and
discretion of those available ?

11 - Will we have less rather than more people wanting to become TUs because
this will become the least creative endeavor for someone wanting to
contribute ?

12 - If the TU pool becomes BOTH smaller and LESS creative, will this pool
of potential devs represent less well trained candidates ?

I could go on and on, because in the proceeding weeks, those answering these
basic questions have not taken sufficient priority with them. Instead I am
asked questions that seem specious to me in reply. This really is
counterproductive.

*** So here is the most basic question;

Why should we be seriously considering ANY recommendation, when those who
have been asked these and other questions have spent so little time and
effort SIMPLY answering them ? The charts seem poorly thought out, and no
where have the authors of such stuff given us the specifics of how they were
made. SORRY, but this is just a waste of time if there is not full
disclosure.

And finally; I am asked below what were the reasons such previous proposals
were either dismissed or voted down by the TUs. Here are some reasons. They
are NOT all the reasons, and in fact many would consider these not as
important as other reasons. Nonetheless here are some;

1 - No one wanted systems where the TUs had less discretion than a DEV or a
AUR contributor. It was too much like being a "slave" to your work, and
"work assigned by someone else". It was (IMHO CORRECTLY) felt that this was
too much of an burden to load unto the TUs as a whole. Not all, but MANY TUs
did not want this change from the fundamental system we had.

2 - We did NOT want to remove any creative decision making from the TUs.
Some were packaging stuff that was truly unique and useful to
sub-communities that do NOT vote but DO download these packages. We felt it
ws short sided and unwise to elliminate this creativity.

3 - We could NOT predict what these changes would do to our current system,
and the TUs were happy with the way things were.

4 - We were, frankly, scared that this very unique TU system (which is one
of the three basic reasons Archlinux is unique in the world of linux
distribtuions,) would morph into just another distribution, with nothing
much unique to prove or account for it's existance.

5 - TUs then and now are the ones that WANT to contribute. We were scared
that many TUs would, over a short time period, choose to leave after voting
in such changes, AND the ones that remained would have a larger burden and
be less motivated to stay with the program.

6 - TUs felt it was inappropriate to decide anything other than on the
ability and safety of another TUs output. It was felt that things would
become too much like a "popularity contest" and too little like a group of
kind, polite, and most importantly diverse group working together instead of
at odds. It was felt that being inclusive was exceptionally important. We
wanted no contention.

Bob F.


On Sat, Nov 29, 2008 at 2:36 AM, Allan McRae <allan at archlinux.org> wrote:

> 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 <allan at archlinux.org<mailto:
>> allan at archlinux.org>> 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
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/aur-general/attachments/20081129/b97b0cad/attachment.htm>