TUs, AUR, and voting

dtw · 2005-06-04 07:45:06

So do it but there is not enough usage and kind of practical results yet - we gotta get more people putting more into it on both ends to really see how it pans out

cactus · 2005-06-04 08:36:01

I keep hearing the pink floyd song echo in my head..
"Welcome my son, welcome to the machine.."

Dusty · 2005-06-04 15:12:50

cactus wrote:

I keep hearing the pink floyd song echo in my head..
"Welcome my son, welcome to the machine.."

you know cactus, sometimes I think you post totally, or almost totally irrelevant information to this forum just to keep your post count above mine...

cactus · 2005-06-04 17:53:38

then have one of the forum mods wipe my post count in the database. I could care less how many posts it says I have. I don't measure my existence by how high I am in the "post count rankings".

Dusty · 2005-06-04 17:59:46

cactus wrote:

then have one of the forum mods wipe my post count in the database. I could care less how many posts it says I have. I don't measure my existence by how high I am in the "post count rankings".

No, I don't suppose a dancing sandwhich would care...

I'm a little odd today, too much freedom... weekend and all, you know...

dtw · 2005-06-05 07:23:34

i'm not much for pink floyd cactus - you'll have to explain that one to me

bardo · 2005-06-05 10:50:06

cactus wrote:

I keep hearing the pink floyd song echo in my head..
"Welcome my son, welcome to the machine.."

OMG cactus... that's what I'm listening to right now

elasticdog · 2005-06-06 04:36:51

As a newcomer to Arch, I agree that there is quite a bit of confusion into how the whole AUR system is supposed to work...how software moves between all of the repositories/sections, really. To me it would make more sense to move packages up the ladder based on thier quality/stability of the build rather than strictly a popularity vote and whether or not a TU has enough time to maintain it.

I can understand the idea behind the TUs, but it does put a lot of burden on a small number of people. It would be nice if a user created a package that was somehow deemed "high-quality", that they could continue to maintain that package as it was moved progressively through the repositories, thus alleviating some of the burden on the TUs. If the person wasn't able to improve upon a popular package due to lack of skills, perhaps then a TU could step in at that point and take over the maintenance. Or, once in the community repository, a TU wouldn't neccessarily have to handle maintenance, but at least sign off on the work of the original maintainer before the update went live.

The voting on the AUR packages is a good idea, but seems to be inconsistent in implementation as many people are using it as a sign of quality rather than an indication of demand.

Under the AUR guidelines page, it reads "all packages start inside the AUR, and as developers consider them crucial to the distribution, they will be adopted into EXTRA/CURRENT." I was wondering how exactly is "crucial" defined? Why not add all packages that have reached a certain level of quality, possibly measured by a vote from the TUs or something of that nature, into the EXTRA repository?

Well, it's late and the thoughts in my head aren't really coming out intelligibly, so I'll leave it at that. Perhaps I'm way out there and missing something completely, but these were my initial thoughts into the matter which clearly could use some ironing out.

xerxes2 · 2005-06-06 09:21:14

you can't let anyone have access to community repo, the whole point with the tu system is that those persons have been around for a long time and have been voted trusted,

if anyone can use community repo then we'll be in big trouble, it will only be used by stupid people trying to crack boxes and such things,

i think the current system is almost perfect,

phrakture · 2005-06-06 14:43:49

elasticdog brings up some good points, but let me expand a bit on what he calls "high-quality" packages.

I think it's a good idea to have some way to mark a package "high quality", and once this is done, perhaps allowing the user to upload a binary package, to be tested by TUs and then moved to community. Of course this would slow updates to these package down, but it would allow users to uplaod binaries as well.

Right now my biggest problem with the AUR is the huge gap from PKGBUILD to binary. I get tired of building software from source, and if I wanted to do that with every package, I would switch to gentoo, or freebsd (*jab*).

Right now, there needs to be some way for binaries to be provided as well. IMHO this is where the personal repositories come in...

medicated · 2005-06-06 15:09:29

I agree that its a pain to compile from sources everytime I need a package from AUR, but whats the sollution to this? I'd still much rather compile from source on a package thats not "approved" as high quality. I'm just a little more comfortable when I can look at a filelist. I know I could open up the package and look at it..but still. I think its a important to stay at a PKGBUILD. Thats just my opinion though.

Dusty · 2005-06-06 15:38:35

I don't understand why having more TUs and/or package maintainers -- enough to maintain the popular packages wouldn't solve this problem for everybody. There would be less workload for each TU, more packages in the community and official repos, etc. I don't mind compiling from source on occasion when i'm using a program that only one or two other people use.

I don't know if this is still the case, but when we were discussing the original idea behind AUR, the voting mechanism was supposed to be entirely popularity. If a package was in what is now called unsupported, and somebody wanted it in a repo, they would vote for it; plain and simple. Quality doesn't enter into the equation at this stage. It is, in fact, up to the TU to ensure quality. This is why we 'trust' them! A low quality PKGBUILD can always be rewritten by a TU if enough people want a copy of that package.

The problem right now appears to be that there are too many popular packages in unsupported. Obviously, these should be in a repo -- why not community? If community, why not an official TU? If there aren't enough TUs to manage all the packages... well more TUs, its simple!

Perhaps a document describing AUR in more detail, from the user's point of view, is in order...

Dusty

phrakture · 2005-06-06 15:43:35

Dusty wrote:

The problem right now appears to be that there are too many popular packages in unsupported. Obviously, these should be in a repo -- why not community? If community, why not an official TU? If there aren't enough TUs to manage all the packages... well more TUs, its simple!

Exactly, but I don't thing more TUs will solve anything. Alot of the TUs seem to maintain binary versions of packages they like while ignoring the more popular packages.... if this is the trend, I think we need to have a title added in addition - maybe "Community Users" which will simply maintain only the popular AUR packages

medicated · 2005-06-06 15:47:43

Weelll..it seems obvious to me that we need more TU's but whoo?? Our community is going to grow and as it does, our TU numbers will grow as well. It just seems like Arch is suffering from some growing pains. Hopefully this is just something that will work itself out. Maybe in the near future, but not likely.

Dusty · 2005-06-06 16:53:23

phrakture wrote:

Alot of the TUs seem to maintain binary versions of packages they like while ignoring the more popular packages.... if this is the trend, I think we need to have a title added in addition - maybe "Community Users" which will simply maintain only the popular AUR packages

Firstly, there aren't a lot of people out there who volunteer to maintain packages just because they are popular... that's no fun. No matter what the group is called. ;-) Secondly, it would make a lot more sense to me to change the mindset of the TUs to focus on popularity, rather than their own interest (if this is, indeed, the problem) than to have yet another group of packagers!

It is volunteer work, and people who volunteer are generally going to maintain packages they are interested in. This should work anyway, with no rules, if there are enough TUs, because, by definition, a popular package is one that a lot of people are interested in using. TUs are people, so it is quite likely that if the pool of TUs is wide enough, they will tend to be interested in packages that are also popular.

Further, a lot of the original TUs don't seem to have stepped into the AUR yet. This is a transition phase and I think its going to work itself out. I suspect some TUs have just stopped maintaining packages and there are a lot fewer of them active than it seems. Therefore, more TUs might solve the problem.

One thing I don't get is Phrakture and i3839, specifically, but also others suggesting that there should be another group of users maintaining packages, and even volunteering to coordinate such a group. It would make more sense to me if you volunteered to be TUs yourselves, and took on some of the packages you are interested in maintaining. I would think that would be less work than coordinating yet another community of users...

I personally don't know much about what TUs do, having never been a TU and never been on their mailing list. But before running off and trying to replace them, I'd be trying to join their discussion and find out what they really do.... and possibly influence their direction to be more user oriented. Originally TUs were meant to be members of the community, and yet... how many of them are still active on this community forum? They've been alienated. More community memebers should be TUs.

Dusty

phrakture · 2005-06-06 17:20:09

Dusty wrote:

One thing I don't get is Phrakture and i3839, specifically, but also others suggesting that there should be another group of users maintaining packages, and even volunteering to coordinate such a group. It would make more sense to me if you volunteered to be TUs yourselves, and took on some of the packages you are interested in maintaining. I would think that would be less work than coordinating yet another community of users...

I've thought about it, but the thing is, I doubt I'd be able to keep up...
I could easilly package things from work over ssh (it takes no time to do it), however, I couldn't test most things, as most of the popular apps require X...
So I'd have to wait when I got home at got a chance to do testing of packages and things like that....

Let me put some thought into it, and look at the aur popularity, to see how feasible it would be...

Another thing is, there isn't alot of TUs around that much, so getting the "go ahead" from 2 TUs may be difficult.

Snowman · 2005-06-06 19:51:33

phrakture wrote:

Another thing is, there isn't alot of TUs around that much, so getting the "go ahead" from 2 TUs may be difficult.

Actually, you need a sponsor plus four votes from other TUs. It seems quite difficult to get this total of votes. For example, Dibble is still missing 1 or 2 votes to become a TU after applying on the mailinglist several weeks ago.

Dusty · 2005-06-06 20:10:02

Perhaps the TUs don't think Dibble has proven himself... 8-)

Dusty

i3839 · 2005-06-06 20:35:45

I'll try to clarify what I want. I don't want to replace the TU system, nor do I want to create a new group of users, all I want is that packages made by Arch users can be easily and safely used by other Arch users, that's all. And here the goal is to have almost all packages in a repo, not only the popular ones. Maybe the TUs can do it, maybe not, we'll see, but with the speed new TUs are accepted or rejected it may take quite a long time...

I don't know why I'm not a TU. Perhaps because no one asked me to become one, because I never make my own packages as almost all I need is in base or extra already, perhaps because my hd is too small and my pc used to be quite slow. Or I don't want to make other people's packages, but instead would prefer to help them making their own, who knows.

cactus · 2005-06-06 20:36:50

It seems that a TUR "vote" on a new user is never actually held. It just seems that votes trickle in, or not. A potential applicant could languish in an unknown state for an indeterminant amount of time. Current TURs could not vote, or not even pay attention to the voting.

It would seem preferable to have the TURs required to vote once a month (or once every two months..whatever) on new applicants, in some private meeting place somewhere. Then applicants aren't drug along for time unending, and things actually get done as far as voting goes. Maybe even make it a requirement of being a TUR to make a monthly meeting of some type..doesn't seem like too much of a hardship. Make allowances for unforseen leaves of absence, etc, of course.

In summary, if you are not going to vote someone in, then at least give them the courtesy of a timely "no" response--either collectively via a TUR spokesman, or individually..however it is decided to be done.

elasticdog · 2005-06-07 03:49:20

i3839: "...all I want is that packages made by Arch users can be easily and safely used by other Arch users, that's all. And here the goal is to have almost all pacakges in a repo, not only the popular ones."

Agreed 100%

dtw · 2005-06-07 11:44:08

I entirely agree with Dusty's points and concerns, except this bit of course:

Dusty wrote:

Perhaps the TUs don't think Dibble has proven himself... 8-)
Dusty

The things Dusty has mentioned about redundant TUs, what Phrakture has said about which pkgs are being added, and what cactus has mentioned several times regrading vote limits and a timely TU selection process have now all been raised on the mailing list.

If you really do care about the AUR you really should be adding to the noise that a very small number of us are already trying to make about the system - join the mailing list and let everyone know what you think - the devs are too busy to come here and find them for themselves. Please. Thanks.

I would also add that you should catch up on the details of the relevant thread before you post or you will just annoy them. My TU application thread contains most of it. This is not blatent self-promotion either - it's just i was stupid enough to raise these issues in my own application thread + people keep hijacking it!

See also cvsup and the AUR re: PKGBUILD to binary systems, which is on the normal arch list

i3839 · 2005-06-07 12:48:54

dibblethewrecker wrote:

If you really do care about the AUR you really should be adding to the noise that a very small number of us are already trying to make about the system - join the mailing list and let everyone know what you think - the devs are too busy to come here and find them for themselves. Please. Thanks.

I read both threads and both seem to try to solve the problems the wrong way, IMHO. But as I said before, currently I've no time, so I'll see how it worked out after a month or so and then take some action, if still needed.

I'm not going to tell nor do I care how the TUs should manage themselves, I'm looking at the whole matter from the normal user's point of view. I've no interest in TU business, as I said before I don't think that using a construction where a small group of trusted users do all the work will be a good solution in the long term, but I may be wrong. I care about AUR, not the TU system, and see the two things seperate.

Edit: Or in other words, TUs basically say "let us do all the work", then why should I tell them how to do it? If they want to do it all then it's their problem how they do it. And only way to help them when they can't manage to do the job well enough is to also become a TU... Or to try to solve the thing another way. But I don't have the illusion that they'll listen to any advice from some non-TU outside smartass. Accepting/rejecting new TUs efficiently is such a small thing, it's just a slight hurdle to take, if they can't manage that then all hope is lost. TUs are called trusted users, but I for one don't even know who they are.

phrakture · 2005-06-07 14:11:44

elasticdog wrote:

i3839: "...all I want is that packages made by Arch users can be easily and safely used by other Arch users, that's all. And here the goal is to have almost all pacakges in a repo, not only the popular ones."
Agreed 100%

You know, this could all be solved with a simple (not so simple?) app that validated the safety of PKGBUILDs, install files, and binary packages.

It's not difficult, but the logic would be overwhelming. Maybe we could start there... for instance, validating a package would make sure it has no empty dirs, direcotry permissions do not differ from the existing file system, none of the files exist in the base system, and it passes namcap flawlessly.
Beyond that, validating an install file is harder and PKGBUILD harder still.

dtw · 2005-06-07 14:25:58

I care about AUR, not the TU system, and see the two things seperate.

Well, sorry, mate, but the TUs control the AUR and we don't. Seeing them seperately is not considering the situation holistically, which is actually where all the problems originally stem from IMHO

Arch Linux

#26 2005-06-04 07:45:06

Re: TUs, AUR, and voting

#27 2005-06-04 08:36:01

Re: TUs, AUR, and voting

#28 2005-06-04 15:12:50

Re: TUs, AUR, and voting

#29 2005-06-04 17:53:38

Re: TUs, AUR, and voting

#30 2005-06-04 17:59:46

Re: TUs, AUR, and voting

#31 2005-06-05 07:23:34

Re: TUs, AUR, and voting

#32 2005-06-05 10:50:06

Re: TUs, AUR, and voting

#33 2005-06-06 04:36:51

Re: TUs, AUR, and voting

#34 2005-06-06 09:21:14

Re: TUs, AUR, and voting

#35 2005-06-06 14:43:49

Re: TUs, AUR, and voting

#36 2005-06-06 15:09:29

Re: TUs, AUR, and voting

#37 2005-06-06 15:38:35

Re: TUs, AUR, and voting

#38 2005-06-06 15:43:35

Re: TUs, AUR, and voting

#39 2005-06-06 15:47:43

Re: TUs, AUR, and voting

#40 2005-06-06 16:53:23

Re: TUs, AUR, and voting

#41 2005-06-06 17:20:09

Re: TUs, AUR, and voting

#42 2005-06-06 19:51:33

Re: TUs, AUR, and voting

#43 2005-06-06 20:10:02

Re: TUs, AUR, and voting

#44 2005-06-06 20:35:45

Re: TUs, AUR, and voting

#45 2005-06-06 20:36:50

Re: TUs, AUR, and voting

#46 2005-06-07 03:49:20

Re: TUs, AUR, and voting

#47 2005-06-07 11:44:08

Re: TUs, AUR, and voting

#48 2005-06-07 12:48:54

Re: TUs, AUR, and voting

#49 2005-06-07 14:11:44

Re: TUs, AUR, and voting

#50 2005-06-07 14:25:58

Re: TUs, AUR, and voting

Board footer