A couple big ideas: cosmo release and server project merge

1.  Merge Cosmo and Scooby SVN trees, mailing list and IRC
channel.
2.  Release Cosmo 0.3 -- less ambitious than previously
planned -- in  
time for Scooby 0.1

Ok, what are we thinking here?

It's been six months since we released Cosmo 0.2 (September
19).  In  
those six months, we have done significant work on Cosmo.
There's all  
the bug fixes in the 0.2 branch, CalDAV work and a rough  
administrative GUI in the 0.3 trunk.  It seems worthwhile to
consider  
another release now, particularly since Scooby 0.1 is slated
for  
release in February and has dependencies on Cosmo CalDAV
features.

With the work ramping up to releasing Scooby, we've seen a
need for a  
combined download/build to make things ultimately easy for
people who  
want to check out Scooby.  BCM threw this together quickly,
including  
Scooby, Cosmo, Jackrabbit and Tomcat, all in one bundle and
ready-to- 
go.  Needing a name for this, BCM (and others) picked Snarf.
 That  
resulted in some meta conversations like "is Snarf a
project" and  
"what is a project" and asking ourselves if this
would confuse people  
or seem sensible.

One possible fix to avoid having another SVN module, and
thus require  
another name, is to combine Cosmo and Scooby under one SVN
module,  
and have a "scooby-complete" download or build
that includes  
everything Snarf does.  When BCM thought of this today in
the server  
meeting there were surprised approval sounds all around the
room and  
people also thought of the advantages of moving to a single
mailing  
list and IRC channel if we'd like.  We'd keep releases of
Cosmo and  
Scooby still possibly independent.  E.g. a release of Cosmo
might  
happen in one month, and a release of Scooby with a
"scooby-complete"  
including that release of Cosmo could happen a week later, a
month  
later, or whatever seems best.  Preserving the ability to do
 
independent releases of the sharing server and the calendar
WebUI,  
what's the best way to manage both in SVN? in community
forums?

Whether or not we merge server communities, what would we
have to do  
to release Cosmo 0.3?
  - Do a small bit of spit and polish on the new
administrative GUI.   
Priscilla is signed up for at least some of this.
  - Do a data upgrade tool, the one thing we promised for
0.3 that we  
don't want to defer -- BCM
  - Fix some CalDAV REPORT issues that would be really
useful for  
Scooby -- BKirsch with Bobby's input
  - Fix current build issues and ensure we are satisfied
with this --  
BCM and Bear, I think
  - Check in more automated tests than we had in 0.2 --
Heikki is on  
this already
  - Todd Agolnick might contribute tests to Cosmo in time --
I asked  
him to mail this list

Is this correct or am I missing anything?  Discussion,
approval votes  
or concerns, anybody?

Lisa
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On Feb 2, 2006, at 5:45 PM, Lisa Dusseault wrote:

> One possible fix to avoid having another SVN module,
and thus  
> require another name, is to combine Cosmo and Scooby
under one SVN  
> module, and have a "scooby-complete" download
or build that  
> includes everything Snarf does.  When BCM thought of
this today in  
> the server meeting there were surprised approval sounds
all around  
> the room and people also thought of the advantages of
moving to a  
> single mailing list and IRC channel if we'd like.  We'd
keep  
> releases of Cosmo and Scooby still possibly
independent.  E.g. a  
> release of Cosmo might happen in one month, and a
release of Scooby  
> with a "scooby-complete" including that
release of Cosmo could  
> happen a week later, a month later, or whatever seems
best.   
> Preserving the ability to do independent releases of
the sharing  
> server and the calendar WebUI, what's the best way to
manage both  
> in SVN? in community forums?

For the record, I made neither approval nor disapproval
noises.  I  
think we have decide whether we have one project or two...

The rationale that I understood (before today) for having
two  
projects includes:
1. Scooby could sit atop any CalDAV server not just Cosmo
2. People who are looking for a CalDAV server might  be
interested in  
Cosmo but not Scooby

Arguments that I heard (today) in favor of having one
project:
1. We want ease of installation - that kind of implies one
project,  
although I don't think it requires it.
2. There are some pieces of code that might be in the margin
in  
between Cosmo and Scooby, which might have to be a separate
project.   
Which I think is what the background idea behind Snarf was. 
But  
Snarf as originally presented was mostly about build
configurations,  
at least until bcm and Bobby started bringing up these other
 
management components.

Are we going to merge product planning as well as merging
the code?    
If we just have one project, does it make sense to keep the
two  
pieces on the same release schedule?  If not, then doesn't
that mean  
we have two projects?   One problem that I see with merging
the two  
projects is that integrated projects take longer to ship,
since you  
have to wait for everybody to be ready.  I'd hate to see the
pace of  
Cosmo development/releases slow down (which I think
negatively  
impacts Chandler) in order to keep in sync with Scooby.

Ted
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On Feb 2, 2006, at 6:48 PM, Ted Leung wrote:

> On Feb 2, 2006, at 5:45 PM, Lisa Dusseault wrote:
>
>> One possible fix to avoid having another SVN
module, and thus  
>> require another name, is to combine Cosmo and
Scooby under one SVN  
>> module, and have a "scooby-complete"
download or build that  
>> includes everything Snarf does.  When BCM thought
of this today in  
>> the server meeting there were surprised approval
sounds all around  
>> the room and people also thought of the advantages
of moving to a  
>> single mailing list and IRC channel if we'd like. 
We'd keep  
>> releases of Cosmo and Scooby still possibly
independent.  E.g. a  
>> release of Cosmo might happen in one month, and a
release of  
>> Scooby with a "scooby-complete" including
that release of Cosmo  
>> could happen a week later, a month later, or
whatever seems best.   
>> Preserving the ability to do independent releases
of the sharing  
>> server and the calendar WebUI, what's the best way
to manage both  
>> in SVN? in community forums?
>
> For the record, I made neither approval nor disapproval
noises.  I  
> think we have decide whether we have one project or
two...

that's why we're going to the list!  that meeting was the
wrong place  
to determine consensus, I was just trying to say that we'd
heard some  
encouragement to bring this up.
>
>
> Are we going to merge product planning as well as
merging the  
> code?   If we just have one project, does it make sense
to keep the  
> two pieces on the same release schedule?  If not, then
doesn't that  
> mean we have two projects?   One problem that I see
with merging  
> the two projects is that integrated projects take
longer to ship,  
> since you have to wait for everybody to be ready.  I'd
hate to see  
> the pace of Cosmo development/releases slow down (which
I think  
> negatively impacts Chandler) in order to keep in sync
with Scooby.

The alignments between projects and other pieces are
uncertain in  
many ways. As you point out, one could merge product
planning.   
Chandler is one project with two development groups and both
separate  
and combined status meetings, whereas Cosmo and Scooby are
two  
projects today but with one status meeting.  I don't think
that  
having one SVN repository necessarily implies we would need
to change  
product planning practices.  I guess the project alignment
issue  
overall is one that we're actively questioning various parts
of,  
rather than going with the unconscious assumptions we'd
previously used.

thanks!
lisa

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

I'm not even sure if I like the idea of one svn module,
regardless of  
whether we call it one project or not.

You still want to be able to run cosmo and scooby on
different  
servers (I do anyway!) so there would be different codebases
for the  
apps now called scooby and cosmo so that will require that
they maybe  
in different SVN 'modules' but still need their own  
directories....which would need names. And you'd still need
the code  
which packages it all together somehow (now called Snarf) so
that  
would be it's own directory...

Plus branching would be annoying (I think) since you'll want
to be  
branching Scooby sometimes but not Cosmo and vice versa if
they are  
on different release schedules. I guess I don't see the
advantage of  
having one SVN module.

For the sake of community however, we can call everything
one  
project, and have what is now Cosmo and Scooby (perhaps even
 
Chandler!) be sub-projects. Think Apache Jakarta Commons -
the  
Commons projects have a shared goal and vision, but various
sub- 
projects (net, lang, validator) with their own release
cycles.  
Another example is Microsoft Office.

Imagine if everything was called Chandler (for example) -
we'd have  
Chandler Desktop (now Chandler), Chandler Web (Scooby) and
Chandler  
Server (Cosmo).

On a more practical note, I give a +1 to releasing Cosmo .3
in time  
for Scooby .1 -- assuming '.3' means that CalDAV reports
issues are  
taken care of (at least).

Bobby

On Feb 3, 2006, at 1:00 PM, Lisa Dusseault wrote:

>
> On Feb 2, 2006, at 6:48 PM, Ted Leung wrote:
>
>> On Feb 2, 2006, at 5:45 PM, Lisa Dusseault wrote:
>>
>>> One possible fix to avoid having another SVN
module, and thus  
>>> require another name, is to combine Cosmo and
Scooby under one  
>>> SVN module, and have a
"scooby-complete" download or build that  
>>> includes everything Snarf does.  When BCM
thought of this today  
>>> in the server meeting there were surprised
approval sounds all  
>>> around the room and people also thought of the
advantages of  
>>> moving to a single mailing list and IRC channel
if we'd like.   
>>> We'd keep releases of Cosmo and Scooby still
possibly  
>>> independent.  E.g. a release of Cosmo might
happen in one month,  
>>> and a release of Scooby with a
"scooby-complete" including that  
>>> release of Cosmo could happen a week later, a
month later, or  
>>> whatever seems best.  Preserving the ability to
do independent  
>>> releases of the sharing server and the calendar
WebUI, what's the  
>>> best way to manage both in SVN? in community
forums?
>>
>> For the record, I made neither approval nor
disapproval noises.  I  
>> think we have decide whether we have one project or
two...
>
> that's why we're going to the list!  that meeting was
the wrong  
> place to determine consensus, I was just trying to say
that we'd  
> heard some encouragement to bring this up.
>>
>>
>> Are we going to merge product planning as well as
merging the  
>> code?   If we just have one project, does it make
sense to keep  
>> the two pieces on the same release schedule?  If
not, then doesn't  
>> that mean we have two projects?   One problem that
I see with  
>> merging the two projects is that integrated
projects take longer  
>> to ship, since you have to wait for everybody to be
ready.  I'd  
>> hate to see the pace of Cosmo development/releases
slow down  
>> (which I think negatively impacts Chandler) in
order to keep in  
>> sync with Scooby.
>
> The alignments between projects and other pieces are
uncertain in  
> many ways. As you point out, one could merge product
planning.   
> Chandler is one project with two development groups and
both  
> separate and combined status meetings, whereas Cosmo
and Scooby are  
> two projects today but with one status meeting.  I
don't think that  
> having one SVN repository necessarily implies we would
need to  
> change product planning practices.  I guess the project
alignment  
> issue overall is one that we're actively questioning
various parts  
> of, rather than going with the unconscious assumptions
we'd  
> previously used.
>
> thanks!
> lisa
>
> _______________________________________________
> Scooby mailing list
> Scoobyosafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/lis
tinfo/scooby

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 2/2/06, Lisa Dusseault <lisaosafoundation.org>
wrote:

> One possible fix to avoid having another SVN module,
and thus require

i don't see why we'd ever need to avoid adding svn modules.
we already
have nearly ten modules in the server repo. there is no
relationship
between svn module and project status, at least as we've
currently
structured the repo.

> another name, is to combine Cosmo and Scooby under one
SVN module,
> and have a "scooby-complete" download or
build that includes
> everything Snarf does.  When BCM thought of this today
in the server

well, "scooby-complete" is not how i'd
characterize my idea 

it occurs to me that what we really have is one umbrella
server
project with closely collaborating developers (me and
bobbyrullo at
the moment), shared code (osaf patched ical4j), extremely
similar
build systems and documentation, etc. we happen to have two
subprojects, i think, but there are so many common ideas and
concepts
flowing between them that it seems artificial to me to
separate them.

it's always been my goal, and from what i could tell
everybody else
agreed with me, to have a single download-and-install server
package
that included the web calendar, as well as individual
webapps for
cosmo and scooby. yes, these are just packaging concerns,
but i think
they reflect the larger sense of identity that i see
evolving. scooby
and cosmo are really just parts of a whole, tho it's easy
for somebody
to pull out one of those parts if that's all they want.

> Preserving the ability to do
> independent releases of the sharing server and the
calendar WebUI,
> what's the best way to manage both in SVN? in community
forums?

i don't see any reason to change how svn is structured. it's
already
structured as an umbrella (the server repo) with many
subprojects
(cosmo, scooby, ical4j, jackrabbit, osaf-commons, derby,
etc).

i do think that segregating the cosmo and scooby communities
is, in
hindsight, a poor decision. take irc for instance. a lot of
discussion
happens on the #scooby channel that would be just as
appropriate on
#cosmo, and vice versa, but unless an interested party is on
both he
will miss some of what goes on. i don't think it's true that
cosmo
folks are uninterested in the ui stuff happening over at
scooby - both
bkirsch and i have extensive ui dev background - and i'd
like to soak
up as much of that conversation as i can even if i'm
directly
participating. keeping cosmo and scooby irc and mail
separate seems
artificial at this point.

i also think that this artificial separation has helped keep
bobby and
me from feeling empowered to contribute to each other's
code. i know
that sometimes i wake up with much more interest in what's
going on
with scooby that day than with cosmo, but because i'm not
"on the
scooby team", it doesn't feel right to offer to work on
one of their
tasks. similarly, bobby seems reluctant to get his hands
dirty with
the cosmo reports code, when he's currently the person to
whom that
code is most important, and indeed he understands how it's
supposed to
work much better than either me or bkirsch. so i think
making us all
part of one project with explicit commit access to the
entire server
svn repo, would address this. yes, i know that the scooby
team could
accept me as a committer and vice versa, but again, that
seems
artificial and overly complicated.

to your question about preserving the ability to make
independent
releases, i don't see any reason for that to be any more
difficult
with them as subprojects of an umbrella server project:

1) cosmo releases 0.3, scooby releases 0.1, snarf releases
0.3-0.1
2) cosmo releases 0.4, snarf releases 0.4-0.1
3) scooby releases 0.2, snarf releases 0.4-0.2

etc.

so, just to be clear, i propose that we formally create an
"osaf
sharing server" project with cosmo and scooby as
subprojects, with
unified community tools, project wiki, and committer pool
(with access
to the entire server repo). cosmo, scooby, and snarf
(probably
renamed) continue to be separate bugzilla products and have
separate
process/planning docs (subsections of the wiki), but we
integrate
their installation docs and faqs and so forth to the extent
that it
makes sense.

thoughts?

> Whether or not we merge server communities, what would
we have to do
> to release Cosmo 0.3?
>   - Do a small bit of spit and polish on the new
administrative GUI.
> Priscilla is signed up for at least some of this.

this isn't strictly required. the ui can be released as is.
to be
honest, i don't think prettying up the ui is particularly
useful at
this stage. it just adds risk of introducing bugs at this
late date.

>   - Do a data upgrade tool, the one thing we promised
for 0.3 that we
> don't want to defer -- BCM

proposal coming in the next day or too.

>   - Fix some CalDAV REPORT issues that would be really
useful for
> Scooby -- BKirsch with Bobby's input

yes please!

>   - Fix current build issues and ensure we are
satisfied with this --
> BCM and Bear, I think

on it right now. hope to have it worked out today.
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 2/3/06, Bobby Rullo <brosafoundation.org>
wrote:
> I'm not even sure if I like the idea of one svn module,
regardless of
> whether we call it one project or not.

the issue is not our svn repo structure, which is already
satisfactory. it's a much larger question of identity.

> For the sake of community however, we can call
everything one
> project, and have what is now Cosmo and Scooby (perhaps
even
> Chandler!) be sub-projects. Think Apache Jakarta
Commons - the
> Commons projects have a shared goal and vision, but
various sub-
> projects (net, lang, validator) with their own release
cycles.
> Another example is Microsoft Office.

i don't care if we call things apple, bob and caterpillar.
it seemed
logical many months ago to have separate cosmo and scooby
communities,
but i think time has shown that is an artificial separation.
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

Comments inline...

On Feb 3, 2006, at 1:27 PM, Brian Moseley wrote:
>
> i don't see any reason to change how svn is structured.
it's already
> structured as an umbrella (the server repo) with many
subprojects
> (cosmo, scooby, ical4j, jackrabbit, osaf-commons,
derby, etc).
>

Wholeheartedly agree.

> i do think that segregating the cosmo and scooby
communities is, in
> hindsight, a poor decision. take irc for instance. a
lot of discussion
> happens on the #scooby channel that would be just as
appropriate on
> #cosmo, and vice versa, but unless an interested party
is on both he
> will miss some of what goes on. i don't think it's true
that cosmo
> folks are uninterested in the ui stuff happening over
at scooby - both
> bkirsch and i have extensive ui dev background - and
i'd like to soak
> up as much of that conversation as i can even if i'm
directly
> participating. keeping cosmo and scooby irc and mail
separate seems
> artificial at this point.
>

I have no problem with merging IRC chat either.

> i also think that this artificial separation has helped
keep bobby and
> me from feeling empowered to contribute to each other's
code. i know
> that sometimes i wake up with much more interest in
what's going on
> with scooby that day than with cosmo, but because i'm
not "on the
> scooby team", it doesn't feel right to offer to
work on one of their
> tasks. similarly, bobby seems reluctant to get his
hands dirty with
> the cosmo reports code, when he's currently the person
to whom that
> code is most important, and indeed he understands how
it's supposed to
> work much better than either me or bkirsch. so i think
making us all
> part of one project with explicit commit access to the
entire server
> svn repo, would address this. yes, i know that the
scooby team could
> accept me as a committer and vice versa, but again,
that seems
> artificial and overly complicated.
>

The only thing that keeps from me feeling un-empowered  or
reluctant  
to making commits to cosmo is a lack of understanding of all
its  
components (the way stuff is stored in the JCR repo and the
indexer  
mostly) but the cosmo team has made me feel very comfortable
making  
changes when I can. (Right now there is nothing blocking my
Scooby  
work FYI).

Explicit commit access however is a good thing just so that
we have  
established policies for when outside contributors start
popping up.

> so, just to be clear, i propose that we formally create
an "osaf
> sharing server" project with cosmo and scooby as
subprojects, with
> unified community tools, project wiki, and committer
pool (with access
> to the entire server repo). cosmo, scooby, and snarf
(probably
> renamed) continue to be separate bugzilla products and
have separate
> process/planning docs (subsections of the wiki), but we
integrate
> their installation docs and faqs and so forth to the
extent that it
> makes sense.
>
> thoughts?

Works for me.

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 2/2/06, Ted Leung <twlosafoundation.org>
wrote:

> The rationale that I understood (before today) for
having two
> projects includes:
> 1. Scooby could sit atop any CalDAV server not just
Cosmo

this might be true someday - we hope it to be true someday -
but it's
not in the short term. and the more we think about it, the
more
synergy there will be in the long term between the two. i
think there
will always be a useful subset of functionality when scooby
runs
against something other than cosmo, but we can do a lot more
wonderful
things when we know the two are being run together.

> 2. People who are looking for a CalDAV server might  be
interested in
> Cosmo but not Scooby

a unified server project doesn't imply that one would be
forced to
download and use both apps. as subprojects, both cosmo and
scooby
would continue to have their own deployment artifacts
(scooby.war and
cosmo.war) and supporting documentation.

> Arguments that I heard (today) in favor of having one
project:
> 1. We want ease of installation - that kind of implies
one project,
> although I don't think it requires it.

you're right, but if ease of installation was the only
criteria, then
what we have today in snarf would suffice.

> 2. There are some pieces of code that might be in the
margin in
> between Cosmo and Scooby, which might have to be a
separate project.
> Which I think is what the background idea behind Snarf
was.  But
> Snarf as originally presented was mostly about build
configurations,
> at least until bcm and Bobby started bringing up these
other
> management components.

we've never talked explicitly about what might be in an
integrated
server bundle, but i've always had ideas along the lines of
a unified
management dashboard and jmx schema (or whatever they call
it). and
the way i see jackrabbit evolving, it's possible that we'll
eventually
need an app server plugin or two as well. there's a lot of
room for
ideas.

> Are we going to merge product planning as well as
merging the code?
> If we just have one project, does it make sense to keep
the two
> pieces on the same release schedule?  If not, then
doesn't that mean
> we have two projects?   One problem that I see with
merging the two
> projects is that integrated projects take longer to
ship, since you
> have to wait for everybody to be ready.  I'd hate to
see the pace of
> Cosmo development/releases slow down (which I think
negatively
> impacts Chandler) in order to keep in sync with Scooby.

as i mentioned in my previous message, i think we'd make a
new release
of the integrated server whenever one of the subprojects has
a
release. no need to wait around for any other subproject,
just include
the most recent stable version.

and fwiw, slowing down cosmo development is not in my
playbook  if
anything, i want to release cosmo much more frequently. i
don't see
the project unification as having any impact on that.
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On Feb 3, 2006, at 10:27 AM, Brian Moseley wrote:

> i also think that this artificial separation has helped
keep bobby and
> me from feeling empowered to contribute to each other's
code. i know
> that sometimes i wake up with much more interest in
what's going on
> with scooby that day than with cosmo, but because i'm
not "on the
> scooby team", it doesn't feel right to offer to
work on one of their
> tasks. similarly, bobby seems reluctant to get his
hands dirty with
> the cosmo reports code, when he's currently the person
to whom that
> code is most important, and indeed he understands how
it's supposed to
> work much better than either me or bkirsch. so i think
making us all
> part of one project with explicit commit access to the
entire server
> svn repo, would address this. yes, i know that the
scooby team could
> accept me as a committer and vice versa, but again,
that seems
> artificial and overly complicated.

Actually, it's not.  When you have separate projects, it's a
sign  
that the meritocracy is working correctly.   When Sun
started  
contributing to Tomcat, their new hires did not
automatically get  
commit privileges to CVS.   They had to earn them, just like
 
everybody else.   We've already seen people who are
reluctant to  
contribute because they feel that OSAF people are in some
ways more  
privileged than they would be.

If we want to be regarded as a serious open source project
that is  
committed to a diverse and empowered community, then we
cannot keep  
making shortcuts for ourselves.

> so, just to be clear, i propose that we formally create
an "osaf
> sharing server" project with cosmo and scooby as
subprojects, with
> unified community tools, project wiki, and committer
pool (with access
> to the entire server repo). cosmo, scooby, and snarf
(probably
> renamed) continue to be separate bugzilla products and
have separate
> process/planning docs (subsections of the wiki), but we
integrate
> their installation docs and faqs and so forth to the
extent that it
> makes sense.

The more I think about it, the more this seems like a
shortcut.

----
Ted Leung                 Open Source Applications
Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87
F5FC 4B42


_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

I haven't had a chance to catch up on this thread so sorry
if this is  
not relevant or has already been discussed.

What does this mean for Chandler? There are features in
Cosmo 0.3  
that Chandler 0.7 will it will be a while before we are able
to do  
any integration testing. Does this mean Chandler will use
Cosmo 0.4?  
Will we just have 0.3.x like we did for the last release? We
we also  
have performance goals for 0.7 Chandler sharing/synching and
this may  
also have implications for work on Cosmo. Is that Cosmo
0.3.x or  
Cosmo 0.4? I guess I am just saying that I can easily see
issues that  
will come up. What happens if a fix for Chandler breaks
Scooby (no  
idea about the likelyhood here but..you never know).

Another thing we need to do in order to release Cosmo 0.3 is
test it  
with Chandler. I am assuming by release we mean upgrade
Cosmo Demo?  
In that case Aparna will have to do some kind of sanity
testing.  
Perhaps this will be minimal but I am pretty sure she hasn't
planned  
for this. We told her originally that we would be releasing
Scooby  
0.1 with some snapshot of Cosmo but not upgrading Cosmo
Demo.

Sheila


On Feb 2, 2006, at 5:45 PM, Lisa Dusseault wrote:

>
> 1.  Merge Cosmo and Scooby SVN trees, mailing list and
IRC channel.
> 2.  Release Cosmo 0.3 -- less ambitious than previously
planned --  
> in time for Scooby 0.1
>
> Ok, what are we thinking here?
>
> It's been six months since we released Cosmo 0.2
(September 19).   
> In those six months, we have done significant work on
Cosmo.  
> There's all the bug fixes in the 0.2 branch, CalDAV
work and a  
> rough administrative GUI in the 0.3 trunk.  It seems
worthwhile to  
> consider another release now, particularly since Scooby
0.1 is  
> slated for release in February and has dependencies on
Cosmo CalDAV  
> features.
>
> With the work ramping up to releasing Scooby, we've
seen a need for  
> a combined download/build to make things ultimately
easy for people  
> who want to check out Scooby.  BCM threw this together
quickly,  
> including Scooby, Cosmo, Jackrabbit and Tomcat, all in
one bundle  
> and ready-to-go.  Needing a name for this, BCM (and
others) picked  
> Snarf.  That resulted in some meta conversations like
"is Snarf a  
> project" and "what is a project" and
asking ourselves if this would  
> confuse people or seem sensible.
>
> One possible fix to avoid having another SVN module,
and thus  
> require another name, is to combine Cosmo and Scooby
under one SVN  
> module, and have a "scooby-complete" download
or build that  
> includes everything Snarf does.  When BCM thought of
this today in  
> the server meeting there were surprised approval sounds
all around  
> the room and people also thought of the advantages of
moving to a  
> single mailing list and IRC channel if we'd like.  We'd
keep  
> releases of Cosmo and Scooby still possibly
independent.  E.g. a  
> release of Cosmo might happen in one month, and a
release of Scooby  
> with a "scooby-complete" including that
release of Cosmo could  
> happen a week later, a month later, or whatever seems
best.   
> Preserving the ability to do independent releases of
the sharing  
> server and the calendar WebUI, what's the best way to
manage both  
> in SVN? in community forums?
>
> Whether or not we merge server communities, what would
we have to  
> do to release Cosmo 0.3?
>  - Do a small bit of spit and polish on the new
administrative  
> GUI.  Priscilla is signed up for at least some of this.
>  - Do a data upgrade tool, the one thing we promised
for 0.3 that  
> we don't want to defer -- BCM
>  - Fix some CalDAV REPORT issues that would be really
useful for  
> Scooby -- BKirsch with Bobby's input
>  - Fix current build issues and ensure we are satisfied
with this  
> -- BCM and Bear, I think
>  - Check in more automated tests than we had in 0.2 --
Heikki is on  
> this already
>  - Todd Agolnick might contribute tests to Cosmo in
time -- I asked  
> him to mail this list
>
> Is this correct or am I missing anything?  Discussion,
approval  
> votes or concerns, anybody?
>
> Lisa
> _______________________________________________
> Cosmo mailing list
> Cosmoosafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo