cs-studio-core — CSS core developer only

Re: [Cs-studio-core] cvs to mercurial migration

[Hatje, J. <jan...@de...>]

Hi,

I have added now the Desy plug-ins and features to the Migration List on
Source Forge.
Because of our headless CSS Applications I had to add a lot of more. 
And some plug-ins are in separated CVS repositories, sorry. Could you
please add the repositories
'css-ams', 'css-dct', 'css-sds' and 'SNL' to your conversion scripts?

Based on your repository 'css-cvs2hg-simple' our Hudson server is now
able to build a 
CSS demo project and we tested the Eclipse IDE with the Mercurial
plug-in. It look all fine
except of the mercurial icons in the Eclipse package explorer. Modified
files are sometimes
not marked with the small 'star' icon of mercurial. Do you have an idea
what is wrong?
We are using Eclipse 3.6.0 with MercurialEclipse 1.6.0.

Best regards,
Jan 





>-----Original Message-----
>From: Carcassi, Gabriele [mailto:car...@bn...] 
>Sent: Friday, July 02, 2010 10:21 PM
>To: cs-...@li...
>Subject: Re: [Cs-studio-core] cvs to mercurial migration
>
>
>> Seems to me that we have multiple demo setups on SF...
>Sorry for the confusion. Let's see if I can clarify.
>
>We (Kunal and I) are expecting from someone at Desy (Jan?) and 
>someone at SNS (Kay?) to have a look at css-cvs2hg-simple and tell us:
>1) Whether the CVS->HG conversion happened to their satisfaction
>2) Fill in the list of plugins they want to move on the wiki 
>at 
>https://sourceforge.net/apps/trac/cs-studio/wiki/PluginsAndFeat
>uresList.
>Plugins that are not put there, are not going to be brought 
>over to minimize the size of the repository.
>3) Tell us what to do with the branches: we drop them? Do you 
>want them? Do they need to be merged?
>
>Once we have that information, we will create the "css-main" 
>repository and junk the rest. At that point I think your plan 
>sounds good: we give a month time to test and correct it. But 
>first we'd like the information above.
>
>To expedite the process: do people see useful organizing a 
>phone meeting where we actually do some (if not most) of the work?
>
>Gabriele
>
>
>-----Original Message-----
>From: Kasemir, Kay [mailto:kas...@or...] 
>Sent: Friday, July 02, 2010 12:28 PM
>To: cs-...@li...
>Subject: Re: [Cs-studio-core] cvs to mercurial migration
>
>Hi:
>
>What is our time line for moving to Mercurial/SF?
>
>Fundamentally, I think
> css-cvs2hg-simple/css-core
> css-cvs2hg-simple/css-applications
>looks OK, except for quirks: Why are there CVSROOT 
>directories? In css-applications, the top-level files 
>.classpath, .project, ..., plugin.xml seem to be out of place.
>
>How does this fit with the css-repo-strawman?
>Does css-repo-strawman represent the overall layout
> build/
> core/
> applications/
> products/
>but with only a few actual plugins? On the other hand, 
>css-cvs2hg-simple has a fully populated list of core and 
>applications plugins, but lacks the 'build'?
>
>
>Seems to me that we have multiple demo setups on SF, but none 
>are complete and their name already indicates that they're not 
>what we want in the end.
>
>How about this:
>
>BNL sets up _THE_ repository with the final name and layout. 
>For example called "cs-studio", not simple, strawman, ....
>
>It includes all that you think it should include.
>
>It imports plugins from DESY CVS. Maybe it actually includes 
>the CVS history, but if a lot of time and space can be saved, 
>maybe it only has the latest snapshot. It works for building 
>the NSLS2 product.
>
>Other sites can look at that, try it, comment, but we don't 
>write to it. When we don't like something, BNL can totally 
>re-create it from scratch according to suggestions. We're in a 
>phase of creating the setup, not using it.
>
>In about a month, we then switch over to using that as the 
>shared repository where others can also write/change.
>
>Would that work?
>
>Thanks,
>Kay
>
>
>
>
>
>
>
>
>On 7/1/10 07:12 , "Carcassi, Gabriele" <car...@bn...> wrote:
>> The site specific plugins already go under product/feature, so they
>are
>> already separate. We were thinking of keeping all the other
>applications
>> plugins under the same level because ...
>
>> From: Hatje, Jan [mailto:jan...@de...]
>> Because we are now very busy with our new CSS version I have had few
>time to
>> test the headless build with mercurial....
>
>>> From: Shroff, Kunal [mailto:sh...@bn...]
>>> I wanted to pick up the discussion regarding the migration 
>of the css 
>>> repository from cvs to hg.
>...
>>> Using this we have converted the entire css-core and 
>css-applications 
>>> directories from the desy repository and published this example on 
>>> sourceforge
>>>
>(http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple)
>. I
>>> intend this repository to only be a demo for us to look at how the
>imported
>>> history looks
>
>---------------------------------------------------------------
>---------
>------
>This SF.net email is sponsored by Sprint
>What will you do first with EVO, the first 4G phone?
>Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>_______________________________________________
>Cs-studio-core mailing list Cs-...@li...
>https://lists.sourceforge.net/lists/listinfo/cs-studio-core
>
>---------------------------------------------------------------
>---------------
>This SF.net email is sponsored by Sprint
>What will you do first with EVO, the first 4G phone?
>Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>_______________________________________________
>Cs-studio-core mailing list Cs-...@li...
>https://lists.sourceforge.net/lists/listinfo/cs-studio-core
>

Re: [Cs-studio-core] cvs to mercurial migration

[Kunal s. <sh...@bn...>]

Hello,

> Thank you for converting the cvs repository. I imported the platform
> plug-ins without any problems. But the structure of the applications
> folder
> is somehow wrong. Mercurial imports all application plug-ins as a
> subfolder
> of project 'kryoNameBrowser'.
>   

This is a strange - while I was able to reproduce it i am not sure why 
the cvs import reorganizes the plugins from the applications folder in 
this manner (maybe the multiple CVSROOT directories are confusing cvsps???).

However after the second step of the conversion 
(http://sourceforge.net/apps/trac/cs-studio/wiki/MigrationProcedure) - 
using the filemap to reorganize the plugins and features into the new 
architecture this problem is solved and a mercurial import correctly 
imports all the plugins into the workspace without putting them under 
kryoNameBrowser.

sincerely
Kunal

Re: [Cs-studio-core] cvs to mercurial migration

[Hatje, J. <jan...@de...>]

Hi,

>We (Kunal and I) are expecting from someone at Desy (Jan?) and 
>someone at SNS (Kay?) to have a look at css-cvs2hg-simple and tell us:
>1) Whether the CVS->HG conversion happened to their satisfaction

Thank you for converting the cvs repository. I imported the platform
plug-ins without any problems. But the structure of the applications
folder
is somehow wrong. Mercurial imports all application plug-ins as a
subfolder
of project 'kryoNameBrowser'. 

>2) Fill in the list of plugins they want to move on the wiki 
>at 
>https://sourceforge.net/apps/trac/cs-studio/wiki/PluginsAndFeat
>uresList.
>Plugins that are not put there, are not going to be brought 
>over to minimize the size of the repository.

ok

>3) Tell us what to do with the branches: we drop them? Do you 
>want them? Do they need to be merged?

At DESY we are now using just the branch for our version 130, but it is
not necessary to convert it. The other DESY branches are all merged or
outdated. 

Best regards,
Jan

Re: [Cs-studio-core] cvs to mercurial migration

[Carcassi, G. <car...@bn...>]

> Seems to me that we have multiple demo setups on SF...
Sorry for the confusion. Let's see if I can clarify.

We (Kunal and I) are expecting from someone at Desy (Jan?) and someone
at SNS (Kay?) to have a look at css-cvs2hg-simple and tell us:
1) Whether the CVS->HG conversion happened to their satisfaction
2) Fill in the list of plugins they want to move on the wiki at
https://sourceforge.net/apps/trac/cs-studio/wiki/PluginsAndFeaturesList.
Plugins that are not put there, are not going to be brought over to
minimize the size of the repository.
3) Tell us what to do with the branches: we drop them? Do you want them?
Do they need to be merged?

Once we have that information, we will create the "css-main" repository
and junk the rest. At that point I think your plan sounds good: we give
a month time to test and correct it. But first we'd like the information
above.

To expedite the process: do people see useful organizing a phone meeting
where we actually do some (if not most) of the work?

Gabriele


-----Original Message-----
From: Kasemir, Kay [mailto:kas...@or...] 
Sent: Friday, July 02, 2010 12:28 PM
To: cs-...@li...
Subject: Re: [Cs-studio-core] cvs to mercurial migration

Hi:

What is our time line for moving to Mercurial/SF?

Fundamentally, I think
 css-cvs2hg-simple/css-core
 css-cvs2hg-simple/css-applications
looks OK, except for quirks: Why are there CVSROOT directories? In
css-applications, the top-level files .classpath, .project, ...,
plugin.xml seem to be out of place.

How does this fit with the css-repo-strawman?
Does css-repo-strawman represent the overall layout
 build/
 core/
 applications/
 products/
but with only a few actual plugins? On the other hand, css-cvs2hg-simple
has a fully populated list of core and applications plugins, but lacks
the 'build'?


Seems to me that we have multiple demo setups on SF, but none are
complete and their name already indicates that they're not what we want
in the end.

How about this:

BNL sets up _THE_ repository with the final name and layout. For example
called "cs-studio", not simple, strawman, ....

It includes all that you think it should include.

It imports plugins from DESY CVS. Maybe it actually includes the CVS
history, but if a lot of time and space can be saved, maybe it only has
the latest snapshot.
It works for building the NSLS2 product.

Other sites can look at that, try it, comment, but we don't write to it.
When we don't like something, BNL can totally re-create it from scratch
according to suggestions. We're in a phase of creating the setup, not
using it.

In about a month, we then switch over to using that as the shared
repository where others can also write/change.

Would that work?

Thanks,
Kay








On 7/1/10 07:12 , "Carcassi, Gabriele" <car...@bn...> wrote:
> The site specific plugins already go under product/feature, so they
are
> already separate. We were thinking of keeping all the other
applications
> plugins under the same level because ...

> From: Hatje, Jan [mailto:jan...@de...]
> Because we are now very busy with our new CSS version I have had few
time to
> test the headless build with mercurial....

>> From: Shroff, Kunal [mailto:sh...@bn...]
>> I wanted to pick up the discussion regarding the migration of the css
>> repository from cvs to hg.
...
>> Using this we have converted the entire css-core and css-applications
>> directories from the desy repository and published this example on
>> sourceforge
>>
(http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple)
. I
>> intend this repository to only be a demo for us to look at how the
imported
>> history looks

------------------------------------------------------------------------
------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Cs-studio-core mailing list
Cs-...@li...
https://lists.sourceforge.net/lists/listinfo/cs-studio-core

Re: [Cs-studio-core] cvs to mercurial migration

[Kasemir, K. <kas...@or...>]

Hi:

What is our time line for moving to Mercurial/SF?

Fundamentally, I think
 css-cvs2hg-simple/css-core
 css-cvs2hg-simple/css-applications
looks OK, except for quirks: Why are there CVSROOT directories? In css-applications, the top-level files .classpath, .project, ..., plugin.xml seem to be out of place.

How does this fit with the css-repo-strawman?
Does css-repo-strawman represent the overall layout
 build/
 core/
 applications/
 products/
but with only a few actual plugins? On the other hand, css-cvs2hg-simple has a fully populated list of core and applications plugins, but lacks the 'build'?


Seems to me that we have multiple demo setups on SF, but none are complete and their name already indicates that they're not what we want in the end.

How about this:

BNL sets up _THE_ repository with the final name and layout. For example called "cs-studio", not simple, strawman, ....

It includes all that you think it should include.

It imports plugins from DESY CVS. Maybe it actually includes the CVS history, but if a lot of time and space can be saved, maybe it only has the latest snapshot.
It works for building the NSLS2 product.

Other sites can look at that, try it, comment, but we don't write to it. When we don't like something, BNL can totally re-create it from scratch according to suggestions. We're in a phase of creating the setup, not using it.

In about a month, we then switch over to using that as the shared repository where others can also write/change.

Would that work?

Thanks,
Kay








On 7/1/10 07:12 , "Carcassi, Gabriele" <car...@bn...> wrote:
> The site specific plugins already go under product/feature, so they are
> already separate. We were thinking of keeping all the other applications
> plugins under the same level because ...

> From: Hatje, Jan [mailto:jan...@de...]
> Because we are now very busy with our new CSS version I have had few time to
> test the headless build with mercurial....

>> From: Shroff, Kunal [mailto:sh...@bn...]
>> I wanted to pick up the discussion regarding the migration of the css
>> repository from cvs to hg.
...
>> Using this we have converted the entire css-core and css-applications
>> directories from the desy repository and published this example on
>> sourceforge
>> (http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple) . I
>> intend this repository to only be a demo for us to look at how the imported
>> history looks

Re: [Cs-studio-core] cvs to mercurial migration

[Carcassi, G. <car...@bn...>]

Hi Jan:

 

The site specific plugins already go under product/feature, so they are
already separate. We were thinking of keeping all the other applications
plugins under the same level because eclipse is not able to find
dependencies by itself. This means that, whenever one does a pull of the
new changes, he/she has to look in all the plugins directories to see if
something new was put there. To minimize the number of directories one
has to look in, we were thinking of keeping them to  core/plugins,
applications/plugins and applications/features plus the site specific
directories.

 

What one would do in eclipse is to import all the plugins, open only the
one he/she is interested (by using the open with dependencies) and then
create a filter to show only those projects. It's the best compromise we
could find...

 

Gabriele 

 

From: Hatje, Jan [mailto:jan...@de...] 
Sent: Thursday, July 01, 2010 4:26 AM
To: Shroff, Kunal; cs-...@li...
Subject: Re: [Cs-studio-core] cvs to mercurial migration

 

Hello,

Because we are now very busy with our new CSS version I have had few
time to test the headless build with mercurial. But I suppose that your
demo repository css-cvs2hg-simple makes the Hudson test easier because
we can use the most of the current configuration.

I will add the plug-ins for our CSS product to the migration list. But I
have to add ca. 100 more plug-ins. Do you think we should split the
application folder in application-common, application-nsls2,...?

Best regards,

Jan 

	-----Original Message-----
	From: Shroff, Kunal [mailto:sh...@bn...] 
	Sent: Wednesday, June 30, 2010 2:40 PM
	To: cs-...@li...
	Subject: [Cs-studio-core] cvs to mercurial migration

	Hello,

	 

	I wanted to pick up the discussion regarding the migration of
the css repository from cvs to hg.

	We have set up a method to successfully convert the cvs
repository to mercurial with the history. While hg convert was useful
for smaller conversions (I used it to convert databrowser and boy) for
converting the entire repository indirect conversion using git cvsimport
proved easier, It overcame certain cvsps errors.

	 

	Using this we have converted the entire css-core and
css-applications directories from the desy repository and published this
example on sourceforge
(http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple)
. I intend this repository to only be a demo for us to look at how the
imported history looks (and check if all of it gets through the way we
want it). 

	 

	I have also created a wiki page
(https://sourceforge.net/apps/trac/cs-studio/wiki/MercurialMigration)
with a list of plugins and features organized according to the new
architecture. I have only added the plugins and features currently being
used by our product. The first step for the migration would involve
adding all the plugins and features required by our respective products
to the appropriate lists - using these lists we can then create the new
mercurial repository. We could use this step as the first round of
cleanup - avoiding addition of unnecessary plugins would ensure that the
history does not get too big.

	 

	Sincerely

	Kunal

	 

Re: [Cs-studio-core] cvs to mercurial migration

[Hatje, J. <jan...@de...>]

Hello,

Because we are now very busy with our new CSS version I have had few
time to test the headless build with mercurial. But I suppose that your
demo repository css-cvs2hg-simple makes the Hudson test easier because
we can use the most of the current configuration.

I will add the plug-ins for our CSS product to the migration list. But I
have to add ca. 100 more plug-ins. Do you think we should split the
application folder in application-common, application-nsls2,...?

Best regards,

Jan 

	-----Original Message-----
	From: Shroff, Kunal [mailto:sh...@bn...] 
	Sent: Wednesday, June 30, 2010 2:40 PM
	To: cs-...@li...
	Subject: [Cs-studio-core] cvs to mercurial migration
	
	

	Hello,

	 

	I wanted to pick up the discussion regarding the migration of
the css repository from cvs to hg.

	We have set up a method to successfully convert the cvs
repository to mercurial with the history. While hg convert was useful
for smaller conversions (I used it to convert databrowser and boy) for
converting the entire repository indirect conversion using git cvsimport
proved easier, It overcame certain cvsps errors.

	 

	Using this we have converted the entire css-core and
css-applications directories from the desy repository and published this
example on sourceforge
(http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple)
. I intend this repository to only be a demo for us to look at how the
imported history looks (and check if all of it gets through the way we
want it). 

	 

	I have also created a wiki page
(https://sourceforge.net/apps/trac/cs-studio/wiki/MercurialMigration)
with a list of plugins and features organized according to the new
architecture. I have only added the plugins and features currently being
used by our product. The first step for the migration would involve
adding all the plugins and features required by our respective products
to the appropriate lists - using these lists we can then create the new
mercurial repository. We could use this step as the first round of
cleanup - avoiding addition of unnecessary plugins would ensure that the
history does not get too big.

	 

	Sincerely

	Kunal

	 

[Cs-studio-core] cvs to mercurial migration

[Shroff, K. <sh...@bn...>]

Hello,

 

I wanted to pick up the discussion regarding the migration of the css
repository from cvs to hg.

We have set up a method to successfully convert the cvs repository to
mercurial with the history. While hg convert was useful for smaller
conversions (I used it to convert databrowser and boy) for converting
the entire repository indirect conversion using git cvsimport proved
easier, It overcame certain cvsps errors.

 

Using this we have converted the entire css-core and css-applications
directories from the desy repository and published this example on
sourceforge
(http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/css-cvs2hg-simple)
. I intend this repository to only be a demo for us to look at how the
imported history looks (and check if all of it gets through the way we
want it). 

 

I have also created a wiki page
(https://sourceforge.net/apps/trac/cs-studio/wiki/MercurialMigration)
with a list of plugins and features organized according to the new
architecture. I have only added the plugins and features currently being
used by our product. The first step for the migration would involve
adding all the plugins and features required by our respective products
to the appropriate lists - using these lists we can then create the new
mercurial repository. We could use this step as the first round of
cleanup - avoiding addition of unnecessary plugins would ensure that the
history does not get too big.

 

Sincerely

Kunal

 

Re: [Cs-studio-core] RightsManagementService listeners never used? Re: Memory leak in org.csstudio.platform.*.security

[Hatje, J. <jan...@de...>]

Hi,

we have tested your modifications and do not see any problems for our
plug-ins.

Thank you for the bug fix!

Best regards
Jan

>-----Original Message-----
>From: Kasemir, Kay [mailto:kas...@or...] 
>Sent: Thursday, June 24, 2010 8:41 PM
>To: cs-...@li...
>Subject: Re: [Cs-studio-core] RightsManagementService 
>listeners never used? Re: Memory leak in 
>org.csstudio.platform.*.security
>
>
>Hi:
>
>I changed the SecurityFacade to use weak references to 
>registered listeners.
>
>In the RightsManagementService, I remove the previously unused 
>listener list, leaving 
>addRightsManagementListener/removeListener as @deprectated in 
>case somebody still calls those.
>
>With those changes to ActivationService, ActivatableList, 
>ObjectAdapterTupel, SecurityFacade, RightsManagementService 
>and AbstractUserDependentAction I see no more memory leaks 
>from autorization-dependent UI actions.
>
>Thanks,
>Kay
>
>
>---------------------------------------------------------------
>---------------
>ThinkGeek and WIRED's GeekDad team up for the Ultimate 
>GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
>lucky parental unit.  See the prize list and enter to win: 
>http://p.sf.net/sfu/thinkgeek-promo
>_______________________________________________
>Cs-studio-core mailing list Cs-...@li...
>https://lists.sourceforge.net/lists/listinfo/cs-studio-core
>

Re: [Cs-studio-core] RightsManagementService listeners never used? Re: Memory leak in org.csstudio.platform.*.security

[Kasemir, K. <kas...@or...>]

Hi:

I changed the SecurityFacade to use weak references to registered listeners.

In the RightsManagementService, I remove the previously unused listener
list, leaving addRightsManagementListener/removeListener as @deprectated in
case somebody still calls those.

With those changes to ActivationService, ActivatableList,
ObjectAdapterTupel, SecurityFacade, RightsManagementService and
AbstractUserDependentAction I see no more memory leaks from
autorization-dependent UI actions.

Thanks,
Kay

[Cs-studio-core] RightsManagementService listeners never used? Re: Memory leak in org.csstudio.platform.*.security

[Kasemir, K. <kas...@or...>]

Hi:

Looking at the RightsManagementService , I was about to replace the listener
list in there with a weak-link list to prevent memory leaks with for example
AbstractUserDependentAction instances that are used in dynamically created
context menues which register, but have no good way to ever unregister.

Then I noticed that the RightsManagementService._listener list is never
used:
The AbstractUserDependentAction registers in the list, maybe others do, too.
In principle there is an API to unregister, but the listeners are never
invoked.

So the easiest fix would be to simply delete the
RightsManagementService._listener list (and add/removeListener calls).

Anybody opposed to this?

Thanks,
Kay


On 6/24/10 09:24 , "Kay Kasemir" <kas...@or...> wrote:

> Hi:
> 
> I've updated the ActivationService  (ActivatableList, ObjectAdapterTupel) to
> use WeakReferences to the registered objects, so according to JProfiler it no
> longer keeps actions from being garbage collected.
> 
> But it turns out that the CSS SecurityFacade and RightsManagementService also
> use hard references to each AbstractUserDependentAction, so I'll try to update
> those as well.
> 
> Thanks,
> Kay

Re: [Cs-studio-core] Memory leak in org.csstudio.platform.*.security

[Kasemir, K. <kas...@or...>]

Hi:

I've updated the ActivationService  (ActivatableList, ObjectAdapterTupel) to
use WeakReferences to the registered objects, so according to JProfiler it
no longer keeps actions from being garbage collected.

But it turns out that the CSS SecurityFacade and RightsManagementService
also use hard references to each AbstractUserDependentAction, so I'll try to
update those as well.

Thanks,
Kay

[Cs-studio-core] Memory leak in org.csstudio.platform.*.security

[Kasemir, K. <kas...@or...>]

Hi:

I've been looking at CSS under JProfiler, which has been simply amazing in
finding CPU and memory issues.

One thing that I can clearly see in there, but I have no good idea how to
fix it because I've never dealt with the related code is a memory leak in
org.csstudio.platform.*.security:

When you have a UI action that's based on

org.csstudio.platform.ui.security.AbstractUserDependentAction

i.e. an action that automatically enables/disables based on the rights of
the currently logged in user, that AbstractUserDependentAction registers
itself with the ActivationService.
But it never un-registers.
There is code in AbstractUserDependentAction.finalize() to un-register, but
that code is never called because as long as the ActivationService has a
link to the AbstractUserDependentAction, the JVM won't try to
garbage-collect and finalize the AbstractUserDependentAction.

This can lead to leaked memory for security-aware actions that are
dynamically added to context menues: Each invocation of the context menu
will create the security-aware action, and it's never removed.


It seems to me the most transparent way to fix this would be to use weak
references in the ActivationService: This would allow registered widgets to
be garbage-collected.

Or change every piece of code that uses the AbstractUserDependentAction to
somehow un-register it.

Suggestions?

Thanks,
Kay

[Cs-studio-core] Welcome... and test

[Kasemir, K. <kas...@or...>]

Welcome to the CSS 'core' list!

If you can read this, the list is working.

Since the SourceForge mailing list archive had an error because "mailing
list .. had no e-mails sent to it", this should fix it.

Thanks,
Kay

[Cs-studio-core] CSS mailing lists at DESY now attached to the sourceforge mailing lists

[Matthias C. <Mat...@de...>]

Hi all.

As of today (you have seen from the previous mails) the DESY CSS mailing 
lists are registered in the CS-Studio mailing lists at SourceForge.

So if you send your mail to
CSS-Users <cs-...@li...>
or
CSS-Core <cs-...@li...>

They will be forwarded to the mailing lists at DESY.
(There's no forward the other way around!)

This will open the chance to use the mailing lists either way.
You can choose the preferred list yourself.

Have a nice weekend!
Regards
Matthias

-- 
------------------------------------------------------------------------
Matthias Clausen                         Cryogenic Controls Group(MKS-2)
phone:  +49-40-8998-3256                Deutsches Elektronen Synchrotron
fax:    +49-40-8994-3256                                    Notkestr. 85
e-mail: Mat...@de...                           22607 Hamburg
WWW-MKS2.desy.de                                                 Germany
------------------------------------------------------------------------