Bug/feature reqeust move to Sourceforge

[ollydbg]

BerliOS site has so limited feature on bugs/feature requests.
No email notification(only the dev assign the bug can receive the email), no file attachment....

This make devs hard to control/handle there issues.
With Sourceforge, we can have all of the feature above, besides that, I believe even more feature like the svn hook can be used to synchronize the bug report and the svn commit.

The difficult is: we have a lot of bugs/features in berliOs, so its hard to migrate.
Method:
1, free/lock the reports in berliOS (no new issues will be added)
2, enable the bugs/feature reqeusts in SF
3, I think some days later, we can clean up/digest all the issues in berliOS

What do you think?
BTW: If there is a way to translate the berliOS data to SF, that would be better.

EDIT:

I see this issue report by morten: #22161 (Transfer script for BerliOS->SourceForge) – sourceforge

But it was closed two years ago without any method mentioned:(


EDIT2:
I fire one in sourceforge, see: Forge / Feature Requests / #190 Is there any way to translate the bug/feature request data from berliOS to Sourceforge

[oBFusCATed]

I don't think this is a good idea.
The bug tracker on sf.net is awkward. If we're going to switch to something new it better be standalone bugtracker controlled by us.
So we can read its database move it to another platform, etc.
Almost all new/modern bugtrackers support import from older bugtrackers (mantis, bugzilla, trac).

Also I don't think we should bother much with moving the database, just make the berlios bugtracker read only for users and start a new one somewhere else.

[ToApolytoXaos]

Almost all new/modern bugtrackers support import from older bugtrackers (mantis, bugzilla, trac).

Indeed what you suggest is the best alternative IMHO and even though I very much prefer trac for its simplicity, I would say bugzilla is much more appropriate for C::B as a whole. Anyhow, that's only my suggestion and should not be taken for granted.

Also, It would be really convenient if registered users could login to submit either tickets or suggestions.

I would not mind to QA the entire project for old pending tickets so you guys concentrate on improvements. The only reason I did not do so thus far is because I did not want to register on Berlios as well while I'm already registered here.

[Alpha]

If we're going to switch to something new it better be standalone bugtracker controlled by us.

I am in support of this.

[dmoore]

Also I don't think we should bother much with moving the database, just make the berlios bugtracker read only for users and start a new one somewhere else.

I think this send a negative signal to our bug reporters. Why can't we import the old reports including some metadata that says this is a berlios era bug report and links back to the original report (because we won't be able to transfer user names easily if at all)?

Details for getting an RSS dump of bugs etc from berlios are here:

http://developer.berlios.de/docman/display_doc.php?docid=2056&group_id=2#tracker

[oBFusCATed]

I think this send a negative signal to our bug reporters.

Our reporters are already getting negative signals or to be more correct they get no signals, because almost no one bothers to follow or answer the reports.

[dmoore]

PS: I do think github's issue tracker is pretty good (and avoids redundancy of having separate features/support/patch/bug report trackers) and it seems to be relatively easy to import and export data to/from.

[dmoore]

I think this send a negative signal to our bug reporters.

Our reporters are already getting negative signals or to be more correct they get no signals, because almost no one bothers to follow or answer the reports.

Agree. Step 1 after the migration should be triaging the bugs reported at least in the last year. (About 100 by my count?)

[ToApolytoXaos]

In case you decide to go with github's issue tracker, please count me in as Quality Assurance.

Cheers.

[ollydbg]

FYI: I get one Reply from a SF guy:

Hi, we don't have an import process available specifically for Berlios, but you can import tickets based on a certain JSON format. That format is not fully documented but you can create a test project/tracker and export its data and use that as a complete example. See Admin > Export, and Admin > Import > Allura Import. So if you have a way to extract the data from Berlios then you can create that json file and import it.

[ollydbg]

I see bad news about Sourceforge:
http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/
and
http://www.gimp.org/ (the title is: GIMP Windows Installers move from Sourceforge to ftp.gimp.org)

EDIT: I just check our exe installer on SF was affected, the result is: it still download the correct exe (with the name: codeblocks-12.11mingw-setup.exe), but people may concern whether SF may do some modification to this exe, so we need check-sum numbers.

[thomas]

Aren't there any free Trac providers? Yiannis had Trac installed on the server that runs the website just for testing, and for laughs, some 3-4 years ago (or longer ago?). It worked really nicely and made both BerliOS and Sourceforge look like total loser sites.

[oBFusCATed]

http://trac.edgewall.org/wiki/CommercialServices (at the top there are some free options)

[ollydbg]

Do I need to send a PM to Yiannis? To let him enable the Trac service in our server? I think Trac does not take much traffic and CPU usage compared to our forum(SMF).

[Jenna]

Just for the interes, I havee placed a json file with the conten of our bug, feature and patch-tracker.
I used a slightly modified version of forgeplucker (a software that seems to be discontinued).

See: http://apt.jenslody.de/downloads/berlios.json.xz (about 2MB packed).