Hi all;
I'm not sure if this has been discussed anywhere but, what will happen with the Toolserver domain?
I'm not sure if ALL servers are going to be removed or a basic Apache is going to run in the domain the next years.
Perhaps we can mantain a basic site, with the wiki, and a little museum?
Regards, emijrp
On 12/25/2013 03:05 PM, Emilio J. Rodríguez-Posada wrote:
I'm not sure if ALL servers are going to be removed or a basic Apache is going to run in the domain the next years.
Last I heard, the plan is to decommission and donate all the hardware.
If WMDE wants, the Foundation can take the domain and keep the redirects up indefinitely so that old links remain valid.
-- Marc
Hello,
On Wed, 25 Dec 2013, Marc A. Pelletier wrote:
I'm not sure if ALL servers are going to be removed or a basic Apache is going to run in the domain the next years.
Last I heard, the plan is to decommission and donate all the hardware.
If WMDE wants, the Foundation can take the domain and keep the redirects up indefinitely so that old links remain valid.
This is what we planned and why amette implemented the htaccess variant. You can put it into your home and even if you remove all your stuff with burnbridges the htaccess file will stay there if it has a labs url in it. WMF can get the files and the domain and host the redirects.
Cheers Marlen/nosy
Hi,
Am 25.12.2013 22:45, schrieb Marlen Caemmerer:
On Wed, 25 Dec 2013, Marc A. Pelletier wrote:
Last I heard, the plan is to decommission and donate all the hardware.
If WMDE wants, the Foundation can take the domain and keep the redirects up indefinitely so that old links remain valid.
as the domain registrar I may add that this has already been discussed with me. We are prepared to transfer the domain if needed. But there are also alternatives:
This is what we planned and why amette implemented the htaccess variant. You can put it into your home and even if you remove all your stuff with burnbridges the htaccess file will stay there if it has a labs url in it. WMF can get the files and the domain and host the redirects.
We may either keep one simple webserver running and point the old domain there in order to maintain redirects of the old URLs to the new scripts. We could also move this late to another server, eg. of Wikimedia CH which I could provide, so we can decomission the toolserver completely and save costs and management time while still maintain the redirects.
/Manuel
On 12/25/2013 04:57 PM, Manuel Schneider wrote:
We may either keep one simple webserver running and point the old domain there in order to maintain redirects of the old URLs to the new scripts. We could also move this late to another server, eg. of Wikimedia CH which I could provide, so we can decomission the toolserver completely and save costs and management time while still maintain the redirects.
Either way, the WMF with collaborate with whatever is decided in the end.
-- Marc
Manuel Schneider manuel.schneider@wikimedia.ch wrote:
[...]
This is what we planned and why amette implemented the htaccess variant. You can put it into your home and even if you remove all your stuff with burnbridges the htaccess file will stay there if it has a labs url in it. WMF can get the files and the domain and host the redirects.
We may either keep one simple webserver running and point the old domain there in order to maintain redirects of the old URLs to the new scripts. We could also move this late to another server, eg. of Wikimedia CH which I could provide, so we can decomission the toolserver completely and save costs and management time while still maintain the redirects.
I'm currently working on puppetizing tools-webproxy and the redirect server is just a few extra lines of configuration. So no servers outside of Labs are needed.
What would be interesting is a mail forwarder for the exist- ing toolserver.org addresses as a) WMF may be hesitant to provide this and b) mails with the senders' assumption on them being forwarded in Amsterdam instead being relayed in the US could be the source for endless drama.
Tim
Hi Tim,
Am 25.12.2013 23:14, schrieb Tim Landscheidt:
What would be interesting is a mail forwarder for the exist- ing toolserver.org addresses as a) WMF may be hesitant to provide this and b) mails with the senders' assumption on them being forwarded in Amsterdam instead being relayed in the US could be the source for endless drama.
should be no problem. WMCH is providing this service for its members anyway already, so it would be just a one-time setup effort, something I could easily do.
The mail addresses @toolserver.org are all just simple forwarders?
/Manuel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I would vote strongly to keep the wiki and also JIRA somewhere accessible. Both contain a serious amount of history and documentation.
Can that be done?
Greetings DrTrigon
On 25.12.2013 21:05, Emilio J. Rodríguez-Posada wrote:
Hi all;
I'm not sure if this has been discussed anywhere but, what will happen with the Toolserver domain?
I'm not sure if ALL servers are going to be removed or a basic Apache is going to run in the domain the next years.
Perhaps we can mantain a basic site, with the wiki, and a little museum?
Regards, emijrp
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Hey,
this would be very easy from the technical side. The host that does this is not part of the cluster but sits in the US. Still this host needs some sort of maintenance as long as its online so the perspective would probably be to reimport the data somewhere. Adding Coren so he can keep it in mind.
Cheers Marlen/nosy
On Sat, 18 Jan 2014, Dr. Trigon wrote:
Date: Sat, 18 Jan 2014 21:29:27 From: Dr. Trigon dr.trigon@surfeu.ch Reply-To: Wikimedia Toolserver toolserver-l@lists.wikimedia.org To: toolserver-l@lists.wikimedia.org Subject: Re: [Toolserver-l] What will happen with the Toolserver domain?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I would vote strongly to keep the wiki and also JIRA somewhere accessible. Both contain a serious amount of history and documentation.
Can that be done?
Greetings DrTrigon
On 25.12.2013 21:05, Emilio J. Rodríguez-Posada wrote:
Hi all;
I'm not sure if this has been discussed anywhere but, what will happen with the Toolserver domain?
I'm not sure if ALL servers are going to be removed or a basic Apache is going to run in the domain the next years.
Perhaps we can mantain a basic site, with the wiki, and a little museum?
Regards, emijrp
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLa5CYACgkQAXWvBxzBrDConACeKJlPvLQNPDMcYlC/NWyXzFVb HFQAmwd2pAy8lJiR4mX+Zh/PH3FIuVuk =OmfH -----END PGP SIGNATURE-----
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On 01/18/2014 03:29 PM, Dr. Trigon wrote:
I would vote strongly to keep the wiki and also JIRA somewhere accessible. Both contain a serious amount of history and documentation.
There is an issue about both living on non-free platforms we have to address before that's possible (I very much doubt that we can reasonably maintain either Jira or Confluence on our infrastructure).
I don't know how /useful/ they would be, but static copies might be appropriate; or we might need to find some other method by which to keep those for history.
-- Marc
On 01/18/2014 08:43 PM, Marc A. Pelletier wrote:
or Confluence on our infrastructure
For some reason, I was convinced that Confluence was used as wiki software on Toolserver. Given that this is in fact Mediawiki, keeping a historical copy for historical reasons is relatively simple and quite okay.
-- Marc
It was (or attempted) I believe at one stage, which is why you might of had that thought (see, you're not crazy!)
On 19 January 2014 11:54, Marc A. Pelletier marc@uberbox.org wrote:
On 01/18/2014 08:43 PM, Marc A. Pelletier wrote:
or Confluence on our infrastructure
For some reason, I was convinced that Confluence was used as wiki software on Toolserver. Given that this is in fact Mediawiki, keeping a historical copy for historical reasons is relatively simple and quite okay.
-- Marc
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
(anonymous) wrote:
I would vote strongly to keep the wiki and also JIRA somewhere accessible. Both contain a serious amount of history and documentation.
Can that be done?
[...]
These are two very different problems.
AFAICS the wiki can be moved rather easily; your mail trig- gered me to finally create the bug from my notes written long ago :-) (cf. https://bugzilla.wikimedia.org/60220). The Toolserver admins need to decouple the wiki from the Toolserver SSO and dump users and data, the WMF admins need to set up a (= just another) wiki without CentralAuth (wmgUseCentralAuth = false IIRC), load users and data, reset the/mail out new users' passwords and then wiki.toolserver.org needs to be set as a CNAME for text-lb.
JIRA however is much more complicated. You know from your own experience (https://jira.toolserver.org/browse/TS-748 has now been unresolved for over three years) that few of the Toolserver admins have time and knowledge with regard to JIRA, while in the WMF camp they have probably zero. So compared with MediaWiki where (security) updates will be regularly deployed with the rest of the cluster, someone would have to keep a dedicated eye on a totally foreign sys- tem. And we only have a free licence from Atlassian which could at some point be discontinued. On the other hand the benefits are very small as Merlijn wrote the fantastic JIRA/ Bugzilla importer which handles almost all cases.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 19.01.2014 03:21, Tim Landscheidt wrote:
These are two very different problems.
AFAICS the wiki can be moved rather easily; your mail trig- gered me to finally create the bug from my notes written long ago :-) (cf. https://bugzilla.wikimedia.org/60220). The Toolserver admins need to decouple the wiki from the Toolserver SSO and dump users and data, the WMF admins need to set up a (= just another) wiki without CentralAuth (wmgUseCentralAuth = false IIRC), load users and data, reset the/mail out new users' passwords and then wiki.toolserver.org needs to be set as a CNAME for text-lb.
That is good to hear! :) Thanks for your effort regarding this.
JIRA however is much more complicated. You know from your own experience (https://jira.toolserver.org/browse/TS-748 has now been unresolved for over three years) that few of the Toolserver admins have time and knowledge with regard to JIRA, while in the WMF camp they have probably zero. So compared with MediaWiki where (security) updates will be regularly deployed with the rest of the cluster, someone would have to keep a dedicated eye on a totally foreign sys- tem. And we only have a free licence from Atlassian which could at some point be discontinued. On the other hand the benefits are very small as Merlijn wrote the fantastic JIRA/ Bugzilla importer which handles almost all cases.
Yes I know those issues... ;) It is/was a pitty...
As far as I know, the JIRA/Bugzilla importer has issues as well, please confer https://bugzilla.wikimedia.org/show_bug.cgi?id=55673. It does e.g. NOT preserve relations between tickets and thus drops a serious amount of the history too. As I understand from the buzilla ticket this will not be resolved.
In my oppinion 1 of the 2 problems should be tackeled; * either keep a static copy of JIRA (may be just the DB along with a simple viewer written by us) * or improve JIRA/Bugzilla importer to a point where it can migrate relations between tickets and other stuff as well
Thanks for all your comments! Greetings DrTrigon
(anonymous) wrote:
[...]
JIRA however is much more complicated. You know from your own experience (https://jira.toolserver.org/browse/TS-748 has now been unresolved for over three years) that few of the Toolserver admins have time and knowledge with regard to JIRA, while in the WMF camp they have probably zero. So compared with MediaWiki where (security) updates will be regularly deployed with the rest of the cluster, someone would have to keep a dedicated eye on a totally foreign sys- tem. And we only have a free licence from Atlassian which could at some point be discontinued. On the other hand the benefits are very small as Merlijn wrote the fantastic JIRA/ Bugzilla importer which handles almost all cases.
Yes I know those issues... ;) It is/was a pitty...
As far as I know, the JIRA/Bugzilla importer has issues as well, please confer https://bugzilla.wikimedia.org/show_bug.cgi?id=55673. It does e.g. NOT preserve relations between tickets and thus drops a serious amount of the history too. As I understand from the buzilla ticket this will not be resolved.
In my oppinion 1 of the 2 problems should be tackeled;
- either keep a static copy of JIRA (may be just the DB along with a simple viewer written by us)
- or improve JIRA/Bugzilla importer to a point where it can migrate relations between tickets and other stuff as well
As I wrote last month in http://permalink.gmane.org/gmane.org.wikimedia.toolserver/6450, you can export an XML dump of your project's issues (you'll have to download attachments manually (or write a script for that)). This contains the links between issues. You can then store it in your software's repository or any other place and convert it to HTML, wiki pages, a book or one of those bubble movies - the world is your oyster.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 20.01.2014 17:26, Tim Landscheidt wrote:
As I wrote last month in http://permalink.gmane.org/gmane.org.wikimedia.toolserver/6450, you can export an XML dump of your project's issues (you'll have to download attachments manually (or write a script for that)). This contains the links between issues. You can then store it in your software's repository or any other place and convert it to HTML, wiki pages, a book or one of those bubble movies - the world is your oyster.
Please confer https://bugzilla.wikimedia.org/show_bug.cgi?id=55673#c26
[...]
I have now written an XSLT script - a viewer - that imitates [4], you can find it at [5]. An Example concerning this bug here is [6]. The entries can be linked directly as e.g. for DRTRIGON-68 [7] in order to be easily integrated with the bugs and bugzilla here.
[4] https://jira.toolserver.org/sr/jira.issueviews:searchrequest-fullcontent/tem... [5] http://tools.wmflabs.org/drtrigonbot/cgi-bin/xsalt.py?xslt=jira2html.xslt [6] http://tools.wmflabs.org/drtrigonbot/cgi-bin/xsalt.py?url=http%3A%2F%2Ftools... [7] http://tools.wmflabs.org/drtrigonbot/cgi-bin/xsalt.py?url=http%3A%2F%2Ftools...
At the moment all links are still pointing to TS JIRA as this can easily be changed after its shutdown. Then it might also be needed to replace the used icons by other ones from commons e.g.
As mentioned in [1], attachments, patches and the like have to be downloaded manually if needed. They can then e.g. be added here as well.
Just to make it VERY clear: EVERYBODY (on tool-labs) can use [5] with their exported xml files from jira. Please enjoy!
Greetings DrTrigon
toolserver-l@lists.wikimedia.org