[aur-general] Proposed rules for packages entering [community]

[Firmicus]

Allan McRae a écrit :
> Firmicus wrote:
>>
>> I basically agree that we need some form of control.
>>
>> However I have some reservations and comments.
>>
>> First, I would like to understand the usefulness of discussing and 
>> voting on this proposal first, before tackling the (IMO probably more 
>> serious issue) of having too many packages with very low popularity / 
>> usefulness in our community repo. Perhaps the former issue is easier 
>> to deal with? Or could serve as a basis for dealing with the latter one?
>>
>
> Paving the way...  Basically stop the problem getting any worse 
> first.  Then do the real fixing.  This is probably also the least 
> controversial of the two.
>

OK. Still, cleaning our repo should remain a relatively short-term priority.

>> Now to the specific points of the proposal:
>>> * Only "popular" packages may enter the repo, as defined by 1% usage 
>>> from pkgstats or 10 votes on the AUR.
>>
>> Allan, can you develop a bit more what is your criterion for the 
>> figures 1% or 10 votes. Why not 5% or 3 votes? (which in my humble 
>> opinion would seem to make more sense...)
>>
>
> I just liked the minimum of 1% for community.  Ten votes comes from 
> looking at the number of votes best at discriminating packages  with 
> more or less than 1% of usage.  In fact any number between 10 and 20 
> does quite well but people told me 20 was really too many...

Thinking about it again I agree. I mistakenly took these figures to be 
relevant to the question of removing packages currently in community 
(which may have less votes if they were not in unsupported before).

By the way, in order to preach by example I just moved 54 of my perl 
packages from community to unsupported. They all had low usage and were 
not dependencies. I had to keep some others with few votes because they 
are needed by pkgs maintained by sergej ;)

To make the cleanup operation easier I wrote this little script:

#--------------------------------------------------------------------------------------
#!/bin/bash
#
# Usage: community2unsupported <pkgname> (in the parent directory of the 
pkg in your cvs tree)
# For instance for pkg foo in category system,
#     cd to $CVSCOMMUNITY/system and run the script with argument foo.
# Requires package aurup from AUR
# !!! USE THIS CAREFULLY !!!

if [ ! -d $1 ]; then
    echo "dir $1 not found!"
    exit 1
fi

extrafiles=`source $1/PKGBUILD && for p in ${source[@]}; do echo $p | 
sed '/:\/\//d' ; done`

echo "Creating a tarball backup of package $1"
tar cf $1.tar $1/PKGBUILD
test -f *.install && tar rf $1.tar $1/*.install
for x in $extrafiles; do
    tar rf $1.tar $1/$x
done
gzip $1.tar

echo "Removing $1 from community"
cd $1 || exit 1
cvs tag -dl CURRENT PKGBUILD || exit 1
cvs tag -dl CURRENT-64 PKGBUILD || exit 1
cvs rm -fl || exit 1
cvs commit || exit 1

cd ..
echo "Uploading $1 to AUR/unsupported"
category=$(basename `pwd`) || exit 1
aurup $1.tar.gz $category

echo "---Done---"
#--------------------------------------------------------------------------------------


>
>>> * 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. 
>>
>> What should a "general consensus" look like? If 5 TUs are for and 3 
>> are against and the remaining ones do not reply, do we say yes or no? 
>> Can we be more specific on the above point without burdening the 
>> procedure with bureaucratic rules?
>>
>
> That is the main thing that needs defined before I call for a vote.  I 
> really want others ideas on this.  Perhaps agreement of 3 other TUs.

Yes, that seems reasonable.

F