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).

[thomas]

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.

Is this even possible in an easy, straightforward way? I mean, sure it's possible to add any kind of malware to any kind of executable (including an installer), but does our installer support adding a drive-by install once it has been compiled? That's NSIS, right?

In any case, checksumming and signing might rule that out (though of course nobody verifies checksums...).

[oBFusCATed]

As far as I understand it for now the feature is opt in and it is up to the projects to decide if they want it or not.
Also every project has some control on things that are included in the installer.

[thomas]

That's what I understood too, been searching the web for that thing the last hour or so. It really seems you have to opt-in, otherwise nothing happens. I've verified the download just to be 100% sure too, and it looks genuine.

[ollydbg]

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).

I create a test project in SF (https://sourceforge.net/p/ticketexport/) , and add some tickets there, then I export them, the result json file attached.

I compared the format of json format of berlios and SF, much similar, but we need a transfer program/script to translate the format.

a ticket of BerliOS:

Code

{
                    "URL": "https://developer.berlios.de/bugs/?func=detailbug&bug_id=19187&group_id=5358", 
                    "assigned_to": "jenslody", 
                    "category": "Application::Crash", 
                    "class": "ARTIFACT", 
                    "comments": [
                        {
                            "class": "COMMENT", 
                            "comment": "The current SVN revision 9435 crashes when I start C::B without options and wants to send a debug log. (Which has only modules information in it.)\n\nSVN revision 9425 worked fine.\n\nWhen starting with \ncodeblocks -d -v\nit works and no longer crashes after\n\n- A message on the console:\n(codeblocks:10887): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -16\n\n- A popup with the text\n\"iCCP: known incorrect sRGB profile\"\n-> Details shows the same message 9 times.\n\nAfter clicking \"OK\" on the popup I can work with C::B normally.\n", 
                            "date": "2013-11-08T10:44:00Z", 
                            "submitter": {
                                "class": "IDENTITY", 
                                "nick": "yamakuzure"
                            }
                        }
                    ], 
                    "dependents": [], 
                    "group": "Platform:Linux", 
                    "history": [
                        {
                            "by": "jenslody", 
                            "class": "FIELDCHANGE", 
                            "date": "2013-11-08T21:46:00Z", 
                            "field": "assigned_to", 
                            "new": "jenslody", 
                            "old": "none"
                        }
                    ], 
                    "id": 19187, 
                    "priority": "5 - Medium", 
                    "resolution": "None", 
                    "status": "Open", 
                    "summary": "[SVN 9435] Crash without debug mode (iCCP, Gtk)", 
                    "type": "bugs"
                }, 
                

a ticket of SF:

Code

{
  "status": "open",
  "reported_by_id": "4d215fc8b9363c7d7a0004b9",
  "related_artifacts": [],
  "attachments": [],
  "reported_by": "ollydbg",
  "description": "Report a bug.",
  "labels": [
    "CodeCompletion"
  ],
  "assigned_to": "nobody",
  "assigned_to_id": null,
  "private": false,
  "summary": "Second ticket",
  "discussion_thread": {
    "_id": "3a7bb9c2",
    "posts": [
      {
        "text": "Add comments in second ticket",
        "attachments": [],
        "author": "ollydbg",
        "timestamp": "2013-11-15 01:59:37.406000",
        "slug": "5b9c",
        "subject": "#2 Second ticket"
      }
    ],
    "discussion_id": "52857ef7b9363c0db81f5bc5",
    "subject": ""
  },
  "mod_date": "2013-11-15 01:59:37.882000",
  "votes_down": 0,
  "votes_up": 0,
  "_id": "52857fcb3e5e8370b9e983b9",
  "discussion_thread_url": "http://sourceforge.net/rest/p/ticketexport/tickets/_discuss/thread/3a7bb9c2/",
  "ticket_num": 2,
  "custom_fields": {
    "_milestone": "1.0"
  },
  "created_date": "2013-11-15 01:58:35.229000"
}

I'm using Notepad++ and JStool plugin (can be easily installed by plugin manager in Notepad++) to view the json object.

[attachment deleted by admin]

[Jenna]

It should not be too hard to translate one json object in another.
PHP can work with json quiet good, Python also as you can see in my dump (not my script, I don't know much about python)  and (of course) javascript can.

Of these three I am most familiar with PHP and javascript, so I could write a tool to convert this.

Did you notice, that features and patches are also dumped (with a slightly different format of course) ?

Besides of this, I have no good feeling with sf.net.

[ollydbg]

It should not be too hard to translate one json object in another.
PHP can work with json quiet good, Python also as you can see in my dump (not my script, I don't know much about python)  and (of course) javascript can.

Of these three I am most familiar with PHP and javascript, so I could write a tool to convert this.

Thanks

Did you notice, that features and patches are also dumped (with a slightly different format of course) ?

In my testing site: https://sourceforge.net/p/ticketexport/tickets/
I only have "tickets" (no bugs/feature-requests/patches)
But I do see some site has those three categories, like the one below:
https://sourceforge.net/p/notepad-plus/_list/tickets
So, I will try to create some sub categories on my testing site, and try to see whether bugs/feature-requests/patches are exported in different json format.

Besides of this, I have no good feeling with sf.net.

I have no idea, SF's ticket system looks good(at least better than berlios).
why not we create our own on codeblocks.org? (since no devs have suggested to do that).

[oBFusCATed]

I don't think switching to the bug tracker of sf.net will be big improvement.
Also I don't think we need to transfer anything.
Most of the problems require user input and we'll loose it.

[dmoore]

I don't think switching to the bug tracker of sf.net will be big improvement.
Also I don't think we need to transfer anything.
Most of the problems require user input and we'll loose it.

Can't we automate a comment on every open bug  in berlios linking to sourceforge/whatever solution we devise telling the reporter to subscribe to/update the bug on the new tracker? That should send an email notification to every reporter.

Noone thinks github issues is a good idea? It's a more user friendly and less rigid system, which I think works well with smaller open source projects.

[oBFusCATed]

Noone thinks github issues is a good idea? It's a more user friendly and less rigid system, which I think works well with smaller open source projects.

We won't switch to git anytime soon, so there is little point in switching to github for bugs/features.

[dmoore]

Noone thinks github issues is a good idea? It's a more user friendly and less rigid system, which I think works well with smaller open source projects.

We won't switch to git anytime soon, so there is little point in switching to github for bugs/features.

Just thinking of the users... Even if we aren't using the pull request system, their issues UI is still a shitload nicer to use than alternatives. Are there any other bug tracking system like it?

To give an idea, here are issues for node.js, one of the bigger github projects:

https://github.com/joyent/node/issues

[oBFusCATed]

... than alternatives. ..

What do you target as alternatives?

[dmoore]

... than alternatives. ..

What do you target as alternatives?

berlios, trac, launchpad. anything else?

[oBFusCATed]

www.jetbrains.com/youtrack/ (a friend is using it, they have free plans for opensource projects)
Jira (I've heard it is awful, but I've not used yet)
Mantis
Bugzilla

[hinojosad]

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.

Say, I'm the Community Manager at SourceForge; I wanted to assure you, as you have seen, we do not impose the DevShare program on projects; DevShare is fully opt in for projects and users.

You can reference our blog post where we announced the program (http://sourceforge.net/blog/today-we-offer-devshare-beta-a-sustainable-way-to-fund-open-source-software/), as well as where we addressed the concerns raised by our community (http://sourceforge.net/blog/advertising-bundling-community-and-criticism/).

If you all need or desire any further clarification, I am available to help.

Best regards,

Daniel.
--

[Alpha]

As another idea, I recently came across Phabricator.  (I am not sure what to make of it though.)

[oBFusCATed]

The enlightenment project has switched to it and there is one serious problem: it requires logging-in just for browsing the tickets, which I don't think it is a good idea.

[ollydbg]

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).

I create a test project in SF (https://sourceforge.net/p/ticketexport/) , and add some tickets there, then I export them, the result json file attached.

FYI: In sourceforge's testing project, I can add several tickests pages including bugs, features, patches, so I exported them as a reference. (three json files), see attachment.


[attachment deleted by admin]

[ollydbg]

FYI:

I found a wiki page in SF: Forge / Documentation / Importing from BerliOS

Also:

berlios will close project host in 2014.04