On Sat, Jan 24, 2009 at 03:36:56PM +1000, Allan McRae wrote:
Loui Chang wrote:
On Fri, Jan 23, 2009 at 01:51:40PM +1000, Allan McRae wrote:
As far as the web changes go, I suggest the relevant AUR developers talk to the people who do the Arch site work and sort this out.
Well it depends. Do we want [community] to remain in AUR so we keep votes and comments and such, or do we drop those packages from AUR?
One thing I think no-one has brought up regarding this. The main repos don't have package categories. So how would the AUR handle that?
I think the categories would be removed.
Loui Chang wrote:
On Sat, Jan 24, 2009 at 03:36:56PM +1000, Allan McRae wrote:
Loui Chang wrote:
On Fri, Jan 23, 2009 at 01:51:40PM +1000, Allan McRae wrote:
As far as the web changes go, I suggest the relevant AUR developers talk to the people who do the Arch site work and sort this out.
Well it depends. Do we want [community] to remain in AUR so we keep votes and comments and such, or do we drop those packages from AUR?
One thing I think no-one has brought up regarding this. The main repos don't have package categories. So how would the AUR handle that?
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
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.
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.
+1. I'm agree with Evangelos.
We'll have more "control" with flyspray.
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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.
On Sat, Jan 24, 2009 at 4:19 PM, Daenyth Blank daenyth+arch@gmail.com wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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 9:53 AM, Ronald van Haren pressh@gmail.com wrote:
On Sat, Jan 24, 2009 at 4:19 PM, Daenyth Blank daenyth+arch@gmail.com wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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's worth point out that commenting on the AUR is "easier" for some users than using the bug tracker.
However, my own personal opinion is this: if you're not willing to _learn_ to use the bug tracker, then you're probably not willing to _learn_ Arch as well. We always proported to be a distro for knowlegable users. So let's trust the users know what they're doing, or are willing to learn. If something being "too much work" turns someone away, maybe they aren't suited to Arch.
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 daenyth+arch@gmail.com wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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 Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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.
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 allan@archlinux.org 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 8:14 PM, Loui Chang louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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.
On Mon, Jan 26, 2009 at 10:20:10PM -0600, Aaron Griffin wrote:
On Mon, Jan 26, 2009 at 8:14 PM, Loui Chang louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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:51 PM, Loui Chang louipc.ist@gmail.com 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 louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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
On Mon, Jan 26, 2009 at 10:57:52PM -0600, Aaron Griffin wrote:
On Mon, Jan 26, 2009 at 10:51 PM, Loui Chang louipc.ist@gmail.com 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 louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 10:19:21AM -0500, Daenyth Blank wrote:
On Sat, Jan 24, 2009 at 00:59, Allan McRae allan@archlinux.org 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 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].
On Mon, Jan 26, 2009 at 11:49 PM, Loui Chang louipc.ist@gmail.com 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 4:55 PM, Aaron Griffin aaronmgriffin@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:49 PM, Loui Chang louipc.ist@gmail.com 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?
On Tue, Jan 27, 2009 at 3:20 AM, James Rayner iphitus@gmail.com wrote:
On Tue, Jan 27, 2009 at 4:55 PM, Aaron Griffin aaronmgriffin@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:49 PM, Loui Chang louipc.ist@gmail.com 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 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.
On Tue, Jan 27, 2009 at 11:01 AM, Loui Chang louipc.ist@gmail.com 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 12:20, Aaron Griffin aaronmgriffin@gmail.com 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.
On Tue, Jan 27, 2009 at 9:22 AM, Daenyth Blank daenyth+arch@gmail.com wrote:
On Tue, Jan 27, 2009 at 12:20, Aaron Griffin aaronmgriffin@gmail.com 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 11:22 AM, Daenyth Blank daenyth+arch@gmail.com wrote:
On Tue, Jan 27, 2009 at 12:20, Aaron Griffin aaronmgriffin@gmail.com 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.
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
On Tue, Jan 27, 2009 at 12:36, Aaron Griffin aaronmgriffin@gmail.com 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
On Tue, Jan 27, 2009 at 12:39 PM, Daenyth Blank daenyth+arch@gmail.com wrote:
On Tue, Jan 27, 2009 at 12:36, Aaron Griffin aaronmgriffin@gmail.com 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
Another thread reminded me of another reason to remove the community repo from AUR. The AUR doesn't have multi-architecture support so packages that are only in the x86_64 community repo (like lib32-* stuff) are not displayed on AUR. Unless someone want to fix this, we might as well removing community from AUR. This way we will fix that long standing problem once for all.
On Sat, Jan 24, 2009 at 06:42, Loui Chang louipc.ist@gmail.com 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.
On Sat, Jan 24, 2009 at 01:27:18PM +0100, Geoffroy Carrier wrote:
On Sat, Jan 24, 2009 at 06:42, Loui Chang louipc.ist@gmail.com 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.
Categories wouldn't really have to be removed, but you'd have to set them manually like in unsupported.
On Sat, 24 Jan 2009 09:25:59 -0500 Loui Chang louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 01:27:18PM +0100, Geoffroy Carrier wrote:
On Sat, Jan 24, 2009 at 06:42, Loui Chang louipc.ist@gmail.com 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 15:52, Dieter Plaetinck dieter@plaetinck.be wrote:
what about tags instead of categories?
We already have groups, provide descriptions and URLs.
Are there/would there be people using features such as categories, tags, etc.? Are there people who want to focus on writing tools to support them? And then spend time on feeding them with the corresponding info? If yes, let's do it!
IMHO freshmeat/the FSF directory, for example, already do a nice job of classification. Should every distro spend time on providing similar features for their packages?
I don't feel like it fits in arch. And I personally don't want to focus on it either...
So that should be my last message in this thread :)
On Sat, Jan 24, 2009 at 8:52 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
On Sat, 24 Jan 2009 09:25:59 -0500 Loui Chang louipc.ist@gmail.com wrote:
On Sat, Jan 24, 2009 at 01:27:18PM +0100, Geoffroy Carrier wrote:
On Sat, Jan 24, 2009 at 06:42, Loui Chang louipc.ist@gmail.com 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.
aur-general@lists.archlinux.org