- Aur-general - lists.archlinux.org

[aur-general] Current TUs
by Aaron Griffin 01 Dec '08

01 Dec '08

Would someone mind telling me which people on this list are no longer TUs? This is the CVS passwd file... whoops http://dev.archlinux.org/~aaron/tu_names

8 16

Re: [aur-general] Proposed rules for packages entering [community]
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 11:54:20PM +1000, Allan McRae wrote: > Daenyth Blank wrote: > > On Sun, Nov 30, 2008 at 22:27, Allan McRae <allan(a)archlinux.org> wrote: > > > >> Hi all, > >> > >> As part of the TU meetings it was decided to post the proposal for > >> restricting packages entering [community] here for discussion before > >> voting. > >> > > > > My primary issue with the current proposal is that I feel 10 votes is > > slightly high for a first step. I'd *much* rather see 3-5 as a > > minimum, and I think others would as well. > > > > 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. How does that achieve a net result of nothing? If these rules were already in place it could have meant a net result of more than 500 less packages in community that we need to deal with.

2 1

Re: [aur-general] Proposed rules for packages entering [community]
by Daenyth Blank 01 Dec '08

01 Dec '08

> 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. > Allan > I didn't realize that was the case. I retract my point then.

1 0

Re: [aur-general] TU Meeting
by Daenyth Blank 01 Dec '08

01 Dec '08

On Mon, Dec 1, 2008 at 08:23, Daenyth Blank <daenyth(a)gmail.com> wrote: >> - It was proposed to add a safe flag on TUs packages in the AUR to encourage >> TUs to leave packages out of community while still being marked in a way as >> they are known to be good PKGBUILDs > > I missed this part... luckily. Safe flags were happily killed with a > few months ago. If you mean to add them to [community] packages only, > then it doesn't make sense to me: to make a TU you don't just need the > User, you also need the Trust. Either you don't T the U from the > beginning (and s/he doesn't get elected) or you T, and then you don't > need to flag anything. If someone notices an anomaly in a TU's > PKGBUILD quality, it should readily be reported to the list to take > action. The idea was that some people were putting packages in community which didn't need to be there, for the reason that having it in community assures that it's safe. If it were brought back, it would be for the purpose of encouraging TUs to use unsupported for packages that don't belong in community, while still allowing users to see *at a glance* if the package was made by a TU or not. Maybe code can explain better... on_upload { [...do stuff...] flag_unsafe $package if $uploader.is_a_tu then flag_safe $package }

1 0

[aur-general] TU Meeting
by Allan McRae 01 Dec '08

01 Dec '08

Hi TU's, I would like to organize a TU meeting on IRC to discuss the results of the pkgstats script and the direction for the [community] repo. I am probably the person with the worst time zone issues so I am happy to take a very late night time slot. I guess a weekend would be best to deal with the multiple time zones. So how are peoples availabilities (provide times/timezones): 15/16 November 22/23 November 29/30 November It would be good if someone (who isn't me...) sets up a temporary wiki page to handle this. Allan

15 37

Re: [aur-general] community back-end rewrite
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 11:35:18AM +1000, Allan McRae wrote: > Hi all, > > In the TU meetings there was some discussion about doing a > rewrite/update/fix-up of the [community] back-end. I am not sure who all is > looking at this and what the plans are - hence this email. > > Can people who are looking at this or interested in looking at this give a > ping back to this message with whatever plans you have or work you have > already done. > > Things I want to flag: > - we should get a git repo for a community-backend project on the arch > server and separate this from the aur site code. - we should switch SCM > tools from CVS. I am strongly in favour of using the same system as the > main repos which would allow much code reuse and easily get us a testing > repo for community packages. (No more big rebuild issues!). I'm involved with AUR development and have recently studied and begin to understand the tupkg code. Some improvements based on that activity will be put into action soon. I'll continue to help maintain AUR until I feel it has reached a certain point of efficiency and effectiveness where it no longer needs major maintenance. My plan from there is to start design and development on a new system that can be used for repo maintenance in AUR as well as any other package repo project, like arch-games, or even maybe official repos. These were actually some of my main goals in becoming a TU. I don't there is any benefit from putting tupkg code in a different repo than the AUR web interface. They are tied together by the DB and separating them may cause disjointed development and other problems. However we could organise the source tree and document how the system works a little better. Cheers!

1 0

Re: [aur-general] Proposed rules for packages entering [community]
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 01:27:33PM +1000, Allan McRae wrote: > Hi all, > > As part of the TU meetings it was decided to post the proposal for > restricting packages entering [community] here for discussion before voting. > Here is the current wording: > > [proposal] > > * Only "popular" packages may enter the repo, as defined by 1% usage from > pkgstats or 10 votes on the AUR. > > * Automatic exceptions to this rule are: > - i18n packages > - accessibility packages > - drivers > - dependencies, including makedeps and optdeps > - packages that are part of a collection and are intended to be distributed > together, provided the primary part of this collection satisfies the > definition of popular > > * Any additions not covered by the above criteria must first be proposed on > the aur-general mailing list, explaining the reason for the exemption (e.g. > renamed package, new package) at which point a general consensus from the > TUs will be reached. TUs with large numbers of "non-popular" packages are > more likely to be rejected. > > * TUs are strongly encouraged to move packages they currently maintain from > [community] if they have low usage. No enforcement will be made, although > resigning TUs packages may be filtered before adoption can occur. > > [end proposal] Thank you for taking the initiative to put this forward Allan. I really think we've had enough discussion about this topic. Nevertheless the motion requires a set discussion period and voting period. How about five days discussion, and five days voting? Cheers!

2 1

[aur-general] mailing list archives not showing up
by Abhishek Dasgupta 30 Nov '08

30 Nov '08

The mailing list archives at http://archlinux.org/pipermail/* are returning a 404. -- Abhishek

2 1

[aur-general] My thoughts on the [Community] policy discussion
by Drew Frank 30 Nov '08

30 Nov '08

Hi all, First off, I'd like to introduce myself so you can weigh my observations appropriately. My name is Drew. I'm a casual Arch user, and until recently my only experience with the AUR was using yaourt to download and install packages (and pacman to install from [Community], but I didn't really understand what that meant). Recently I've been following the discussion on this list regarding how to determine which packages belong in [Community]. Despite my lack of Arch/AUR mastery, I'd like to offer my two cents. I claim: 1. If it were possible to know with certainty that a given package were not in use by anybody (or only by a very small number of people), there would be overwhelming agreement that the package does not belong in [Community]. 2. Both vote counts and pkgstats statistics, as they are currently generated, are flawed metrics of package popularity. 3. Nearly all of the controversy over various [Community] admission policies stems from the fact that different people place different levels of trust in the information provided by votes and pkgstats. I feel like I'm a bit late to the party, but unless there is a critical need to act now my recommendation would be to first set up a system whereby accurate usage statistics are obtained and then proceed to develop policy based on accurate, interpretable statistics. Drew

2 2

[aur-general] huge differencies between i686 and x86_64 community repo
by Jaroslav Lichtblau 30 Nov '08

30 Nov '08

Hi fellow TUs! A quick look on the nice page showing differencies between our i686 and x86_64 repos [1], shows a pretty impresive list in our [community] repository. Could we please work on this a bit and keep it synchronised! IMHO even if some of us don't have access to both architectures, we can talk to someone who does and builds it for us. Have a nice day Jaroslav [1] http://www.archlinux.de/?page=ArchitectureDifferences -- Die Liebe ist der einzige Weg, auf dem selbst die Dummen zu einer gewissen Größe gelangen. -- Honoré de Balzac

4 3