You are not logged in.
Attention Users:
The Trusted Users (TUs) have recently been overhauled, to add a number of people to the group who will provide packages based on community need.
That said, we need you guys to do more voting in the AUR. Seeing as a TU may revamp a PKGBUILD once they take it over, you should not be voting on the quality of the PKGBUILD in the AUR, but the application itself.
In addition, when building packages this way, it is hard to keep up with releases of the application itself. It would be appretiated if you can flag packages out of date if dound to be so.
Tonight I will be building the following for the community repo:
· gnomebaker
· easytag
· acidrip
· leafpad
As other applications gain popularity, I will attempt to build them as well.
Thank You,
phrakture
Offline
I'll also add that, shock horror, there are actually somethings you REALLY should read before you submit your PKGBUILDs to the AUR. I am currently trying to update them but they include:
· The AUR guidelines
· The Arch package making HOW-TO
· How to Build Packages and Guidelines
The updated versions are under way here
Offline
Update: The New AUR Guidelines.
· The AUR User Guidelines
· The AUR TU Guidelines
· Arch Packaging Guidelines
Offline
Attention Users:
It would be appretiated if you can flag packages out of date if dound to be so.
Yes, and I also think it hurts package XYZ votes when the AUR version falls significantly behind the current release. A good example of this would be KlamAV-AUR. It is a popular application on many desktops but would probably fare much better in vote recognition if there were regular updates. My point being I suppose that the accounted popularity of an AUR application IMO often has a lot to do with how well it is maintained, and I would hate to see some deserving projects get left behind just because they have been abandoned and fallen off the radar.
I've also seen alot of packages with only a few votes get into community. I'm not saying this is necessarily bad, but if one of the issues being addressed in this thread is that voting *really* matters, then that should be consistently demonstrated in what is selected for inclusion in Community. I would say that to date that criteria is being met on a sporadic basis. But to be clear, thanks for certain go to the TUR's for the work that they do in sponsoring the many packages which do get selected for Community.
/path/to/Truth
Offline
Yes, and I also think it hurts package XYZ votes when the AUR version falls significantly behind the current release. A good example of this would be KlamAV-AUR. It is a popular application on many desktops but would probably fare much better in vote recognition if there were regular updates.
A very good point - thanks. Obviously, it is up to each maintainer to look after their own packages, but if a package is significantly out of date like this, and reasonable efforts have been made to contact the maintainer, then the package can be orphaned by a TU on request, for adoption by whoever's interested.
I've also seen alot of packages with only a few votes get into community. I'm not saying this is necessarily bad, but if one of the issues being addressed in this thread is that voting *really* matters, then that should be consistently demonstrated in what is selected for inclusion in Community.
The original reason for this thread, over a year ago, was indeed to stress that voting matters, and that has not changed. However, it was never the only factor influencing Community promotions, as TUs have always had the option to promote any package. The User and TU Guidelines have now been updated to clarify that, which is why the thread has been resurrected.
But to be clear, thanks for certain go to the TUR's for the work that they do in sponsoring the many packages which do get selected for Community.
You're more than welcome. Speaking for myself, it's a pleasure, and I would also say thanks to all AUR users and contributors for making it the success that it is.
Offline
McQueen wrote:Yes, and I also think it hurts package XYZ votes when the AUR version falls significantly behind the current release. A good example of this would be KlamAV-AUR. It is a popular application on many desktops but would probably fare much better in vote recognition if there were regular updates.
A very good point - thanks. Obviously, it is up to each maintainer to look after their own packages, but if a package is significantly out of date like this, and reasonable efforts have been made to contact the maintainer, then the package can be orphaned by a TU on request, for adoption by whoever's interested.
And as phrakture said, that a PKGBUILD is out of date shouldn't affect the voting as once it will be adopted by a TU , it will be updated/fixed. I do understand that an up-to-date package will appear more often in the RSS feed so it'll get more exposure and possibly more votes.
McQueen wrote:I've also seen alot of packages with only a few votes get into community. I'm not saying this is necessarily bad, but if one of the issues being addressed in this thread is that voting *really* matters, then that should be consistently demonstrated in what is selected for inclusion in Community.
The original reason for this thread, over a year ago, was indeed to stress that voting matters, and that has not changed. However, it was never the only factor influencing Community promotions, as TUs have always had the option to promote any package. The User and TU Guidelines have now been updated to clarify that, which is why the thread has been resurrected.
To be precise, the thread has been resurrected because of a forum reorganization and Dibble's thread linked to the old guidelines and 404 web pages.
For users not suscribed to the TUR ML, there was a discussion about the inclusion process of packages in the community repo. Here's the main points:
1. As tomk said, the guidelines have been changed to reflect more closely what the 25 votes threshold meant for the TU.
2. It was found out that the TU make a pretty good job in putting popular packages in community. Most packages with 25+ votes still in unsupported are there for good reasons. The most common reason is licence restriction.
3. Sometime this week, I will setup a wiki page that will list the popular packages that are possible candidate for inclusion in community. There will also be a list of the popular packages that will remain in unsupported and the reason for that will be given. Hopefully, it will help the TU in promoting popular packages in the community repo and will explain to users why some popular packages remains in unsupported.
Offline
Hello,
in the The Arch package making HOW-TO it is mentioned, that a package ought to be usable as a (nonpriviliged, i guess) user. This issue seems to be dropped in the newer versions. Has this be done by accident or was it a distinct decision?
I think that creating and testing of PKGBUILDs should be done as a nonpriviliged user, it would be to dangerous and could harm the packages' integrity.
Offline