On Mon, Jan 26, 2009 at 5:00 AM, Jaroslav Lichtblau wrote:

On Fri, Jan 23, 2009 at 06:01:32AM +0100, Grigorios Bouzakis wrote:

...

+1 even if my vote doesnt count.

Cpmments for what? Out of date? -> Flag it Problem? -> Bug report Comments -> Feature request Cudos/Anything else -> Send personal email Donations -> Paypal

Just like its been with any other package in binary repos.

Greg

I share the same opinion here. No more advising users to fill out bug reports instead of commenting on community packages. And I also like to have all the stuff in 1 place (FS), rather then spread out on 20 AUR pages. IMO votes are no more needed on packages in repostories, neither any dividing into categories usig tags. Looking forward to the new order :)

Jaro

Well, I always like to "dream" finding the best solution (and eventually I got many bad solutions and many good ones), so I will dare to say my humble opinion about how AUR will work.. (maybe one of these opinions will be used on the future or will be a good goal to work on). So here we go (excuse me if this thread will split it or it will loose his sense) 1.- I suggested to maintain the unsupported packages with a backend based on one tool to control versions, (cvs, svn, git, mercurial, darcs, bazaar, <insert another here>), then we can have a good versioning support over the PKGBUILDS uploaded by the community, basicly we should develop a web client to one of these backends, and trust in a tool more powerful and more flexible. 2.- The accounts on AUR, Forums, Wiki, Bug tracker should be unique, I mean, I have differents accounts with the same login and different passwords, in differents parts of the portals, maybe have many passwords it's *more secure*, but being honestly, having different logins, and register in any portal everytime (bbs, bugtracker, aur) isn't the best, so having centralized accounts we don't have to force the users to have an account in AUR and another account in bugtracker because one time he will sign-in on the portal he will have access on the forums, bugtracker, wiki, etc, and this should be easier to report bugs. 3.- Every package in repositories and unsupported should use a similar interface for the users, for example, when you search a package on the web page if that package doesn't belong to core,extra,testing you won't be able to see it, and IMHO it would be fine if we can use also the same interface, or develop a new one for all repositories (even unsupported), I am just wondering, if we (TU crew) will use the same tools like the devs (not with the same permissions of course), why don't have similar web interfaces for the packages?. 4.- Every package's page should have links with a text like "bugs related to this package" (and the list of the bugs of this packages, to avoid to readding new bugs) and also a link "add new bug for this package" these links will call directly the bugtracker, the button about flag out of date should be considered to add a bug report? i don't like the idea, but it will be good if a new version of a package solves old bugs... Basicly these are my goals with a development of an integrated plataform or a how will goes better Arch and AUR, it's a thing to study and decide, then start to develop, isn't a thing to do in two days and I know it, but I would like to know opinions, I repeat *I am just wondering things*, I feel good about how works AUR actually, but this is my vision about future improvements, so please don't think that this mail is critic. Excuse me for my english and thanks for read this. -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Arch Linux Trusted User

On Tue, Jan 27, 2009 at 1:10 AM, Abhishek Dasgupta wrote:

2009/1/26 Angel Velásquez :

...

2.- The accounts on AUR, Forums, Wiki, Bug tracker should be unique, I mean, I have differents accounts with the same login and different passwords, in differents parts of the portals,

I've no idea how this might be possible. It'd be nice, but punbb, flyspray are all separate packages...

I know that punbb and flyspray and mediawiki are separate packages, but it's not impossible, in the place that I've worked before we used an LDAP backend to handle the accounts, so the database of the users will be the same, it's a thing to develop (if isn't developed yet) the autentication routines for these packages against LDAP.

...

4.- Every package's page should have links with a text like "bugs related to this package" (and the list of the bugs of this packages, to avoid to readding new bugs) and also a link "add new bug for this package" these links will call directly the bugtracker, the button about flag out of date should be considered to add a bug report? i don't like the idea, but it will be good if a new version of a package solves old bugs...

bugs.archlinux.org does not have a "Package" field for its bugs, so we'd have to search the bug titles. Something like this: [Show bugs for pitivi](http://bugs.archlinux.org/?string=pitivi&project=4)

-- Abhishek

As I said, we will have to develop patches to realize these ideas, isn't easy, but isn't hard at all, adding fields on the database, something like package_id, or modifying the form where the bug is added forcing to add the package name should be a way to do it. Then we can develop a script with the result of this query http://bugs.archlinux.org/?string=pitivi&project=4 in a format more flexible like XML, so we can read this XML and add it a cool list on the page handling it with JavaScript (a.k.a AJAX), this isn't hard to do too (I worked with this before too). The hard thing is install these backends and migrate the old stuff to the new plataform, so I will understand if this doesn't like to much to the people. Thanks for your time -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Arch Linux Trusted User