Allan McRae wrote:

Loui Chang wrote:

...

I think the categories would be removed.

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

Categories should be removed as well as AUR entries for [community] packages. The former isn't all that useful in my opinion, and any comments/suggestions/bug reports would be better off placed in FS where we can track them more easily.

On Sat, Jan 24, 2009 at 06:42, Loui Chang wrote:

I think the categories would be removed.

I think categories are completely useless and should be removed from unsupported too. AFAIK, only [community] is really maintained as a tree. -- Geoffroy Carrier

On Sat, 24 Jan 2009 09:25:59 -0500 Loui Chang wrote:

On Sat, Jan 24, 2009 at 01:27:18PM +0100, Geoffroy Carrier wrote:

...

On Sat, Jan 24, 2009 at 06:42, Loui Chang wrote:

...

I think the categories would be removed.

I think categories are completely useless and should be removed from unsupported too. AFAIK, only [community] is really maintained as a tree.

I actually like categories. They really help quickly whittle down searches. The only problem is that a package can officially only be in one category, when actually it could easily fit into two or more.

what about tags instead of categories?

Categories wouldn't really have to be removed, but you'd have to set them manually like in unsupported.

On Sat, Jan 24, 2009 at 4:19 PM, Daenyth Blank wrote:

On Sat, Jan 24, 2009 at 00:59, Allan McRae wrote:

...

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

I'd like to keep them. Especially if we get smooth non-destructive transitions moving a package from community to unsupported.

So -1, keep the comments IMO.

Please remove the comments. I'd rather have everything in one place (bug tracker). People seem to abuse the comment section too much anyway by filing bugs there, it is really anoying so remove :D Ronald

On Sat, Jan 24, 2009 at 8:52 AM, Dieter Plaetinck wrote:

On Sat, 24 Jan 2009 09:25:59 -0500 Loui Chang wrote:

...

On Sat, Jan 24, 2009 at 01:27:18PM +0100, Geoffroy Carrier wrote:

...

On Sat, Jan 24, 2009 at 06:42, Loui Chang wrote:

...

I think the categories would be removed.

I think categories are completely useless and should be removed from unsupported too. AFAIK, only [community] is really maintained as a tree.

I actually like categories. They really help quickly whittle down searches. The only problem is that a package can officially only be in one category, when actually it could easily fit into two or more.

what about tags instead of categories?

Actually, this is proposed for pacman as well. I think it's a good idea. Let me explain how this is relevant: Right now our 'categories' are for organization. It's a holdover from CRUX, if I recall. When we moved the official repos over to svn, we did away with categories because they just don't make sense. Where do perl modules go? The category based on the task it does (i.e. network)? The modules category? The perl category? Kernel modules in the kernel category? Or modules? Ugh... too much confusion. The proposed category feature for pacman works more like arbitrary tagging. This perl module can have categories=(network modules perl). Problem solved. The initial intent was to aid in searching, too. pacman -Ss --category multimedia blah. We could use a similar system in the aur, but make it more free-form. I think it makes more sense, as the categories are SOLELY used for mental orgnaization.

On Sat, Jan 24, 2009 at 04:53:32PM +0100, Ronald van Haren wrote:

On Sat, Jan 24, 2009 at 4:19 PM, Daenyth Blank wrote:

...

On Sat, Jan 24, 2009 at 00:59, Allan McRae wrote:

...

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

I'd like to keep them. Especially if we get smooth non-destructive transitions moving a package from community to unsupported.

So -1, keep the comments IMO.

Please remove the comments. I'd rather have everything in one place (bug tracker). People seem to abuse the comment section too much anyway by filing bugs there, it is really anoying so remove :D

It seems the consensus is to remove community packages from the AUR interface altogether. Before we do that though we should do a general package clean up. Moving packages with extremely low votes/pkgstats usage into unsupported, so we're not importing garbage into the new system. What do you think?

On Mon, Jan 26, 2009 at 09:14:45PM -0500, Loui Chang wrote:

On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:

...

On Sat, Jan 24, 2009 at 00:59, Allan McRae wrote:

...

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

I'd like to keep them. Especially if we get smooth non-destructive transitions moving a package from community to unsupported.

Hmm it seems like all it takes to move a package from community to unsupported is to upload the tarball with buildscripts via the AUR interface (pkgsubmit.php). Votes and comments are preserved.

So if we're doing a clean up, we can disable tupkgupdate to be safe. tupkgupdate only runs a minute after the hour every hour. It shouldn't be a problem really.

Err you have to upload it to AUR, then untag and delete it from CVS. If you don't delete it, it will actually stay in the community repo, but won't show up in the AUR interface.

On Mon, Jan 26, 2009 at 10:20:10PM -0600, Aaron Griffin wrote:

On Mon, Jan 26, 2009 at 8:14 PM, Loui Chang wrote:

...

On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:

...

On Sat, Jan 24, 2009 at 00:59, Allan McRae wrote:

...

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

I'd like to keep them. Especially if we get smooth non-destructive transitions moving a package from community to unsupported.

Hmm it seems like all it takes to move a package from community to unsupported is to upload the tarball with buildscripts via the AUR interface (pkgsubmit.php). Votes and comments are preserved.

So if we're doing a clean up, we can disable tupkgupdate to be safe. tupkgupdate only runs a minute after the hour every hour. It shouldn't be a problem really.

So are you suggesting that all community packages will also exist in unsupported? If we're going to go that route, why not integrate the AUR with the abs tree - seems there'd be no need to upload anything that way, and there' be no file duplication.

Oh I'm just saying if we do a clean up before the transition that it's pretty easy to move a package to unsupported, and we won't lose any data for those packages transferred. Yeah the running policy is for no duplication.

On Mon, Jan 26, 2009 at 10:57:52PM -0600, Aaron Griffin wrote:

On Mon, Jan 26, 2009 at 10:51 PM, Loui Chang wrote:

...

On Mon, Jan 26, 2009 at 10:20:10PM -0600, Aaron Griffin wrote:

...

On Mon, Jan 26, 2009 at 8:14 PM, Loui Chang wrote:

...

On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:

...

On Sat, Jan 24, 2009 at 00:59, Allan McRae wrote:

...

Any other people want to comment on this? Any TUs feel keeping AUR pages for [community] packages is necessary?

Allan

I'd like to keep them. Especially if we get smooth non-destructive transitions moving a package from community to unsupported.

Hmm it seems like all it takes to move a package from community to unsupported is to upload the tarball with buildscripts via the AUR interface (pkgsubmit.php). Votes and comments are preserved.

So if we're doing a clean up, we can disable tupkgupdate to be safe. tupkgupdate only runs a minute after the hour every hour. It shouldn't be a problem really.

So are you suggesting that all community packages will also exist in unsupported? If we're going to go that route, why not integrate the AUR with the abs tree - seems there'd be no need to upload anything that way, and there' be no file duplication.

Oh I'm just saying if we do a clean up before the transition that it's pretty easy to move a package to unsupported, and we won't lose any data for those packages transferred.

Yeah the running policy is for no duplication.

Still... the idea of integrating the ABS tree brings up an interesting solution to everyone's issues. If you import or read the ABS tree into the AUR, we get all packages from all official repos, with comments and all that fun stuff. Not that the developers will pay much attention to it, but it'll sate the users who seem to want votes on official packages

I dont know how applicaple this is, it sounds very neat, and i guess it will intergrate my FR http://bugs.archlinux.org/task/12902 . Greg

On Mon, Jan 26, 2009 at 11:49 PM, Loui Chang wrote:

On Mon, Jan 26, 2009 at 10:57:52PM -0600, Aaron Griffin wrote:

...

Still... the idea of integrating the ABS tree brings up an interesting solution to everyone's issues. If you import or read the ABS tree into the AUR, we get all packages from all official repos, with comments and all that fun stuff. Not that the developers will pay much attention to it, but it'll sate the users who seem to want votes on official packages

Yeah that would be interesting. There's not much point for comments and votes in [core] because it already has a specific and well defined purpose, but I could see that being appreciated in [extra].

For the record, though, I'd put a big warning that says "the developers are most likely never ever going to check this, don't kid yourself. They have 10-20 other things to check already. Use on of them if it's important"

On Tue, Jan 27, 2009 at 3:20 AM, James Rayner wrote:

On Tue, Jan 27, 2009 at 4:55 PM, Aaron Griffin wrote:

...

On Mon, Jan 26, 2009 at 11:49 PM, Loui Chang wrote:

...

On Mon, Jan 26, 2009 at 10:57:52PM -0600, Aaron Griffin wrote:

...

Still... the idea of integrating the ABS tree brings up an interesting solution to everyone's issues. If you import or read the ABS tree into the AUR, we get all packages from all official repos, with comments and all that fun stuff. Not that the developers will pay much attention to it, but it'll sate the users who seem to want votes on official packages

Yeah that would be interesting. There's not much point for comments and votes in [core] because it already has a specific and well defined purpose, but I could see that being appreciated in [extra].

For the record, though, I'd put a big warning that says "the developers are most likely never ever going to check this, don't kid yourself. They have 10-20 other things to check already. Use on of them if it's important"

Could have fireworks, flying banners and presidential announcements, people will still comment.

If repo in ['core','community','extra'] then disable comments and place a link to the bugtracker and/or email?

+1 for disabling comments for repo packages. Even with warnings, we risk having users using the comments instead of the bug tracker to report bugs. We already have users abusing the flag out-of-date functionnality to report bugs. If devs are very unlikely to read those comments, why would we have them in the first place? If users want to discuss about a package among themselves, they already have plenty of ways to do it: forums, ML, IRC.

On Tue, Jan 27, 2009 at 11:01 AM, Loui Chang wrote:

On Tue, Jan 27, 2009 at 10:59:53AM -0500, Eric Bélanger wrote:

...

+1 for disabling comments for repo packages. Even with warnings, we risk having users using the comments instead of the bug tracker to report bugs. We already have users abusing the flag out-of-date functionnality to report bugs. If devs are very unlikely to read those comments, why would we have them in the first place? If users want to discuss about a package among themselves, they already have plenty of ways to do it: forums, ML, IRC.

That doesn't stop users from reporting bugs on the forums, ML, IRC and expecting devs to read them. Having comments and discussion about a package alongside the package makes a lot more sense than having the discussion detached elsewhere.

Well saying "it's already kinda broken so lets break it some more" isn't a good idea either. The rationale that "users are going to do it anyway" doesn't make much sense. As long as it's clear (and it can be) that for official packages, this is not a "comment for the maintainer" but a place to "discuss about the package" then we're not overlapping here. I'm trying to say - if you want to keep comments, that's fine. Just please be completely sure to point out that no dev is ever going to read it. Adding a link that says "Report a bug for this package" is a small step that would have a fairly large impact here.

On Tue, Jan 27, 2009 at 9:22 AM, Daenyth Blank wrote:

On Tue, Jan 27, 2009 at 12:20, Aaron Griffin wrote:

...

As long as it's clear (and it can be) that for official packages, this is not a "comment for the maintainer" but a place to "discuss about the package" then we're not overlapping here. I'm trying to say - if you want to keep comments, that's fine. Just please be completely sure to point out that no dev is ever going to read it. Adding a link that says "Report a bug for this package" is a small step that would have a fairly large impact here.

+1 on both keeping comments for discussion, and adding a link to report a bug.

Another +1 from me, FWIW...I've found comments quite useful in the past.

On Tue, Jan 27, 2009 at 12:36, Aaron Griffin wrote:

Actually, I think a bug report link, and changing "comment" to "discussion" would make a big impact here (at least for english). Additional "contact the maintainer" links may work, as long as they're not just mailto links... and people know it's not the place for bug reports

Sounds sane to me. +1