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.
If we're going to switch to something new it better be standalone bugtracker controlled by us.I am in support of this.
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.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.
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.
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.
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?
Just for the interes, I havee placed a json file with the conten of our bug, feature and patch-tracker.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 used a slightly modified version of forgeplucker (a software that seems to be discontinued).
See: http://apt.jenslody.de/downloads/berlios.json.xz (http://apt.jenslody.de/downloads/berlios.json.xz) (about 2MB packed).
{
"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"
},
{
"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"
}
It should not be too hard to translate one json object in another.Thanks
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) ?In my testing site: https://sourceforge.net/p/ticketexport/tickets/
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).
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.
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.
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.
... than alternatives. ..What do you target as alternatives?
... than alternatives. ..What do you target as alternatives?
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.
Just for the interes, I havee placed a json file with the conten of our bug, feature and patch-tracker.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 used a slightly modified version of forgeplucker (a software that seems to be discontinued).
See: http://apt.jenslody.de/downloads/berlios.json.xz (http://apt.jenslody.de/downloads/berlios.json.xz) (about 2MB packed).