I propose to disconnect collections from the aggregate project and put
it on its own release cycle.

This was originally someone else's idea when we started on it.

Collections is useful in its own right, and I'd like to make fixes to
it available without having the whole rest of Mahout reach a release
point.

I confess that the slf4j dependency in collections is a very strong
local motivation to me, but it also seems right in principle.

When we go TLP, we can organize this more coherently in svn, but for
now we can leave it where it is, but fix up the poms.

This strikes me as consistent with the idea of marinating with
possible intent that it would become its own thing some day.

On Sat, Apr 3, 2010 at 6:47 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> I confess that the slf4j dependency in collections is a very strong
> local motivation to me, but it also seems right in principle.

I just killed this BTW. (There was one dangling log statement... not
worth a dependency.)

> When we go TLP, we can organize this more coherently in svn, but for
> now we can leave it where it is, but fix up the poms.

Actually it seems like this a valid subproject of a Mahout TLP in its
own right, if that would be a useful middle-ground status.

> This strikes me as consistent with the idea of marinating with
> possible intent that it would become its own thing some day.

Yes it's already its own module, which helps manage it independently.
At the moment that means anyone can depend on it, and only it, via
Maven, which is 80% of the value.

I think it probably needs a fair bit of API rethinking and cleanup to
truly stand as a general purpose and reusable component, but that can
happen.

On Sat, Apr 3, 2010 at 2:07 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 3, 2010 at 6:47 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
>> I confess that the slf4j dependency in collections is a very strong
>> local motivation to me, but it also seems right in principle.
>
> I just killed this BTW. (There was one dangling log statement... not
> worth a dependency.)

Yes, thank you.

My selfish short-term goal is to get a release with the log dependency
removed out before Mahout 0.4 :-).

>
>> When we go TLP, we can organize this more coherently in svn, but for
>> now we can leave it where it is, but fix up the poms.
>
> Actually it seems like this a valid subproject of a Mahout TLP in its
> own right, if that would be a useful middle-ground status.

I'm not trying to suggest anything different. I'm opposed to having
'separate committers', but I'm happy to have multiple releasable
components all in the Mahout TLP.

>
>> This strikes me as consistent with the idea of marinating with
>> possible intent that it would become its own thing some day.
>
> Yes it's already its own module, which helps manage it independently.
> At the moment that means anyone can depend on it, and only it, via
> Maven, which is 80% of the value.
>
> I think it probably needs a fair bit of API rethinking and cleanup to
> truly stand as a general purpose and reusable component, but that can
> happen.
>

No argument there.

Practical point: it would be, all joking aside, good to make a very
prompt release of this so that the rest of Mahout 0.4-SNAPSHOT could
depend on it.

If no one protests, I'll do the POM surgery in a couple of days.

On Apr 3, 2010, at 2:22 PM, Benson Margulies wrote:

> On Sat, Apr 3, 2010 at 2:07 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>
>> Actually it seems like this a valid subproject of a Mahout TLP in its
>> own right, if that would be a useful middle-ground status.
>
> I'm not trying to suggest anything different. I'm opposed to having
> 'separate committers', but I'm happy to have multiple releasable
> components all in the Mahout TLP.

For those following the sub project saga in Lucene, let's not go down that road.  +1 to releasable components, though.  We can release what we want when we want.  It doesn't have to be the whole thing all the time.  But I'd say no to separate committers, etc.

Last question: What's the first version going to be? I propose '1.0'.
0.4 would get mighty confusion. I really don't see the harm in calling
it 1.0.
On Sat, Apr 3, 2010 at 6:00 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
> On Apr 3, 2010, at 2:22 PM, Benson Margulies wrote:
>
>> On Sat, Apr 3, 2010 at 2:07 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>
>>> Actually it seems like this a valid subproject of a Mahout TLP in its
>>> own right, if that would be a useful middle-ground status.
>>
>> I'm not trying to suggest anything different. I'm opposed to having
>> 'separate committers', but I'm happy to have multiple releasable
>> components all in the Mahout TLP.
>
> For those following the sub project saga in Lucene, let's not go down that road.  +1 to releasable components, though.  We can release what we want when we want.  It doesn't have to be the whole thing all the time.  But I'd say no to separate committers, etc.

Hearing no other remarks, I will proceed to disconnect and make the
version 1.0-SNAPSHOT, and call a release vote RSN.
On Sun, Apr 4, 2010 at 7:58 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> Last question: What's the first version going to be? I propose '1.0'.
> 0.4 would get mighty confusion. I really don't see the harm in calling
> it 1.0.
>
>
> On Sat, Apr 3, 2010 at 6:00 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>>
>> On Apr 3, 2010, at 2:22 PM, Benson Margulies wrote:
>>
>>> On Sat, Apr 3, 2010 at 2:07 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>
>>>> Actually it seems like this a valid subproject of a Mahout TLP in its
>>>> own right, if that would be a useful middle-ground status.
>>>
>>> I'm not trying to suggest anything different. I'm opposed to having
>>> 'separate committers', but I'm happy to have multiple releasable
>>> components all in the Mahout TLP.
>>
>> For those following the sub project saga in Lucene, let's not go down that road.  +1 to releasable components, though.  We can release what we want when we want.  It doesn't have to be the whole thing all the time.  But I'd say no to separate committers, etc.
>

This still lives in Mahout, just has a different version number?
what's the substance of the change in the short-term; I think I missed
that step.

On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> Hearing no other remarks, I will proceed to disconnect and make the
> version 1.0-SNAPSHOT, and call a release vote RSN.

Substance:

1: remove collections-codegen and collections from the top-level pom's
module list.
2: change their parents to point to the apache parent.
3: tweak their poms so that the release plugin works right with them.
4: release them
5: change rest of mahout to consume release.
On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> This still lives in Mahout, just has a different version number?
> what's the substance of the change in the short-term; I think I missed
> that step.
>
> On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
>> Hearing no other remarks, I will proceed to disconnect and make the
>> version 1.0-SNAPSHOT, and call a release vote RSN.
>

For what it is worth, I actually prefer this approach to the multi-pom
approach in many cases.  If it really is a separate thing, it might as well
have a separate release schedule and artifact.  If it isn't a separate
thing, then you might as well use a single pom.  This heuristic doesn't
always work, and I know that people with more maven experience than I have
work under different principles.  My explanation for the difference in
opinion is that the separated project may be better for those with limited
maven experience while the more complex arrangement may be better for those
with a native fluency.

As such, giving mahout-collections and ultimately mahout-math their own
version number is a fine thing.  Also will pretty much always exhibit more
maturity than the core mahout project if only because the needs they fulfill
are better understood.  That makes the 1.0 version for collections match the
0.4 upcoming version for Mahout.

On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies <[EMAIL PROTECTED]>wrote:

> Substance:
>
> 1: remove collections-codegen and collections from the top-level pom's
> module list.
> 2: change their parents to point to the apache parent.
> 3: tweak their poms so that the release plugin works right with them.
> 4: release them
> 5: change rest of mahout to consume release.
>
>
> On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> > This still lives in Mahout, just has a different version number?
> > what's the substance of the change in the short-term; I think I missed
> > that step.
> >
> > On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <[EMAIL PROTECTED]>
> wrote:
> >> Hearing no other remarks, I will proceed to disconnect and make the
> >> version 1.0-SNAPSHOT, and call a release vote RSN.
> >
>

I agree in principal, but having a whole different set of versionings seems
kinda... messy?  If m-collections goes 1.0, and then 1.1, and then m-math
goes 1.0, and core goes to 0.5, we have a whole pile of different version
numbers to keep track of.

Didn't Lucene and Solr just intentionally do the reverse, locking their
release
numbers and schedules?  And now we're doing the opposite on a less
mature project?  What exactly do we gain by this?

  -jake

On Tue, Apr 6, 2010 at 11:43 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> For what it is worth, I actually prefer this approach to the multi-pom
> approach in many cases.  If it really is a separate thing, it might as well
> have a separate release schedule and artifact.  If it isn't a separate
> thing, then you might as well use a single pom.  This heuristic doesn't
> always work, and I know that people with more maven experience than I have
> work under different principles.  My explanation for the difference in
> opinion is that the separated project may be better for those with limited
> maven experience while the more complex arrangement may be better for those
> with a native fluency.
>
> As such, giving mahout-collections and ultimately mahout-math their own
> version number is a fine thing.  Also will pretty much always exhibit more
> maturity than the core mahout project if only because the needs they
> fulfill
> are better understood.  That makes the 1.0 version for collections match
> the
> 0.4 upcoming version for Mahout.
>
> On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies <[EMAIL PROTECTED]
> >wrote:
>
> > Substance:
> >
> > 1: remove collections-codegen and collections from the top-level pom's
> > module list.
> > 2: change their parents to point to the apache parent.
> > 3: tweak their poms so that the release plugin works right with them.
> > 4: release them
> > 5: change rest of mahout to consume release.
> >
> >
> > On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> > > This still lives in Mahout, just has a different version number?
> > > what's the substance of the change in the short-term; I think I missed
> > > that step.
> > >
> > > On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <
> [EMAIL PROTECTED]>
> > wrote:
> > >> Hearing no other remarks, I will proceed to disconnect and make the
> > >> version 1.0-SNAPSHOT, and call a release vote RSN.
> > >
> >
>

The Lucene/Solr community have decided to loosely couple release schedules
and explicitly decided to not lock version numbers.  One of their arguments
was that it would confuse users, which doesn't apply for us.  The other
argument was that either side should be free to have a release that was
completely compatible without the other side having to bump version number.
This especially applies to major version numbers.

The question is the degree of coupling.  I expect that we will have nearly
zero coupling between collections releases and mahout releases, if only
because there should be a vanishingly small number of collections releases.
In some sense, tying the collections and core version numbers together
should be about as compelling as, say, tying mahout to hadoop releases.  We
may need to have a new Mahout version when 0.21 or hadoop 1.0 comes out, but
we definitely should be free to release many times before that happens.  The
only difference is that with collections, we will really have a say in
whether the maven artifact gets pushed onto the main repositories.

On Tue, Apr 6, 2010 at 11:48 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> I agree in principal, but having a whole different set of versionings seems
> kinda... messy?  If m-collections goes 1.0, and then 1.1, and then m-math
> goes 1.0, and core goes to 0.5, we have a whole pile of different version
> numbers to keep track of.
>
> Didn't Lucene and Solr just intentionally do the reverse, locking their
> release
> numbers and schedules?  And now we're doing the opposite on a less
> mature project?  What exactly do we gain by this?
>
>  -jake
>
> On Tue, Apr 6, 2010 at 11:43 AM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
>
> > For what it is worth, I actually prefer this approach to the multi-pom
> > approach in many cases.  If it really is a separate thing, it might as
> well
> > have a separate release schedule and artifact.  If it isn't a separate
> > thing, then you might as well use a single pom.  This heuristic doesn't
> > always work, and I know that people with more maven experience than I
> have
> > work under different principles.  My explanation for the difference in
> > opinion is that the separated project may be better for those with
> limited
> > maven experience while the more complex arrangement may be better for
> those
> > with a native fluency.
> >
> > As such, giving mahout-collections and ultimately mahout-math their own
> > version number is a fine thing.  Also will pretty much always exhibit
> more
> > maturity than the core mahout project if only because the needs they
> > fulfill
> > are better understood.  That makes the 1.0 version for collections match
> > the
> > 0.4 upcoming version for Mahout.
> >
> > On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies <[EMAIL PROTECTED]
> > >wrote:
> >
> > > Substance:
> > >
> > > 1: remove collections-codegen and collections from the top-level pom's
> > > module list.
> > > 2: change their parents to point to the apache parent.
> > > 3: tweak their poms so that the release plugin works right with them.
> > > 4: release them
> > > 5: change rest of mahout to consume release.
> > >
> > >
> > > On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
> > > > This still lives in Mahout, just has a different version number?
> > > > what's the substance of the change in the short-term; I think I
> missed
> > > > that step.
> > > >
> > > > On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <
> > [EMAIL PROTECTED]>
> > > wrote:
> > > >> Hearing no other remarks, I will proceed to disconnect and make the
> > > >> version 1.0-SNAPSHOT, and call a release vote RSN.
> > > >
> > >
> >
>

I should have said "there should SOON be a vanishingly small number of
collections releases".  Clearly that isn't so just yet.

On Tue, Apr 6, 2010 at 12:09 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> if only because there should be a vanishingly small number of collections
> releases

On Tue, Apr 6, 2010 at 3:10 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I should have said "there should SOON be a vanishingly small number of
> collections releases".  Clearly that isn't so just yet.
>
> On Tue, Apr 6, 2010 at 12:09 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> if only because there should be a vanishingly small number of collections
>> releases

Until we all all the unit tests and remove all the deprecations, I
expect a some releases, as per Ted's later message. Then, it should
get really, really, quiet. Unless we decide that it's the right place
for things like bloom filters.
I should also add that I still have hopes that collections will
transmigrate to commons, so making it more independent of mahout is
better.

>

Where are we on the consensus process?

Jake, have Ted and I satisfied you? Does this call for a VOTE to be
sure that we're on the same page?
On Tue, Apr 6, 2010 at 3:33 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 6, 2010 at 3:10 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> I should have said "there should SOON be a vanishingly small number of
>> collections releases".  Clearly that isn't so just yet.
>>
>> On Tue, Apr 6, 2010 at 12:09 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>
>>> if only because there should be a vanishingly small number of collections
>>> releases
>
> Until we all all the unit tests and remove all the deprecations, I
> expect a some releases, as per Ted's later message. Then, it should
> get really, really, quiet. Unless we decide that it's the right place
> for things like bloom filters.
>
>
> I should also add that I still have hopes that collections will
> transmigrate to commons, so making it more independent of mahout is
> better.
>
>>
>

I guess I'm fine with whatever, making fast releases of collections is
in fact pretty cool, it will give us practice with making releases in mahout
in general.  And if we can do this for mahout-math as well, some of us who
care about, for example, eventually adding unit tests for all of the old
Colt
stuff, can do so bit by bit, and undeprecate code which is now tested, and
then re-release with new version number frequently there as well.

I'm in favor, I guess, of:

1: remove collections-codegen and collections from the top-level pom's
module list.
2: change their parents to point to the apache parent.
3: tweak their poms so that the release plugin works right with them.
4: release them
5: change rest of mahout to consume release.

  -jake

On Tue, Apr 6, 2010 at 12:44 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:

> Where are we on the consensus process?
>
> Jake, have Ted and I satisfied you? Does this call for a VOTE to be
> sure that we're on the same page?
>
>
> On Tue, Apr 6, 2010 at 3:33 PM, Benson Margulies <[EMAIL PROTECTED]>
> wrote:
> > On Tue, Apr 6, 2010 at 3:10 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >> I should have said "there should SOON be a vanishingly small number of
> >> collections releases".  Clearly that isn't so just yet.
> >>
> >> On Tue, Apr 6, 2010 at 12:09 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >>
> >>> if only because there should be a vanishingly small number of
> collections
> >>> releases
> >
> > Until we all all the unit tests and remove all the deprecations, I
> > expect a some releases, as per Ted's later message. Then, it should
> > get really, really, quiet. Unless we decide that it's the right place
> > for things like bloom filters.
> >
> >
> > I should also add that I still have hopes that collections will
> > transmigrate to commons, so making it more independent of mahout is
> > better.
> >
> >>
> >
>

Very cool.  Very exciting.

Benson, that sounds like consensus to me.

On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> ... I'm in favor, I guess, of:
>
> 1: remove collections-codegen and collections from the top-level pom's
> module list.
> 2: change their parents to point to the apache parent.
> 3: tweak their poms so that the release plugin works right with them.
> 4: release them
> 5: change rest of mahout to consume release.
>
>   -jake
>
>

Indeed. Off I go.

On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Very cool.  Very exciting.
>
> Benson, that sounds like consensus to me.
>
> On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
>> ... I'm in favor, I guess, of:
>>
>> 1: remove collections-codegen and collections from the top-level pom's
>> module list.
>> 2: change their parents to point to the apache parent.
>> 3: tweak their poms so that the release plugin works right with them.
>> 4: release them
>> 5: change rest of mahout to consume release.
>>
>>   -jake
>>
>>
>

+1.  Release early, release often.

-Grant

On Apr 6, 2010, at 5:12 PM, Benson Margulies wrote:

> Indeed. Off I go.
>
> On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Very cool.  Very exciting.
>>
>> Benson, that sounds like consensus to me.
>>
>> On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>>
>>> ... I'm in favor, I guess, of:
>>>
>>> 1: remove collections-codegen and collections from the top-level pom's
>>> module list.
>>> 2: change their parents to point to the apache parent.
>>> 3: tweak their poms so that the release plugin works right with them.
>>> 4: release them
>>> 5: change rest of mahout to consume release.
>>>
>>>   -jake
>>>
>>>
>>

Great proposal. Hopefully this will push Mahout core to have faster releases
Robin
On Wed, Apr 7, 2010 at 3:29 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:

> +1.  Release early, release often.
>
> -Grant
>
> On Apr 6, 2010, at 5:12 PM, Benson Margulies wrote:
>
> > Indeed. Off I go.
> >
> > On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >> Very cool.  Very exciting.
> >>
> >> Benson, that sounds like consensus to me.
> >>
> >> On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
> >>
> >>> ... I'm in favor, I guess, of:
> >>>
> >>> 1: remove collections-codegen and collections from the top-level pom's
> >>> module list.
> >>> 2: change their parents to point to the apache parent.
> >>> 3: tweak their poms so that the release plugin works right with them.
> >>> 4: release them
> >>> 5: change rest of mahout to consume release.
> >>>
> >>>   -jake
> >>>
> >>>
> >>
>
>

I count enough votes. This vote is closed.

On Tue, Apr 6, 2010 at 8:04 PM, Robin Anil <[EMAIL PROTECTED]> wrote:
> Great proposal. Hopefully this will push Mahout core to have faster releases
>
>
> Robin
>
>
> On Wed, Apr 7, 2010 at 3:29 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
>> +1.  Release early, release often.
>>
>> -Grant
>>
>> On Apr 6, 2010, at 5:12 PM, Benson Margulies wrote:
>>
>> > Indeed. Off I go.
>> >
>> > On Tue, Apr 6, 2010 at 4:23 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >> Very cool.  Very exciting.
>> >>
>> >> Benson, that sounds like consensus to me.
>> >>
>> >> On Tue, Apr 6, 2010 at 1:02 PM, Jake Mannix <[EMAIL PROTECTED]>
>> wrote:
>> >>
>> >>> ... I'm in favor, I guess, of:
>> >>>
>> >>> 1: remove collections-codegen and collections from the top-level pom's
>> >>> module list.
>> >>> 2: change their parents to point to the apache parent.
>> >>> 3: tweak their poms so that the release plugin works right with them.
>> >>> 4: release them
>> >>> 5: change rest of mahout to consume release.
>> >>>
>> >>>   -jake
>> >>>
>> >>>
>> >>
>>
>>
>

We gain the ability to release collections more frequently. *because*
it is less mature, it needs that.

On Tue, Apr 6, 2010 at 2:48 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
> I agree in principal, but having a whole different set of versionings seems
> kinda... messy?  If m-collections goes 1.0, and then 1.1, and then m-math
> goes 1.0, and core goes to 0.5, we have a whole pile of different version
> numbers to keep track of.
>
> Didn't Lucene and Solr just intentionally do the reverse, locking their
> release
> numbers and schedules?  And now we're doing the opposite on a less
> mature project?  What exactly do we gain by this?
>
>  -jake
>
> On Tue, Apr 6, 2010 at 11:43 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
>> For what it is worth, I actually prefer this approach to the multi-pom
>> approach in many cases.  If it really is a separate thing, it might as well
>> have a separate release schedule and artifact.  If it isn't a separate
>> thing, then you might as well use a single pom.  This heuristic doesn't
>> always work, and I know that people with more maven experience than I have
>> work under different principles.  My explanation for the difference in
>> opinion is that the separated project may be better for those with limited
>> maven experience while the more complex arrangement may be better for those
>> with a native fluency.
>>
>> As such, giving mahout-collections and ultimately mahout-math their own
>> version number is a fine thing.  Also will pretty much always exhibit more
>> maturity than the core mahout project if only because the needs they
>> fulfill
>> are better understood.  That makes the 1.0 version for collections match
>> the
>> 0.4 upcoming version for Mahout.
>>
>> On Tue, Apr 6, 2010 at 11:17 AM, Benson Margulies <[EMAIL PROTECTED]
>> >wrote:
>>
>> > Substance:
>> >
>> > 1: remove collections-codegen and collections from the top-level pom's
>> > module list.
>> > 2: change their parents to point to the apache parent.
>> > 3: tweak their poms so that the release plugin works right with them.
>> > 4: release them
>> > 5: change rest of mahout to consume release.
>> >
>> >
>> > On Tue, Apr 6, 2010 at 1:44 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>> > > This still lives in Mahout, just has a different version number?
>> > > what's the substance of the change in the short-term; I think I missed
>> > > that step.
>> > >
>> > > On Tue, Apr 6, 2010 at 6:41 PM, Benson Margulies <
>> [EMAIL PROTECTED]>
>> > wrote:
>> > >> Hearing no other remarks, I will proceed to disconnect and make the
>> > >> version 1.0-SNAPSHOT, and call a release vote RSN.
>> > >
>> >
>>
>