sourceforge: IdeaTorrent

Written by dgranda the 20 Nov 09 at 14:44.

Moving Ideatorrent link where other trackers are clickable would make it easier to find. In addition, it would be great to have the chance to not allow new entries in old "Feature Request" tracker explaining that new entries should go to IdeaTorrent providing a link.

Moving Ideatorrent link where other trackers are clickable would make it easier to find. In addition, it would be great to have the chance to not allow new entries in old "Feature Request" tracker explaining that new entries should go to IdeaTorrent providing a link.

Written by trilarion the 19 Nov 09 at 14:05.

Pretty much have said it all above. It will all depend on the projects willing to give enough useful information to help and the people willing to help. However the benefit (bringing software from version 0.98 to 1.0) could be great!

Pretty much have said it all above. It will all depend on the projects willing to give enough useful information to help and the people willing to help. However the benefit (bringing software from version 0.98 to 1.0) could be great!

Written by gefahrmaus the 16 Nov 09 at 01:11.

This could be a post-commit hook in SVN, or some other asynchronous method of SF choosing, post processing the keepsake RSS feed maybe.

This could be a post-commit hook in SVN, or some other asynchronous method of SF choosing, post processing the keepsake RSS feed maybe.

Written by andrewsteinborn the 21 Nov 09 at 00:56.

Simply implementing the project VHOST solution to developer web will resolve the issue.

Simply implementing the project VHOST solution to developer web will resolve the issue.

Written by critternyc the 11 Nov 09 at 22:47.

Providing a simple CSV dump of the full filename (including the folder(s)) and the all-time total number of downloads on either a nightly or weekly basis will let project admins be able to download that file and then easily summarize it as they need it by folder or sub-folder using a spreadsheet or database. The single CSV file per project that's not dynamically generated wouldn't put much additional load on the system.

Providing a simple CSV dump of the full filename (including the folder(s)) and the all-time total number of downloads on either a nightly or weekly basis will let project admins be able to download that file and then easily summarize it as they need it by folder or sub-folder using a spreadsheet or database. The single CSV file per project that's not dynamically generated wouldn't put much additional load on the system.

Written by tetsuo55 the 4 Nov 09 at 17:51.

I suggest Sourceforge site staff use the following (open source) application to run static analysis on all of sourceforge inluding the hosted applications.

The appliction is called "Page Speed", it is a firefox plugin.
Source and binaries here: http://code.google.com/speed/page-speed/index.html
One of the things that i noticed first is that hosted apps do not seem to have gzip enabled, causing a huge waste of bandwith.

As part of Google's "Speed up the web" program there is also a webpage with best practices for performance of websites (this site is also community based)
http://code.google.com/speed/

That site also has a link with a ton of optimizing applications but i have not investigated those yet

I suggest Sourceforge site staff use the following (open source) application to run static analysis on all of sourceforge inluding the hosted applications. The appliction is called "Page Speed", it is a firefox plugin. Source and binaries here: http://code.google.com/speed/page-speed/index.html One of the things that i noticed first is that hosted apps do not seem to have gzip enabled, causing a huge waste of bandwith. As part of Google's "Speed up the web" program there is also a webpage with best practices for performance of websites (this site is also community based) http://code.google.com/speed/ That site also has a link with a ton of optimizing applications but i have not investigated those yet

Written by hackmiker the 3 Nov 09 at 14:20.

It would be nice if SF also included at least the commit message, if not the list of changed files.

This can be useful for feed reader users and other services.

It would be nice if SF also included at least the commit message, if not the list of changed files. This can be useful for feed reader users and other services.

Written by milo-software the 18 Nov 09 at 13:06.

git clone http://project.git.sourceforge.net/.... should work.

git clone http://project.git.sourceforge.net/.... should work.

Written by mcrotty the 17 Nov 09 at 23:00.

Details for installing it can be found here:
http://trac-hacks.org/wiki/TocMacro

Details for installing it can be found here: http://trac-hacks.org/wiki/TocMacro

Written by faenon the 23 Nov 09 at 18:20.

Basic instructions can be found here:
http://trac.edgewall.org/wiki/TracMercurial

Basic instructions can be found here: http://trac.edgewall.org/wiki/TracMercurial

Written by toumimi the 13 Nov 09 at 23:52.

Using a webservice, we can directly retreive a list of all files for a project, for a subfolder, and configure if we want additional informations or not.
I think this is the most appropriate way to do that.
We would choose the project, the subfolder, and the configuration.

Using a webpage, we can also send informations throw both $_GET and $_POST variable. It should be one file per project to be more efficient.

Informations should be retrieved as an xml file to deal with subfolders and additional informations.

Using a webservice, we can directly retreive a list of all files for a project, for a subfolder, and configure if we want additional informations or not. I think this is the most appropriate way to do that. We would choose the project, the subfolder, and the configuration. Using a webpage, we can also send informations throw both $_GET and $_POST variable. It should be one file per project to be more efficient. Informations should be retrieved as an xml file to deal with subfolders and additional informations.

Written by toumimi the 13 Nov 09 at 23:57.

SourceForge can also build a complete xml file each time a file has been added or removed.
It should be automatic.
Problem is that can take server ressources if we add many files separately.
But, it is reduced if we add many files together, and stabilises itself because there is a moment when no update are made on a project.

SourceForge can also build a complete xml file each time a file has been added or removed. It should be automatic. Problem is that can take server ressources if we add many files separately. But, it is reduced if we add many files together, and stabilises itself because there is a moment when no update are made on a project.

Written by gnoxx the 13 Nov 09 at 12:54.

Clicking on the title of a news item on the project summery page should take the user to "https://sourceforge.net/news/?group_id=..." istead of "https://sourceforge.net/projects/sfnews/forums/forum/..."

Clicking on the title of a news item on the project summery page should take the user to "https://sourceforge.net/news/?group_id=..." istead of "https://sourceforge.net/projects/sfnews/forums/forum/..."

Written by jdpipe the 4 Nov 09 at 23:44.

As far as I can tell, the solution for this problem just requires more platforms to be added to the detection algorithm.

For example, by Browser gives the following user-agent string:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091028
Ubuntu/9.10 (karmic) Firefox/3.5.4

Likewise, detection of Fedora looks to be straighforward as well:
http://fedoraproject.org/wiki/Planet/TestMatrix#Fedora.2C_Firefox_3

So it's probably just a question of regexing for
/Linux.*Ubuntu/
/Linux.*Fedora/

More sophisticated approaches would also detect the release (eg Ubuntu/9.10). But this is definitely optional.
/Lunix.*Ubuntu\/9.10/

As far as I can tell, the solution for this problem just requires more platforms to be added to the detection algorithm. For example, by Browser gives the following user-agent string: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091028 Ubuntu/9.10 (karmic) Firefox/3.5.4 Likewise, detection of Fedora looks to be straighforward as well: http://fedoraproject.org/wiki/Planet/TestMatrix#Fedora.2C_Firefox_3 So it's probably just a question of regexing for /Linux.*Ubuntu/ /Linux.*Fedora/ More sophisticated approaches would also detect the release (eg Ubuntu/9.10). But this is definitely optional. /Lunix.*Ubuntu\/9.10/ In determining the user's platform, an algorithm could run down the list of regexes and select the last one that matched. This way, you could identify "Linux" or "Ubuntu" or "Ubuntu/9.10", depending on how platform-specific the user chose to be in tagging their releases.

Written by jdpipe the 4 Nov 09 at 23:48.

An alternative approach would be to have an additional page appear in the case where multiple 'default downloads' match a particular platform.

So that way, the developer could specify one file for Windows, and that would download immediately. But they could specifiy two or more files for Linux, and that would result in a page like this:

"There are multiple Linux downloads suggested for PROJECTNAME: please select from..."

That would not require any more programming on the admin interface, but would improve usability for these Linux downloads but offering .rpm and .deb options without ever making a wrong assumption about which one the user wants.

An alternative approach would be to have an additional page appear in the case where multiple 'default downloads' match a particular platform. So that way, the developer could specify one file for Windows, and that would download immediately. But they could specifiy two or more files for Linux, and that would result in a page like this: "There are multiple Linux downloads suggested for PROJECTNAME: please select from..." That would not require any more programming on the admin interface, but would improve usability for these Linux downloads but offering .rpm and .deb options without ever making a wrong assumption about which one the user wants.

Written by nogoodatcoding the 12 Nov 09 at 22:47.

Avoiding the problem:
1. The simplest way to avoid this situation in the first place is to only allow users who are logged into the system to create new tickets. However, I am of the opinion that the extra step of first creating an account (if the user doesn't have one already) and then logging in, would discourage some users from logging bugs. Perhaps the loss of anonymity as well. So I've made the conscious decision of allowing anonymous tickets on my Trac.

Fixing the problem:
I'm not familiar with the internal workings of Trac but a little Google'ing turned up these two options for getting rid of the offending tickets:

1. Fire off SQL queries on the Trac DB:
$ sqlite trac.db
delete from ticket_change where ticket = 1234;
delete from ticket_custom where ticket = 1234;
delete from ticket where id = 1234;

Obviously this doesn't work for an environment like SourceForge.ent

2. Use the TicketDeletePlugin: http://trac-hacks.org/wiki/TicketDeletePlugin

Avoiding the problem: 1. The simplest way to avoid this situation in the first place is to only allow users who are logged into the system to create new tickets. However, I am of the opinion that the extra step of first creating an account (if the user doesn't have one already) and then logging in, would discourage some users from logging bugs. Perhaps the loss of anonymity as well. So I've made the conscious decision of allowing anonymous tickets on my Trac. Fixing the problem: I'm not familiar with the internal workings of Trac but a little Google'ing turned up these two options for getting rid of the offending tickets: 1. Fire off SQL queries on the Trac DB: $ sqlite trac.db delete from ticket_change where ticket = 1234; delete from ticket_custom where ticket = 1234; delete from ticket where id = 1234; Obviously this doesn't work for an environment like SourceForge.ent 2. Use the TicketDeletePlugin: http://trac-hacks.org/wiki/TicketDeletePlugin Again, this requires the ability to install the plugin on Trac and so, can't be done by the hosted app users. However, if SourceForge.net was to offer this plugin for general use, it might help people in the situation that I find myself in, without having to give them access to the DB.

Written by ceball the 12 Nov 09 at 20:31.

Since my opinion about what users should see when they first visit the bug tracker for my project differs from Sourceforge's, couldn't my project be allowed to specify the default options for its own trackers? Then I could choose to display only the open bugs by default to visitors to my tracker. I could also show the bugs ordered by priority by default.

Since my opinion about what users should see when they first visit the bug tracker for my project differs from Sourceforge's, couldn't my project be allowed to specify the default options for its own trackers? Then I could choose to display only the open bugs by default to visitors to my tracker. I could also show the bugs ordered by priority by default.

Written by jbednar the 23 Nov 09 at 15:44.

Even though I too believe that the most useful default is to display open bugs only, in priority order, having some other site-wide default would be fine as long as once a given user changes their view, it persists for all future session. That way a developer can set it up the way he/she wants, and it will then work properly (compared to the current situation, which doesn't work at all). This solution differs from solution #1 by being per-user, rather than per-project.

Even though I too believe that the most useful default is to display open bugs only, in priority order, having some other site-wide default would be fine as long as once a given user changes their view, it persists for all future session. That way a developer can set it up the way he/she wants, and it will then work properly (compared to the current situation, which doesn't work at all). This solution differs from solution #1 by being per-user, rather than per-project.

Written by slicer the 9 Nov 09 at 15:16.

sf.net already uses OpenID authentication for users. Start offering OpenID provider services, and allow this to be used both from project web pages and the rest of the net.
Doing so would allow any project associated with sourceforge to securely authenticate users to their matching sf.net username, no matter where their webpages are hosted.

sf.net already uses OpenID authentication for users. Start offering OpenID provider services, and allow this to be used both from project web pages and the rest of the net. Doing so would allow any project associated with sourceforge to securely authenticate users to their matching sf.net username, no matter where their webpages are hosted.

Written by slicer the 9 Nov 09 at 15:24.

Just like the hosted applications, set up https for the project webpages hosted on *.sourceforge.net (using a wildcard cert) and authenticate against the sf.net user database. This will give project pages hosted on sf.net access to the username.
To avoid user confusion, set up the 401 authentication error page to show a short error message and redirect to the non-https equivalent. It probably also makes sense to reject spiders to the https pages, to avoid these ending up in search engines.

Just like the hosted applications, set up https for the project webpages hosted on *.sourceforge.net (using a wildcard cert) and authenticate against the sf.net user database. This will give project pages hosted on sf.net access to the username. To avoid user confusion, set up the 401 authentication error page to show a short error message and redirect to the non-https equivalent. It probably also makes sense to reject spiders to the https pages, to avoid these ending up in search engines.

Written by luc_peuvrier the 8 Nov 09 at 04:02.

instead of a platform column have a file type column. with some predefined values as: executable for platform ( with platform list or platform independant ), source files, file checksum. And a free text for a user description.

instead of a platform column have a file type column. with some predefined values as: executable for platform ( with platform list or platform independant ), source files, file checksum. And a free text for a user description.

Written by vampire0 the 7 Nov 09 at 11:42.

I suggest something like it was there in former times if I remember correctly. I want to have a page where I can somehow do a bulk update. e. g. a tabular page like the Membership page, but editable.

I suggest something like it was there in former times if I remember correctly. I want to have a page where I can somehow do a bulk update. e. g. a tabular page like the Membership page, but editable.

Written by devlaam the 18 Nov 09 at 10:37.

It should be possible to edit your own posts (if not anonymous) and the project administrator should be able to edit all posts. Simply add one button "edit selection" that generates a text box just like the reply box. Thats all.

It should be possible to edit your own posts (if not anonymous) and the project administrator should be able to edit all posts. Simply add one button "edit selection" that generates a text box just like the reply box. Thats all.

Written by fraber the 5 Nov 09 at 14:15.

Maybe only show this option to "advanced" or "heavy" users, if you don't want to complicate the GUI for normal users.

Maybe only show this option to "advanced" or "heavy" users, if you don't want to complicate the GUI for normal users.