Re: [DISCUSS] Community Virtual Meetup, January 2024

[Alessandro Benedetti]

Right now, all of them work for me.

Cheers
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benede...@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io 
LinkedIn  | Twitter
 | Youtube
 | Github



On Wed, 10 Jan 2024 at 05:15, raghavan m  wrote:

> Hey everyone,
> Please vote for one of the following days
>
>- 1/15
>- 1/16
>- 1/17
>- 1/18
>- 1/19
>- 1/22
>
> Time: 9 am pacific time.
> Thanks
> Raghavan
>
> Sent from iPhone
>
>
> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
> wrote:
>
> > Awesome, thanks for volunteering Raghavan!
> >
> > Anyone have thoughts on scheduling?  Absent other strong opinions, maybe
> we
> > could aim for the week of Monday the 15th through Friday the 19th and
> pick
> > a day/time in that range?
> >
> > Best,
> >
> > Jason
> >
> > On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
> wrote:
> >
> > > Happy New Year everyone. I can volunteer for January.
> > >
> > > Sent from iPhone
> > >
> > >
> > > On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski 
> > > wrote:
> > >
> > > > Hey all,
> > > >
> > > > After missing December, It's time once again to start thinking ahead
> to
> > > our
> > > > first Virtual Meetup in the New Year!  As always, there's two main
> > > > questions to answer in terms of planning:
> > > >
> > > > 1. Any volunteers to organize?  Organizer duties are pretty light and
> > are
> > > > summarized here:
> > > > https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> > > > Volunteers
> > > > get some discretion in terms of picking a meeting time/day that works
> > for
> > > > them.  If there are no volunteers by the end of the week, I'm more
> than
> > > > happy to set things up for this month.
> > > >
> > > > 2. When should we meet?  I've started the discussion early this
> month,
> > so
> > > > we've got plenty of days to choose from.  If you have any opinions,
> > > please
> > > > discuss.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > >
> >
>

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Alessandro Benedetti]

Hi all,
thanks for raising this!

I am in favour of:
B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history

But rather than just OPEN, I would probably migrate only the active ones?

I agree it doesn't make sense to duplicate thousands of Jiras.

I would also be ok with C, mine is just a preference not a veto at all.
Cheers
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benede...@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io 
LinkedIn  | Twitter
 | Youtube
 | Github



On Mon, 8 Jan 2024 at 23:57, Jan Høydahl  wrote:

> Bringing attention to this thread again.
>
> Now that Lucene has some experience after the migration and with using
> Issues, labels etc, I'd like to discuss whether we'd want to copy the
> Lucene approach or do something different.
>
> I'm not frequenting the Lucene issue tracker much, and am not either aware
> of a formal evaluation of their issue migration. So appreciate feedback
> from committers who have more exposure from Lucene.
>
> In my mind, we, Solr, have four options
> A) Migrate everything, like Lucene did
> B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
> C) Fresh-start empty GH issues, use JIRA as archive before -mm-dd
> D) Continue with g'old JIRA
>
> I was getting used to the thought of copying Lucene's approach, but
> re-thinking now, I have once again shifted my preference towards C), a
> fresh start. I'll summarize my reasons below with some numbers and
> experience from Lucene's GH issues. Forgive my last rant on this subject :)
>
> 
> I'm a fan of NOT migrating the entire JIRA history to GH. Instead let the
> R/O SOLR-JIRA be the system of record for historic issues forever. I.e.
> start a fresh, empty GH issue tracker for all NEW issues. The main con, two
> systems of record, can imo be mitigated with SearchEngineTechnoloty™.
> Nothing is lost and the duplication of 16k issues in two systems is more
> confusing imo. We could time-box the overlap period where both systems are
> writable to, say 3 months, and at the end of that period, CLOSE all
> still-open JIRA issues with a label and a suitable message.
>
> My arguments for this approach: 1) Solr has 16993 JIRA issues! 2) There
> are 4030 OPEN issues, of which 3681 has not been touched for a year! Why
> would we want 3681 OPEN & stale GitHub issues? Instead I'd like to use
> StaleBot to tag stale issues+PRs and auto close+tag if still stale for N
> days. This is a much-used, proven approach. 3) The Lucene migration caused
> a whopping 642 issue/PR labels <
> https://github.com/apache/lucene/issues/labels>, impossible to browse
> manually. Most labels are trying to record legacy JIRA fields. I checked
> e.g. the "affects-version" <
> https://github.com/apache/lucene/labels?q=affects-version:9>, label in
> Lucene. New labels have not been maintained for recent releases (8.11.2,
> 9.4..9), and those labels are ~NEVER even used when people create new GH
> issues, so why even bother? Same for Priority etc.
> 
>
> Let the discussion continue...
>
> Jan
>
>
> > 3. nov. 2023 kl. 12:33 skrev Jan Høydahl :
> >
> > Bringing this to our attention again. Lucene seems to have survived well
> after the migration to Github issues. They have established a way to work
> with milestones (https://github.com/apache/lucene/milestones) and labels (
> https://github.com/apache/lucene/labels?q=type), and they have updated
> release-wizard with corresponding steps.
> >
> > So are we ready to follow their lead?
> >
> > Jan
> >
> >> 18. okt. 2022 kl. 12:58 skrev Jan Høydahl :
> >>
> >> +1 from me too.
> >>
> >> I'm still not sold on bringing all history from JIRA into GH but that's
> what Lucene did, so perhaps just doing the same (+ lessons learnt) is the
> smoothest path.
> >> Solr would in addition need to find a new process for security issues.
> But we could just fall back on plain security@solr mailing list until a
> new solution is ready.
> >>
> >> Jan
> >>
> >>> 17. okt. 2022 kl. 16:20 skrev David Smiley :
> >>>
> >>> +1 to migrate.
> >>>
> >>> Yeah.  Maybe Tomoko could validate the steps required?  (CC'ed)  Jeb
> listed
> >>> them in JIRA; the steps/mechanics can be discussed there while we leave
> >>> this thread as voting on the major decision.
> >>>
> >>> ~ David Smiley
> >>> Apache Lucene/Solr Search Developer
> >>> http://www.linkedin.com/in/davidwsmiley
> >>>
> >>>
> >>> On Mon, Oct 17, 2022 at 10:12 AM Houston Putman 
> wrote:
> >>>
>  I'm a big +1 on this idea, just like I was for Lucene's migration.
> 
>  Also I think that we could very much mooch off of the monumental
> amounts of
>  hard work that Tomoko and Mike did for Lucene.
> 
>  There w

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Alessandro Benedetti]

Another thing that always bugged me with the Lucene approach is the dualism
issue/PR.

If I don't have a solution for an issue, it makes complete sense to write
the Github Issue and later on a Pull Request may or may not happen.

But if I have a PR (or at least a draft) ready, to me creating the Github
issue is a redundant (and annoying) copy and paste.
Also, I am then confused about where to discuss and comments (the issue or
the PR?).
Effectively nowadays Github PRs have plenty of description, discussion and
review capabilities so in case it's a bug-fix or a well-established code
direction, does it make sense to have the associated issue?

I understand that ideally, you would like to have an issue first, discuss
it with other committers and then start the implementation, but being
honest I realised over the years that this makes contributing a full-time
job and most of us(who are not lucky enough to be paid to contribute) can't
(and shouldn't) commit to that.
So to me, it happens all the time I go deep with a bug fix or new feature,
open the PR and then open the Jira issue.

Could we possibly go with Solr in a direction where there's always at least
one PR for an issue, but not necessarily an issue for a PR?
Just food for thought based on my experience,
Cheers
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benede...@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io 
LinkedIn  | Twitter
 | Youtube
 | Github



On Wed, 10 Jan 2024 at 10:26, Alessandro Benedetti 
wrote:

> Hi all,
> thanks for raising this!
>
> I am in favour of:
> B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
>
> But rather than just OPEN, I would probably migrate only the active ones?
>
> I agree it doesn't make sense to duplicate thousands of Jiras.
>
> I would also be ok with C, mine is just a preference not a veto at all.
> Cheers
> --
> *Alessandro Benedetti*
> Director @ Sease Ltd.
> *Apache Lucene/Solr Committer*
> *Apache Solr PMC Member*
>
> e-mail: a.benede...@sease.io
>
>
> *Sease* - Information Retrieval Applied
> Consulting | Training | Open Source
>
> Website: Sease.io 
> LinkedIn  | Twitter
>  | Youtube
>  | Github
> 
>
>
> On Mon, 8 Jan 2024 at 23:57, Jan Høydahl  wrote:
>
>> Bringing attention to this thread again.
>>
>> Now that Lucene has some experience after the migration and with using
>> Issues, labels etc, I'd like to discuss whether we'd want to copy the
>> Lucene approach or do something different.
>>
>> I'm not frequenting the Lucene issue tracker much, and am not either
>> aware of a formal evaluation of their issue migration. So appreciate
>> feedback from committers who have more exposure from Lucene.
>>
>> In my mind, we, Solr, have four options
>> A) Migrate everything, like Lucene did
>> B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
>> C) Fresh-start empty GH issues, use JIRA as archive before -mm-dd
>> D) Continue with g'old JIRA
>>
>> I was getting used to the thought of copying Lucene's approach, but
>> re-thinking now, I have once again shifted my preference towards C), a
>> fresh start. I'll summarize my reasons below with some numbers and
>> experience from Lucene's GH issues. Forgive my last rant on this subject :)
>>
>> 
>> I'm a fan of NOT migrating the entire JIRA history to GH. Instead let the
>> R/O SOLR-JIRA be the system of record for historic issues forever. I.e.
>> start a fresh, empty GH issue tracker for all NEW issues. The main con, two
>> systems of record, can imo be mitigated with SearchEngineTechnoloty™.
>> Nothing is lost and the duplication of 16k issues in two systems is more
>> confusing imo. We could time-box the overlap period where both systems are
>> writable to, say 3 months, and at the end of that period, CLOSE all
>> still-open JIRA issues with a label and a suitable message.
>>
>> My arguments for this approach: 1) Solr has 16993 JIRA issues! 2) There
>> are 4030 OPEN issues, of which 3681 has not been touched for a year! Why
>> would we want 3681 OPEN & stale GitHub issues? Instead I'd like to use
>> StaleBot to tag stale issues+PRs and auto close+tag if still stale for N
>> days. This is a much-used, proven approach. 3) The Lucene migration caused
>> a whopping 642 issue/PR labels <
>> https://github.com/apache/lucene/issues/labels>, impossible to browse
>> manually. Most labels are trying to record legacy JIRA fields. I checked
>> e.g. the "affects-version" <
>> https://github.com/apache/lucene/labels?q=affects

Re: [DISCUSS] Community Virtual Meetup, January 2024

[Eric Pugh]

I prefer 18,19, or 20….!


> On Jan 10, 2024, at 5:18 AM, Alessandro Benedetti  
> wrote:
> 
> Right now, all of them work for me.
> 
> Cheers
> --
> *Alessandro Benedetti*
> Director @ Sease Ltd.
> *Apache Lucene/Solr Committer*
> *Apache Solr PMC Member*
> 
> e-mail: a.benede...@sease.io
> 
> 
> *Sease* - Information Retrieval Applied
> Consulting | Training | Open Source
> 
> Website: Sease.io 
> LinkedIn  | Twitter
>  | Youtube
>  | Github
> 
> 
> 
> On Wed, 10 Jan 2024 at 05:15, raghavan m  wrote:
> 
>> Hey everyone,
>> Please vote for one of the following days
>> 
>>   - 1/15
>>   - 1/16
>>   - 1/17
>>   - 1/18
>>   - 1/19
>>   - 1/22
>> 
>> Time: 9 am pacific time.
>> Thanks
>> Raghavan
>> 
>> Sent from iPhone
>> 
>> 
>> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
>> wrote:
>> 
>>> Awesome, thanks for volunteering Raghavan!
>>> 
>>> Anyone have thoughts on scheduling?  Absent other strong opinions, maybe
>> we
>>> could aim for the week of Monday the 15th through Friday the 19th and
>> pick
>>> a day/time in that range?
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
>> wrote:
>>> 
 Happy New Year everyone. I can volunteer for January.
 
 Sent from iPhone
 
 
 On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski 
 wrote:
 
> Hey all,
> 
> After missing December, It's time once again to start thinking ahead
>> to
 our
> first Virtual Meetup in the New Year!  As always, there's two main
> questions to answer in terms of planning:
> 
> 1. Any volunteers to organize?  Organizer duties are pretty light and
>>> are
> summarized here:
> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> Volunteers
> get some discretion in terms of picking a meeting time/day that works
>>> for
> them.  If there are no volunteers by the end of the week, I'm more
>> than
> happy to set things up for this month.
> 
> 2. When should we meet?  I've started the discussion early this
>> month,
>>> so
> we've got plenty of days to choose from.  If you have any opinions,
 please
> discuss.
> 
> Best,
> 
> Jason
> 
 
>>> 
>> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: [DISCUSS] Community Virtual Meetup, January 2024

[Jason Gerlowski]

I'll vote for the 18th!

On Wed, Jan 10, 2024 at 9:50 AM Eric Pugh 
wrote:

> I prefer 18,19, or 20….!
>
>
> > On Jan 10, 2024, at 5:18 AM, Alessandro Benedetti 
> wrote:
> >
> > Right now, all of them work for me.
> >
> > Cheers
> > --
> > *Alessandro Benedetti*
> > Director @ Sease Ltd.
> > *Apache Lucene/Solr Committer*
> > *Apache Solr PMC Member*
> >
> > e-mail: a.benede...@sease.io
> >
> >
> > *Sease* - Information Retrieval Applied
> > Consulting | Training | Open Source
> >
> > Website: Sease.io 
> > LinkedIn  | Twitter
> >  | Youtube
> >  | Github
> > 
> >
> >
> > On Wed, 10 Jan 2024 at 05:15, raghavan m  wrote:
> >
> >> Hey everyone,
> >> Please vote for one of the following days
> >>
> >>   - 1/15
> >>   - 1/16
> >>   - 1/17
> >>   - 1/18
> >>   - 1/19
> >>   - 1/22
> >>
> >> Time: 9 am pacific time.
> >> Thanks
> >> Raghavan
> >>
> >> Sent from iPhone
> >>
> >>
> >> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
> >> wrote:
> >>
> >>> Awesome, thanks for volunteering Raghavan!
> >>>
> >>> Anyone have thoughts on scheduling?  Absent other strong opinions,
> maybe
> >> we
> >>> could aim for the week of Monday the 15th through Friday the 19th and
> >> pick
> >>> a day/time in that range?
> >>>
> >>> Best,
> >>>
> >>> Jason
> >>>
> >>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
> >> wrote:
> >>>
>  Happy New Year everyone. I can volunteer for January.
> 
>  Sent from iPhone
> 
> 
>  On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski  >
>  wrote:
> 
> > Hey all,
> >
> > After missing December, It's time once again to start thinking ahead
> >> to
>  our
> > first Virtual Meetup in the New Year!  As always, there's two main
> > questions to answer in terms of planning:
> >
> > 1. Any volunteers to organize?  Organizer duties are pretty light and
> >>> are
> > summarized here:
> > https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> > Volunteers
> > get some discretion in terms of picking a meeting time/day that works
> >>> for
> > them.  If there are no volunteers by the end of the week, I'm more
> >> than
> > happy to set things up for this month.
> >
> > 2. When should we meet?  I've started the discussion early this
> >> month,
> >>> so
> > we've got plenty of days to choose from.  If you have any opinions,
>  please
> > discuss.
> >
> > Best,
> >
> > Jason
> >
> 
> >>>
> >>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com <
> http://www.opensourceconnections.com/> | My Free/Busy <
> http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
>
>

Re: [DISCUSS] Standardizing sysprop naming

[David Smiley]

On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl  wrote:

> Hi,
>
> > Using this one as an example; what would you propose?:
> > * solr.shardSplit.checkDiskSpace.enabled
>
> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
> But say we standardized the first component layer to be one of "query",
> "index", "collection", "schema", "cluster", "node" or whatever set of
> top-level components make sense. Then I guess shard split would be
> "solr.collection.shard.split.checkDiskSpace.enabled" or similar. However, I
> find it hard to find good generic top-level categories for Solr that are
> consise and no overlapping.
>

So the module can't be camel-case but checkDiskSpace can?  What about
hyphens in a sys prop, mapped to an underscore in an env var?

> "solr.collection.shard.split.checkDiskSpace.enabled"

Not bad.
I bet it's hard to find good generic top-level categories.Feel free to
take a stab at this and share for review.  It doesn't need to be perfect,
just not nausea inducing :-)


> > Are you saying the camel case is a problem?
>
> No necessarily. The concern was that there should be a well-defined way to
> translate an SOLR_ENV_VAR into system property, so we don't need to touch
> bin/solr[.cmd] every single time. And it would be hard for an algorithm to
> know that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED
> env.var into the exact combination of dot separation and camelCase used
> above. An alternative could be using a combination of underscore and dash,
> such as "SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate
> underscore with dot and dash with Camelcase. We'd need to disallow dash in
> property names then...
>

Alternatively simply normalize both sys props and env vars using the same
scheme.  In theory it would allow crazy variation but if we only document
each named toggle a certain way then it doesn't matter.

Re: [DISCUSS] Community Virtual Meetup, January 2024

[David Smiley]

18th
or probably any

On Wed, Jan 10, 2024 at 12:15 AM raghavan m  wrote:

> Hey everyone,
> Please vote for one of the following days
>
>- 1/15
>- 1/16
>- 1/17
>- 1/18
>- 1/19
>- 1/22
>
> Time: 9 am pacific time.
> Thanks
> Raghavan
>
> Sent from iPhone
>
>
> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
> wrote:
>
> > Awesome, thanks for volunteering Raghavan!
> >
> > Anyone have thoughts on scheduling?  Absent other strong opinions, maybe
> we
> > could aim for the week of Monday the 15th through Friday the 19th and
> pick
> > a day/time in that range?
> >
> > Best,
> >
> > Jason
> >
> > On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
> wrote:
> >
> > > Happy New Year everyone. I can volunteer for January.
> > >
> > > Sent from iPhone
> > >
> > >
> > > On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski 
> > > wrote:
> > >
> > > > Hey all,
> > > >
> > > > After missing December, It's time once again to start thinking ahead
> to
> > > our
> > > > first Virtual Meetup in the New Year!  As always, there's two main
> > > > questions to answer in terms of planning:
> > > >
> > > > 1. Any volunteers to organize?  Organizer duties are pretty light and
> > are
> > > > summarized here:
> > > > https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> > > > Volunteers
> > > > get some discretion in terms of picking a meeting time/day that works
> > for
> > > > them.  If there are no volunteers by the end of the week, I'm more
> than
> > > > happy to set things up for this month.
> > > >
> > > > 2. When should we meet?  I've started the discussion early this
> month,
> > so
> > > > we've got plenty of days to choose from.  If you have any opinions,
> > > please
> > > > discuss.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > >
> >
>

Re: [DISCUSS] Community Virtual Meetup, January 2024

[Marcus Eagan]

On the 18th, I'll be available to join.

On Wed, Jan 10, 2024 at 7:06 PM David Smiley  wrote:

> 18th
> or probably any
>
> On Wed, Jan 10, 2024 at 12:15 AM raghavan m 
> wrote:
>
> > Hey everyone,
> > Please vote for one of the following days
> >
> >- 1/15
> >- 1/16
> >- 1/17
> >- 1/18
> >- 1/19
> >- 1/22
> >
> > Time: 9 am pacific time.
> > Thanks
> > Raghavan
> >
> > Sent from iPhone
> >
> >
> > On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
> > wrote:
> >
> > > Awesome, thanks for volunteering Raghavan!
> > >
> > > Anyone have thoughts on scheduling?  Absent other strong opinions,
> maybe
> > we
> > > could aim for the week of Monday the 15th through Friday the 19th and
> > pick
> > > a day/time in that range?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
> > wrote:
> > >
> > > > Happy New Year everyone. I can volunteer for January.
> > > >
> > > > Sent from iPhone
> > > >
> > > >
> > > > On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski <
> gerlowsk...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > After missing December, It's time once again to start thinking
> ahead
> > to
> > > > our
> > > > > first Virtual Meetup in the New Year!  As always, there's two main
> > > > > questions to answer in terms of planning:
> > > > >
> > > > > 1. Any volunteers to organize?  Organizer duties are pretty light
> and
> > > are
> > > > > summarized here:
> > > > > https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> > > > > Volunteers
> > > > > get some discretion in terms of picking a meeting time/day that
> works
> > > for
> > > > > them.  If there are no volunteers by the end of the week, I'm more
> > than
> > > > > happy to set things up for this month.
> > > > >
> > > > > 2. When should we meet?  I've started the discussion early this
> > month,
> > > so
> > > > > we've got plenty of days to choose from.  If you have any opinions,
> > > > please
> > > > > discuss.
> > > > >
> > > > > Best,
> > > > >
> > > > > Jason
> > > > >
> > > >
> > >
> >
>


-- 
Marcus Eagan