generating test data

As the desktop team turns attention to performance, we're
revisiting the
test data set that we've been using for performance
metrics.

I'm not sure if we ought to coordinate desktop and server
team efforts
wrt test data -- sending this to both teams in case this
turns out to be
the case.

Previously, we generated a set of calendar data and have
stored that in
an ics file (tools/cats/datafiles/Generated3000.ics). The
size of the
calendar and some of the characteristics were based on
Mitch's calendar
at the time.

We're now at a point where we'd like to have a data set that
is
- based on real users' data
- contains multiple collections
- contains tasks, notes, messages in addition to calendar
data (a data
set that reflects the Preview feature set)

Instead of storing test data in .ics files, it makes sense
to use our
new eim-based format. We'd like to start out with real user
data, then
obfuscate the data to protect the innocent.

Morgen has checked in a tool that allows us to obfuscate a
"dump" file
from the desktop app. (Thanks Morgen!)

 From Morgen:
> So yesterday I checked in Tools > Save and Restore
> Obfuscated dump
> to file...
> 
> It sets an obfuscation attribute to True on the
translator object,
> and then the various exporter callbacks honor its
setting, instead
> emitting X's for the appropriate fields, and skipping a
bunch of item
> types such as accounts and passwords altogether.  The
one thing I'm
> not sure about obfuscating is the mail item and all its
various
> fields.  Does it matter if email addresses are included
in these
> dumps?  If so, someone will have to go and tweak
export_mail( ) in
> translator.py to obfuscate the appropriate fields.
> 

So from here:
- Should we tweak mail addresses to use test accounts?
(looking to Brian 
Kirsch here)
- Can we make use of this tool or data for server
performance efforts? 
If so, any next actions?

Cheers,
Katie

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I don't know about anyone else, but it seems reasonable to
me for the  
desktop and server to be working from the same datasets,
since we are  
also evaluation workflows that cross the two products.

What do other people think?

Ted

On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante wrote:

> As the desktop team turns attention to performance,
we're  
> revisiting the
> test data set that we've been using for performance
metrics.
>
> I'm not sure if we ought to coordinate desktop and
server team efforts
> wrt test data -- sending this to both teams in case
this turns out  
> to be
> the case.
>
> Previously, we generated a set of calendar data and
have stored  
> that in
> an ics file (tools/cats/datafiles/Generated3000.ics).
The size of the
> calendar and some of the characteristics were based on
Mitch's  
> calendar
> at the time.
>
> We're now at a point where we'd like to have a data set
that is
> - based on real users' data
> - contains multiple collections
> - contains tasks, notes, messages in addition to
calendar data (a data
> set that reflects the Preview feature set)
>
> Instead of storing test data in .ics files, it makes
sense to use our
> new eim-based format. We'd like to start out with real
user data, then
> obfuscate the data to protect the innocent.
>
> Morgen has checked in a tool that allows us to
obfuscate a "dump" file
> from the desktop app. (Thanks Morgen!)
>
> From Morgen:
>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>> to file...
>> It sets an obfuscation attribute to True on the
translator object,
>> and then the various exporter callbacks honor its
setting, instead
>> emitting X's for the appropriate fields, and
skipping a bunch of item
>> types such as accounts and passwords altogether. 
The one thing I'm
>> not sure about obfuscating is the mail item and all
its various
>> fields.  Does it matter if email addresses are
included in these
>> dumps?  If so, someone will have to go and tweak
export_mail( ) in
>> translator.py to obfuscate the appropriate fields.
>
> So from here:
> - Should we tweak mail addresses to use test accounts?
(looking to  
> Brian Kirsch here)
> - Can we make use of this tool or data for server
performance  
> efforts? If so, any next actions?
>
> Cheers,
> Katie
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I don't know about anyone else, but it seems reasonable to
me for the  
desktop and server to be working from the same datasets,
since we are  
also evaluation workflows that cross the two products.

What do other people think?

Ted

On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante wrote:

> As the desktop team turns attention to performance,
we're  
> revisiting the
> test data set that we've been using for performance
metrics.
>
> I'm not sure if we ought to coordinate desktop and
server team efforts
> wrt test data -- sending this to both teams in case
this turns out  
> to be
> the case.
>
> Previously, we generated a set of calendar data and
have stored  
> that in
> an ics file (tools/cats/datafiles/Generated3000.ics).
The size of the
> calendar and some of the characteristics were based on
Mitch's  
> calendar
> at the time.
>
> We're now at a point where we'd like to have a data set
that is
> - based on real users' data
> - contains multiple collections
> - contains tasks, notes, messages in addition to
calendar data (a data
> set that reflects the Preview feature set)
>
> Instead of storing test data in .ics files, it makes
sense to use our
> new eim-based format. We'd like to start out with real
user data, then
> obfuscate the data to protect the innocent.
>
> Morgen has checked in a tool that allows us to
obfuscate a "dump" file
> from the desktop app. (Thanks Morgen!)
>
> From Morgen:
>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>> to file...
>> It sets an obfuscation attribute to True on the
translator object,
>> and then the various exporter callbacks honor its
setting, instead
>> emitting X's for the appropriate fields, and
skipping a bunch of item
>> types such as accounts and passwords altogether. 
The one thing I'm
>> not sure about obfuscating is the mail item and all
its various
>> fields.  Does it matter if email addresses are
included in these
>> dumps?  If so, someone will have to go and tweak
export_mail( ) in
>> translator.py to obfuscate the appropriate fields.
>
> So from here:
> - Should we tweak mail addresses to use test accounts?
(looking to  
> Brian Kirsch here)
> - Can we make use of this tool or data for server
performance  
> efforts? If so, any next actions?
>
> Cheers,
> Katie
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

+1 on using the same test data for both Desktop and Server
performance.

Also we could use our test accounts demo1, demo2 etc for
email  
addresses in case we cannot replace it with some junk.

(bkirsch, can you confirm....in case you missed there is a
question  
waiting for your confirmation at the end of this email)

On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante wrote:

> As the desktop team turns attention to performance,
we're  
> revisiting the
> test data set that we've been using for performance
metrics.
>
> I'm not sure if we ought to coordinate desktop and
server team efforts
> wrt test data -- sending this to both teams in case
this turns out  
> to be
> the case.
>
> Previously, we generated a set of calendar data and
have stored  
> that in
> an ics file (tools/cats/datafiles/Generated3000.ics).
The size of the
> calendar and some of the characteristics were based on
Mitch's  
> calendar
> at the time.
>
> We're now at a point where we'd like to have a data set
that is
> - based on real users' data
> - contains multiple collections
> - contains tasks, notes, messages in addition to
calendar data (a data
> set that reflects the Preview feature set)
>
> Instead of storing test data in .ics files, it makes
sense to use our
> new eim-based format. We'd like to start out with real
user data, then
> obfuscate the data to protect the innocent.
>
> Morgen has checked in a tool that allows us to
obfuscate a "dump" file
> from the desktop app. (Thanks Morgen!)
>
> From Morgen:
>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>> to file...
>> It sets an obfuscation attribute to True on the
translator object,
>> and then the various exporter callbacks honor its
setting, instead
>> emitting X's for the appropriate fields, and
skipping a bunch of item
>> types such as accounts and passwords altogether. 
The one thing I'm
>> not sure about obfuscating is the mail item and all
its various
>> fields.  Does it matter if email addresses are
included in these
>> dumps?  If so, someone will have to go and tweak
export_mail( ) in
>> translator.py to obfuscate the appropriate fields.
>
> So from here:
> - Should we tweak mail addresses to use test accounts?
(looking to  
> Brian Kirsch here)
> - Can we make use of this tool or data for server
performance  
> efforts? If so, any next actions?
>
> Cheers,
> Katie
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

+1 on using the same test data for both Desktop and Server
performance.

Also we could use our test accounts demo1, demo2 etc for
email  
addresses in case we cannot replace it with some junk.

(bkirsch, can you confirm....in case you missed there is a
question  
waiting for your confirmation at the end of this email)

On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante wrote:

> As the desktop team turns attention to performance,
we're  
> revisiting the
> test data set that we've been using for performance
metrics.
>
> I'm not sure if we ought to coordinate desktop and
server team efforts
> wrt test data -- sending this to both teams in case
this turns out  
> to be
> the case.
>
> Previously, we generated a set of calendar data and
have stored  
> that in
> an ics file (tools/cats/datafiles/Generated3000.ics).
The size of the
> calendar and some of the characteristics were based on
Mitch's  
> calendar
> at the time.
>
> We're now at a point where we'd like to have a data set
that is
> - based on real users' data
> - contains multiple collections
> - contains tasks, notes, messages in addition to
calendar data (a data
> set that reflects the Preview feature set)
>
> Instead of storing test data in .ics files, it makes
sense to use our
> new eim-based format. We'd like to start out with real
user data, then
> obfuscate the data to protect the innocent.
>
> Morgen has checked in a tool that allows us to
obfuscate a "dump" file
> from the desktop app. (Thanks Morgen!)
>
> From Morgen:
>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>> to file...
>> It sets an obfuscation attribute to True on the
translator object,
>> and then the various exporter callbacks honor its
setting, instead
>> emitting X's for the appropriate fields, and
skipping a bunch of item
>> types such as accounts and passwords altogether. 
The one thing I'm
>> not sure about obfuscating is the mail item and all
its various
>> fields.  Does it matter if email addresses are
included in these
>> dumps?  If so, someone will have to go and tweak
export_mail( ) in
>> translator.py to obfuscate the appropriate fields.
>
> So from here:
> - Should we tweak mail addresses to use test accounts?
(looking to  
> Brian Kirsch here)
> - Can we make use of this tool or data for server
performance  
> efforts? If so, any next actions?
>
> Cheers,
> Katie
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

>> - Should we tweak mail addresses to use test
accounts? (looking to  
>> Brian Kirsch here)

So to make sure I have this correct. You are advocating
replacing  
real user email addresses
with the OSAF demo account email addresses when generating /
  
obfuscating the test data.

+1 I don't see an issue with this.  We do need to be careful
with  
demo accounts
in general though since they are used by our CATS testing
framework  
and myself
for debugging.



-Brian





On Apr 11, 2007, at 11:29 AM, Aparna Kadakia wrote:

> +1 on using the same test data for both Desktop and
Server  
> performance.
>
> Also we could use our test accounts demo1, demo2 etc
for email  
> addresses in case we cannot replace it with some junk.
>
> (bkirsch, can you confirm....in case you missed there
is a question  
> waiting for your confirmation at the end of this
email)
>
> On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante
wrote:
>
>> As the desktop team turns attention to performance,
we're  
>> revisiting the
>> test data set that we've been using for performance
metrics.
>>
>> I'm not sure if we ought to coordinate desktop and
server team  
>> efforts
>> wrt test data -- sending this to both teams in case
this turns out  
>> to be
>> the case.
>>
>> Previously, we generated a set of calendar data and
have stored  
>> that in
>> an ics file
(tools/cats/datafiles/Generated3000.ics). The size of the
>> calendar and some of the characteristics were based
on Mitch's  
>> calendar
>> at the time.
>>
>> We're now at a point where we'd like to have a data
set that is
>> - based on real users' data
>> - contains multiple collections
>> - contains tasks, notes, messages in addition to
calendar data (a  
>> data
>> set that reflects the Preview feature set)
>>
>> Instead of storing test data in .ics files, it
makes sense to use our
>> new eim-based format. We'd like to start out with
real user data,  
>> then
>> obfuscate the data to protect the innocent.
>>
>> Morgen has checked in a tool that allows us to
obfuscate a "dump"  
>> file
>> from the desktop app. (Thanks Morgen!)
>>
>> From Morgen:
>>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>>> to file...
>>> It sets an obfuscation attribute to True on the
translator object,
>>> and then the various exporter callbacks honor
its setting, instead
>>> emitting X's for the appropriate fields, and
skipping a bunch of  
>>> item
>>> types such as accounts and passwords
altogether.  The one thing I'm
>>> not sure about obfuscating is the mail item and
all its various
>>> fields.  Does it matter if email addresses are
included in these
>>> dumps?  If so, someone will have to go and
tweak export_mail( ) in
>>> translator.py to obfuscate the appropriate
fields.
>>
>> So from here:
>>
>> - Can we make use of this tool or data for server
performance  
>> efforts? If so, any next actions?
>>
>> Cheers,
>> Katie
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

>> - Should we tweak mail addresses to use test
accounts? (looking to  
>> Brian Kirsch here)

So to make sure I have this correct. You are advocating
replacing  
real user email addresses
with the OSAF demo account email addresses when generating /
  
obfuscating the test data.

+1 I don't see an issue with this.  We do need to be careful
with  
demo accounts
in general though since they are used by our CATS testing
framework  
and myself
for debugging.



-Brian





On Apr 11, 2007, at 11:29 AM, Aparna Kadakia wrote:

> +1 on using the same test data for both Desktop and
Server  
> performance.
>
> Also we could use our test accounts demo1, demo2 etc
for email  
> addresses in case we cannot replace it with some junk.
>
> (bkirsch, can you confirm....in case you missed there
is a question  
> waiting for your confirmation at the end of this
email)
>
> On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante
wrote:
>
>> As the desktop team turns attention to performance,
we're  
>> revisiting the
>> test data set that we've been using for performance
metrics.
>>
>> I'm not sure if we ought to coordinate desktop and
server team  
>> efforts
>> wrt test data -- sending this to both teams in case
this turns out  
>> to be
>> the case.
>>
>> Previously, we generated a set of calendar data and
have stored  
>> that in
>> an ics file
(tools/cats/datafiles/Generated3000.ics). The size of the
>> calendar and some of the characteristics were based
on Mitch's  
>> calendar
>> at the time.
>>
>> We're now at a point where we'd like to have a data
set that is
>> - based on real users' data
>> - contains multiple collections
>> - contains tasks, notes, messages in addition to
calendar data (a  
>> data
>> set that reflects the Preview feature set)
>>
>> Instead of storing test data in .ics files, it
makes sense to use our
>> new eim-based format. We'd like to start out with
real user data,  
>> then
>> obfuscate the data to protect the innocent.
>>
>> Morgen has checked in a tool that allows us to
obfuscate a "dump"  
>> file
>> from the desktop app. (Thanks Morgen!)
>>
>> From Morgen:
>>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>>> to file...
>>> It sets an obfuscation attribute to True on the
translator object,
>>> and then the various exporter callbacks honor
its setting, instead
>>> emitting X's for the appropriate fields, and
skipping a bunch of  
>>> item
>>> types such as accounts and passwords
altogether.  The one thing I'm
>>> not sure about obfuscating is the mail item and
all its various
>>> fields.  Does it matter if email addresses are
included in these
>>> dumps?  If so, someone will have to go and
tweak export_mail( ) in
>>> translator.py to obfuscate the appropriate
fields.
>>
>> So from here:
>>
>> - Can we make use of this tool or data for server
performance  
>> efforts? If so, any next actions?
>>
>> Cheers,
>> Katie
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Since Brian Kirsch has confirmed that we can replace the
real  
accounts with test accounts, what are the next action items
on this?
I would like to solicit help from external users for
providing their  
real calendars for testing. Having this tool obfuscate real
data will  
encourage more people to share their calendars for testing.

On Apr 11, 2007, at 2:29 PM, Aparna Kadakia wrote:

> +1 on using the same test data for both Desktop and
Server  
> performance.
>
> Also we could use our test accounts demo1, demo2 etc
for email  
> addresses in case we cannot replace it with some junk.
>
> (bkirsch, can you confirm....in case you missed there
is a question  
> waiting for your confirmation at the end of this
email)
>
> On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante
wrote:
>
>> As the desktop team turns attention to performance,
we're  
>> revisiting the
>> test data set that we've been using for performance
metrics.
>>
>> I'm not sure if we ought to coordinate desktop and
server team  
>> efforts
>> wrt test data -- sending this to both teams in case
this turns out  
>> to be
>> the case.
>>
>> Previously, we generated a set of calendar data and
have stored  
>> that in
>> an ics file
(tools/cats/datafiles/Generated3000.ics). The size of the
>> calendar and some of the characteristics were based
on Mitch's  
>> calendar
>> at the time.
>>
>> We're now at a point where we'd like to have a data
set that is
>> - based on real users' data
>> - contains multiple collections
>> - contains tasks, notes, messages in addition to
calendar data (a  
>> data
>> set that reflects the Preview feature set)
>>
>> Instead of storing test data in .ics files, it
makes sense to use our
>> new eim-based format. We'd like to start out with
real user data,  
>> then
>> obfuscate the data to protect the innocent.
>>
>> Morgen has checked in a tool that allows us to
obfuscate a "dump"  
>> file
>> from the desktop app. (Thanks Morgen!)
>>
>> From Morgen:
>>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>>> to file...
>>> It sets an obfuscation attribute to True on the
translator object,
>>> and then the various exporter callbacks honor
its setting, instead
>>> emitting X's for the appropriate fields, and
skipping a bunch of  
>>> item
>>> types such as accounts and passwords
altogether.  The one thing I'm
>>> not sure about obfuscating is the mail item and
all its various
>>> fields.  Does it matter if email addresses are
included in these
>>> dumps?  If so, someone will have to go and
tweak export_mail( ) in
>>> translator.py to obfuscate the appropriate
fields.
>>
>> So from here:
>> - Should we tweak mail addresses to use test
accounts? (looking to  
>> Brian Kirsch here)
>> - Can we make use of this tool or data for server
performance  
>> efforts? If so, any next actions?
>>
>> Cheers,
>> Katie
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Since Brian Kirsch has confirmed that we can replace the
real  
accounts with test accounts, what are the next action items
on this?
I would like to solicit help from external users for
providing their  
real calendars for testing. Having this tool obfuscate real
data will  
encourage more people to share their calendars for testing.

On Apr 11, 2007, at 2:29 PM, Aparna Kadakia wrote:

> +1 on using the same test data for both Desktop and
Server  
> performance.
>
> Also we could use our test accounts demo1, demo2 etc
for email  
> addresses in case we cannot replace it with some junk.
>
> (bkirsch, can you confirm....in case you missed there
is a question  
> waiting for your confirmation at the end of this
email)
>
> On Apr 10, 2007, at 3:28 PM, Katie Capps Parlante
wrote:
>
>> As the desktop team turns attention to performance,
we're  
>> revisiting the
>> test data set that we've been using for performance
metrics.
>>
>> I'm not sure if we ought to coordinate desktop and
server team  
>> efforts
>> wrt test data -- sending this to both teams in case
this turns out  
>> to be
>> the case.
>>
>> Previously, we generated a set of calendar data and
have stored  
>> that in
>> an ics file
(tools/cats/datafiles/Generated3000.ics). The size of the
>> calendar and some of the characteristics were based
on Mitch's  
>> calendar
>> at the time.
>>
>> We're now at a point where we'd like to have a data
set that is
>> - based on real users' data
>> - contains multiple collections
>> - contains tasks, notes, messages in addition to
calendar data (a  
>> data
>> set that reflects the Preview feature set)
>>
>> Instead of storing test data in .ics files, it
makes sense to use our
>> new eim-based format. We'd like to start out with
real user data,  
>> then
>> obfuscate the data to protect the innocent.
>>
>> Morgen has checked in a tool that allows us to
obfuscate a "dump"  
>> file
>> from the desktop app. (Thanks Morgen!)
>>
>> From Morgen:
>>> So yesterday I checked in Tools > Save and
Restore > Obfuscated dump
>>> to file...
>>> It sets an obfuscation attribute to True on the
translator object,
>>> and then the various exporter callbacks honor
its setting, instead
>>> emitting X's for the appropriate fields, and
skipping a bunch of  
>>> item
>>> types such as accounts and passwords
altogether.  The one thing I'm
>>> not sure about obfuscating is the mail item and
all its various
>>> fields.  Does it matter if email addresses are
included in these
>>> dumps?  If so, someone will have to go and
tweak export_mail( ) in
>>> translator.py to obfuscate the appropriate
fields.
>>
>> So from here:
>> - Should we tweak mail addresses to use test
accounts? (looking to  
>> Brian Kirsch here)
>> - Can we make use of this tool or data for server
performance  
>> efforts? If so, any next actions?
>>
>> Cheers,
>> Katie
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev