Migrating BerliOS to SourceForge

[Alpha]

I have been starting a few tests with with migration of the BerliOS dump files, and have run into what will likely be a major issue.  Attached files on SourceForge do not appear anywhere in the complete export.  They are only referenced by a url, but give no hint of how a file could be imported to that location.

Code

{
  "status": "open",
  "reported_by_id": "5124334124b0d9277e70766c",
  "related_artifacts": [],
  "attachments": [
    {
      "url": "http://sourceforge.net/p/ticketexport/patches/3/attachment/converterTest.py",
      "bytes": 921
    }
  ],
  "reported_by": "alpha0010",
  "description": "Extended description.",
  "labels": [],
  "assigned_to": "alpha0010",
  "assigned_to_id": "5124334124b0d9277e70766c",
  "private": false,
  "summary": "Ticket with patch",
  "discussion_thread": {
    "_id": "bc4d1a58",
    "posts": [],
    "discussion_id": "529d6ac0d46bb4611598533a",
    "subject": ""
  },
  "mod_date": "2014-06-06 01:34:22.120000",
  "votes_down": 0,
  "votes_up": 0,
  "_id": "53911a9df1fd8d55b0aeeeb3",
  "discussion_thread_url": "http://sourceforge.net/rest/p/ticketexport/patches/_discuss/thread/bc4d1a58/",
  "ticket_num": 3,
  "custom_fields": {
    "_milestone": "1.0"
  },
  "created_date": "2014-06-06 01:34:21.961000"
}

[Alpha]

Another issue, is that it appears the BerliOS dump was faulty: inside bs_patches_0.1.xml, all instances of the tags status_id and category_id are empty.

[Alpha]

Attached is a start at creating a conversion script (Python).  (The .patch must be applied first to remove invalid characters from the XML dump.)
Unfortunately SourceForge import does not tell you what the errors are when an import fails, so this will not be easy.

[oBFusCATed]

I don't think we should do any migration at all.
We cannot match the users on the two systems, but most bugs require a dialogue with the user in order to gather more information or to understand what the problem was. Thus will end with a pile of bugs no one would bother to try to fix.

[ollydbg]

@Alpha, maybe, we should ask the questions on SF, I and Morten have asked there, see:
Bug/feature reqeust move to Sourceforge

@OBF, If we don't migrate, we may lose a lot of resources(some patches, feature requests in BerliOS are very useful)

[oBFusCATed]

If something is useful it would be requested again.
The bug tracker on berlios is full of invalid or abandoned (by the reporter) issues.

[BlueHazzard]

I'm with obfuscated, the patch and also the bugtracker on berlios where to old, and to bad maintained to get useful things from them. Also if some patch where useful they are now integrated or they where not necessary... I would count more on seeing it as a restart. The new bug tracker on sourceforge is again full with bugs/patches not maintained from the admins (no offense here!!!)...
They should get closed if there is nothing to say about them (like the first ticket)

greetings

[ollydbg]

If something is useful it would be requested again.
The bug tracker on berlios is full of invalid or abandoned (by the reporter) issues.

Yes, there are many invalid issues. But I once added some issues as my TODO lists, and now they are all buried in the exported xml files  )
So it is great if the exported xml files can be imported to SF's ticket system.

[Alpha]

I have been thinking about this, and perhaps it is better if we create a read-only page for the history, and allow SF to start fresh.  Here is my beginning:
https://github.com/alpha0010/cb-history
http://alpha0010.github.io/cb-history/patches.html

[ollydbg]

I have been thinking about this, and perhaps it is better if we create a read-only page for the history, and allow SF to start fresh.  Here is my beginning:
https://github.com/alpha0010/cb-history
http://alpha0010.github.io/cb-history/patches.html

Nice work, the html page looks good.

[Alpha]

The bugs listing is populated.
http://alpha0010.github.io/cb-history/bugs.html

Next up, features list.  Then I will see what I can do about filtering and searching.

[ollydbg]

The bugs listing is populated.
http://alpha0010.github.io/cb-history/bugs.html

Next up, features list.  Then I will see what I can do about filtering and searching.

Great.
One suggestion:
Is it possible to translate the link in the comments of Patch to Bug items?
See: http://alpha0010.github.io/cb-history/patches/3502-Allow_C_11_com.html There is a link:

Code

https://developer.berlios.de/bugs/?func=detailbug&bug_id=19125&group_id=5358

in the comments.

Thanks.

[Alpha]

Is it possible to translate the link in the comments of Patch to Bug items?

I think so.  I already have some local code starting that; but I think I should finish the features list first so I can cross link between the three.

[ollydbg]

Hi, alpha, I may be aggressive. Here is another idea: once a bug is fixed in our trunk, can the bug web page be marked as closed or fixed. I mean if it can have futures(API) that devs have rights to edit the issue item. Thanks.

[ollydbg]

I have update our wiki home page, so that bugs/features direct to SF and the pages your created.

[Alpha]

All pages on http://alpha0010.github.io/cb-history/ are now populated (lots of issues scraping together the features page because the dump from BerliOS contains none of that data) with all history I was able to get access to.  Links within the comments that direct to BeriOS are (for the most part) rewritten to link internally.

Here is another idea: once a bug is fixed in our trunk, can the bug web page be marked as closed or fixed. I mean if it can have futures(API) that devs have rights to edit the issue item.

Hmm, this would be difficult to do live because hosting webpages on github restricts you to serving only static content.  I could grant devs commit access to the repo.  Or, I could regenerate the pages if someone lets me know whenever a ticket is closed.

[ollydbg]

Hi, Alpha, with you page and Google, I can quick find and locate an old bug(see: Re: Patch for inserting implementation), thanks.

Here is a small bug.
Look at the page: http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html, the first comments still contains a link which jump to berlios.

Here is another idea: once a bug is fixed in our trunk, can the bug web page be marked as closed or fixed. I mean if it can have futures(API) that devs have rights to edit the issue item.

Hmm, this would be difficult to do live because hosting webpages on github restricts you to serving only static content.  I could grant devs commit access to the repo.  Or, I could regenerate the pages if someone lets me know whenever a ticket is closed.

Fine, thanks.

[ollydbg]

Another two issue:
1, The web link format is currently

Code

http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html

Is it possible to change to some thing like:

Code

http://alpha0010.github.io/cb-history/bugs/18526.html

which is much cleaner.

2, Is comments in the same thread sorted? In the page: http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html
I see that a newer comment is put in the first.

Still these can be feature request, thanks.

[Alpha]

Look at the page: http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html, the first comments still contains a link which jump to berlios.

Odd... I must have messed up my regex's or something; looking into it.

1, The web link format is currently

Code

http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html

Is it possible to change to some thing like:

Code

http://alpha0010.github.io/cb-history/bugs/18526.html

which is much cleaner.

I could change it, but I personally prefer having some detail in the file name.  That way, it is easier to identify files on disk (especially if you are downloading multiple patch files).  What do you think?  Maybe simplify the .html, but leave the .patch file names?

2, Is comments in the same thread sorted? In the page: http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html
I see that a newer comment is put in the first.

They are supposed to be sorted.  Reviewing my code, it appears some them get sorted, and some of them just (incorrectly) assume they are already sorted.

[ollydbg]

1, The web link format is currently

Code

http://alpha0010.github.io/cb-history/bugs/18526-Insert_all_cl.html

Is it possible to change to some thing like:

Code

http://alpha0010.github.io/cb-history/bugs/18526.html

which is much cleaner.

I could change it, but I personally prefer having some detail in the file name.  That way, it is easier to identify files on disk (especially if you are downloading multiple patch files).  What do you think?  Maybe simplify the .html, but leave the .patch file names?

Hi, thanks.
The reason I would like to see a short html is that some times, I may add this link to our SVN commit message, such as:

Code

* CC: fix a bug xxxx, see: http://alpha0010.github.io/cb-history/bugs/18526.html

So, we can have a clean web page reference. I don't have much strong option whether option is good. 

About the patch names, I totally agree with you, the patch name should have some details in the file name. 

[Alpha]

Pages renamed and comments sorted.

[ollydbg]

Pages renamed and comments sorted.

Great work, thanks!

[Alpha]

The pages all have basic filtering controls, so now it is a bit more manageable to navigate.  If anyone has a request for another field I implement filtering on, let me know (although, I would prefer to keep filters down to only the most useful ones).