[aur-general] Removing comments from AUR

Grigorios Bouzakis grbzks at gmail.com
Thu Jun 25 21:03:47 EDT 2009

On Fri, Jun 26, 2009 at 3:42 AM, Gergely Imreh<imrehg at gmail.com> wrote:
>> Since i started this, even by stupidly replying to another thread, i
>> might as well answer
>> to that.
>> My suggestion is not having comments in the AUR at all, comments arent useful to
>> the users. They are only useful to the maintainer.
> I would disagree... Sometimes it is good for maintaner-user feedback
> as well. E.g. one of my packages takes a long time to compile. It's a
> small package but one step looks as if it hung and stays there for
> about 10-15mins on my computer. I had one of the users place a comment
> that his compilation didn't work, it froze and he had to kill it after
> about 5 minutes. Told him to wait a bit longer and it worked.
> Sure it could be done in the BBS - but would be completely
> inefficient. Not many users for most of the packages so not many
> people know what's going on, and I'm not going to search through the
> forums every day to see if someone wrote about them... Now: comment
> placed, me notified, can act on it....

Scrap the bbs.
If he mailed you, wouldnt you have bothered to reply his email?
Or it needs to be done by a comment or not done at all?
You wouldnt have added it to the package notes because it wouldnt interest the
users? If you had, he wouldnt even have to email you.

> Or: someone makes a package. A TU or a more knowledgeable user points
> out some problems with it in comments so he can fix it. Other users
> see the comments and see the advice, one day when they will make
> packages they can take that advice that is now public, and not in
> someone's mailbox. Yeah, the Wiki is for such things, but how many
> little things are there that people don't Wiki up? Or how many time
> people still write on the mailing list while this and that does not
> work in a package when it should? Sure it "only" concerns the
> maintainer at that time but there are a much wider potential audience.

Again private email.
bbs & mailing list & IRC = last resort.

> Also, it can serve as a "call" for other users who are interested in
> that package (and probably set it to "notify")  to call for someone
> else to adopt a package.

mailing list, bbs, IRC

> And also, your assumption is 100% reliable dedicated knowledgeable
> maintainers. Which is obviously not the case...
mailing list, bbs, IRC

>> If there is no
>> maintainer, if a user feels
>> the need to comment with an updated/altered script then he should
>> adopt it and fix it.
>> And even disown it afterwards if he feels like it.
> Not everyone is the same. Not everyone wants to take that
> responsibility. Is forcing them the right way? I'd see more people
> giving up a package before adopting it. If they want to adopt they
> would do it under the current arrangement. Though the "email the list
> if one package is very outdated and the maintainer don't give a" is
> probably not that clear for everyone, might be better to advertise it
> a bit more, but that's a different issue.

Then dont. What is the purpose of adding an updated PKGBUILD as a comment?
An irresponsible way to update the package?

>> How's that for "KISS" ?
> I'd ask, if you have a website that supposed to be automated and self
> contained, how is it KISS to require people +1 registration to BBS, +1
> registration to mailing list, +possibly much longer waiting to contact
> someone who can know the solution to the problem?
> Just thinking...
>   Greg

Those channels are already set up and working reliably. You just have
to use them properly.
Just like its done with the binary repositories. Do you mean the way
the official Arch works
is wrong? Its not KISS?
If you are not willing to get involved you shouldnt "maintain" AUR scripts.

PS. Please dont overexpand on the KISS issue. I just wrote that
because for some strange
reason it freequently gets mentioned as an aliby not to fix obvious problems.
Its totally irrelevant. KISS doesnt neither say that all pieces of
unseful information should be
gathered in one place and maintain a chaos.


More information about the aur-general mailing list