Glad to be of help. :)
Frankly, I believe that the rate at which patches are processed/audited/committed has a lot to do
with us non-committers (or simply interested parties) testing and reviewing those patches.
A common cry on JIRA: "Will somebody test this patch please? Gonna commit inside of 48 hours."
> Jonathon - I'm sure that you may be able to process patches VERY quickly
> - and that my friend, is a totally invaluable resource to have going
> on. I mean please do more of them and report your findings, so that the
> project can move forward even more quickly. It doesn't take a committer
> role to be actively involved in this.
>
> You may in fact grow into a role of a committer if you continue with the
> project and are able to help push the project forward as much as you
> appear to be motivated to do. Thanks for being here - and keep up the
> JIRA testing - it means A LOT to all of us.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
>
http://www.hotwaxmedia.com>
> o:801.649.6594
> f:801.649.6595
>
> On Jan 26, 2007, at 10:00 AM, Jonathon -- Improov wrote:
>
>> Tim,
>>
>> For some reason I can't quite put my finger on, I am confident that I
>> can process patches to my own sandbox faster than the OFBiz committers
>> can process patches to OFBiz.
>>
>> Maybe it's because I am becoming an OFBiz addict that I work on it
>> tirelessly and relentlessly? I don't know.
>>
>> And also, for some reason that escapes me, my commits seem to be more
>> tested and less unsettling than some of OFBiz's.
>>
>> Maybe it's because I don't have 10 paying clients to serve at once.
>>
>> Or maybe I do understand the OFBiz framework enough to be able to do a
>> "OFBiz-wide grep or other scan" in order to check whether my patches
>> break stuff. Sort of like what a good IDE will do, probably. But I'm
>> always stone-age, stick to simple tools (with good mind map).
>>
>> There's still this need to put together stable audited releases. I'm
>> sort of doing that with my personal "sandbox" on my harddisk.
>>
>> I can't guarantee I can do the same if I'm a committer in OFBiz myself.
>>
>> Jonathon
>>
>> Tim Ruppert wrote:
>>> I know this sounds overly simplified, but someone please explain to
>>> me why this doesn't work:
>>> 1. Someone - let's say Chris has a great idea for a new project
>>> 2. He creates a JIRA issue describing it
>>> 3. He attaches an initial patch
>>> 4. Someone else - let's say Daniel decides that he wants to
>>> contribute to this effort and downloads the patch
>>> 5. He makes some improvements, so he updates the existing patch as
>>> well as adds another patch containing additional data
>>> 6. Chris downloads it and makes some mods and reposts.
>>> Now, to me this doesn't seem that crazy - and is totally legal. And
>>> . . . just so you know - replace Chris with Tim and Daniel with
>>> either Anil or Ashish and you have EXACTLY what happened with the
>>> anonymous checkout process!
>>> This shouldn't be this hard guys. My suggestion would be to TRY one
>>> of these in this format and if you can't do it this way - THEN let's
>>> try and address it. A separately maintained sandbox is absolutely no
>>> different than managing patches - since both have to deal with
>>> integration back into the OFBiz trunk in some form or fashion.
>>> Personally, I think the patches will be EASIER to maintain because
>>> they will allow you to make changes to existing code in an easier,
>>> more trackable format. The alternative would be for you to maintain
>>> a sandbox - AND patches for updates to the source - doesn't that
>>> sound MORE tedious?
>>> Anyways, thanks for listening to my ramble.
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>>
http://www.hotwaxmedia.com>>> o:801.649.6594
>>> f:801.649.6595
>>> On Jan 26, 2007, at 3:04 AM, Daniel Kunkel wrote:
>>>> Hi
>>>>
>>>> First, please understand I hold you in incredibly high regard, and
>>>> apologize for causing any frustration... You and Andy have created an
>>>> amazing software tool that I'm basing my business on, and you've given
>>>> it away. I love that! As you can see, your efforts are now multiplying
>>>> in to a system that has a life of its own, which will eventually change
>>>> the face of many businesses throughout the world.
>>>> During this process, you've needed to exercise great control in choosing
>>>> what to allow into the project, and what to reject. Since I often update
>>>> my production system to the svn head, I'm very glad someone is there
>>>> watching, and if you think about it, it makes sense that access has been
>>>> very limited to just the professionals that have devoted themselves to
>>>> the project.
>>>>
>>>> However, as it grows, there are more and more newbies that want to help
>>>> in their little way. Many *non-committers* who have wanted to give back
>>>> to the project have been stifled and frustrated, often because their
>>>> contributions were not appropriate, but sometimes simply because the
>>>> committers are too busy to review/test/correct their contributions. In
>>>> other cases, the resultant solutions are too specific to just their
>>>> business, or as a employee, the business although willing to donate the
>>>> code back, was not willing to devote the time needed to make the
>>>> consumable by the project at large.
>>>> So, what can we do to create a space where non-committers can share
>>>> their bits with the community? Please understand, we are agreed that
>>>> neither of us would want their contributions running on a system.
>>>>
>>>> - The source forge sandbox isn't really a good fit, because, as Chris
>>>> has researched, the legal ramifications of donating it back to the
>>>> project outweigh the benefits begotten from the group effort.
>>>>
>>>> - Forcing developers to work alone isn't working very well.
>>>>
>>>> - A sandbox with lots of committers isn't going to work. Thanks for
>>>> explaining that in your e-mail, I didn't realize this wasn't workable
>>>> till now.
>>>>
>>>> - Jira isn't working.
>>>> - The wiki could possibly work, but it doesn't go through the legal
>>>> process with each submission, and I cringe even thinking of trying to
>>>> work with code in wiki. Eek.
>>>>
>>>> - Even using the wiki, to catalog which jira issues are "in play" is
>>>> unwieldy. Patch nightmare actually.
>>>>
>>>> David, can you think of way to make a space in this community where the
>>>> new/non-polished committers can easily share and play together with
>>>> their ideas where they won't hurt the bigger project until the
>>>> components are well proven?
>>>>
>>>> Would it work to have a sandbox that is managed by the existing
>>>> committers, or perhaps a few new committers? As a committer, you
>>>> wouldn't need to give nearly the same amount of time and attention to
>>>> trying to make sure the commitment met best practices, free of bugs,
>>>> etc. Any developer could share their stuff that they've implemented for
>>>> their business, or other neat components. And, since the commitments
>>>> would be in svn on the other side of the "Donate to the Apache
>>>> Foundation legal radio button, it'd be easy for these developers to
>>>> collaborate and slowly bring unworkable buggy messes into gold. Finally,
>>>> users could easily find and try the components without mucking with
>>>> patch files, etc.
>>>>
>>>> Thanks
>>>>
>>>> Daniel
>>>>
>>>> On Fri, 2007-01-26 at 00:45 -0700, David E. Jones wrote:
>>>>> Okay, I just wrote a huge thing and deleted it. There might have
>>>>> been good stuff in there, but I am really frustrated because I've
>>>>> said it all before and based on the comments from Chris it doesn't
>>>>> seem like anything it making it out there.
>>>>>
>>>>> If you're not a lawyer, then reference documents and processes
>>>>> already established.
>>>>>
>>>>> I'm not even going to bother going into detail unless people are
>>>>> willing to:
>>>>>
>>>>> 1. describe their understanding of how what they want to do would
>>>>> be done under current policy
>>>>> 2. describe why that doesn't work for what you want to do
>>>>> 3. describe how the existing processes need to changed in order to
>>>>> accommodate it
>>>>>
>>>>> A sandbox is a BAD BAD BAD BAD IDEA. Like you mentioned Daniel it
>>>>> would create a huge mess. I'm afraid one of two things would happen:
>>>>>
>>>>> 1. nothing
>>>>> 2. a lot
>>>>>
>>>>> In the case of number 1 it's not worth the effort to set it up. In
>>>>> the case of #2 it would required more effort to administer and
>>>>> monitor than we have resources for in OFBiz. There is no way I'd
>>>>> even think about doing this under the ASF umbrella because I am
>>>>> not willing to take on the responsibility of vetting a large
>>>>> number of committers and recommending them as committers in the
>>>>> ASF, which is BIG DEAL, and a responsibility and some people seem
>>>>> to be forgetting that.
>>>>>
>>>>> If you want to be a committer you have to help with the project.
>>>>> You have to take ownership of it, defend it, be committed to it,
>>>>> and so on. Okay, now I'm doing what I was in the 2 page email I
>>>>> just deleted and I'm stopping.
>>>>>
>>>>> If you want to know more about becoming and being a committer and
>>>>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>>>
>>>>> I don't know WHY these questions are coming up here. Stop asking
>>>>> them. Read the documents. I won't be baited into this any more.
>>>>> It's a waste of time, and all based on supposition and not any
>>>>> real problems or issues as far as I can see.
>>>>>
>>>>> If you develop something outside of OFBiz and want to contribute
>>>>> it, here is the page describing how it works:
>>>>>
>>>>>
http://incubator.apache.org/ip-clearance/index.html>>>>>
>>>>> This is basically a streamlined incubation process for code going
>>>>> into existing projects.
>>>>>
>>>>> If you really want to help and be involved in the project it means
>>>>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it
>>>>> easier to get your own stuff in but if that is all you're about
>>>>> related to the project, then being a committer isn't for you.
>>>>>
>>>>> If you want to know more about contributing and being a committer,
>>>>> read the docs:
>>>>>
>>>>>
http://docs.ofbiz.org/x/mQ>>>>>
http://docs.ofbiz.org/x/r>>>>>
>>>>> If you want to know more about licensing and legal issues, read
>>>>> the docs:
>>>>>
>>>>>
http://incubator.apache.org/incubation/Incubation_Policy.html>>>>>
http://incubator.apache.org/ip-clearance/index.html>>>>>
http://www.apache.org/foundation/how-it-works.html>>>>>
http://www.apache.org/foundation/licence-FAQ.html>>>>>
http://www.apache.org/legal/src-headers.html>>>>>
>>>>> For a lot of good information, broaden the scope and study under:
>>>>>
>>>>>
http://www.apache.org/dev/>>>>>
>>>>> These were not written because someone was looking for some
>>>>> entertainment. They were written so things wouldn't have to be
>>>>> explained over and over.
>>>>>
>>>>> I'm calling it a day now, as soon as I take care of some real
>>>>> issues, and as long as my son with the flu doesn't throw up again.
>>>>> Sorry, this is really frustrating, and really silly. Reality
>>>>> sucks, but we all have to live with it.
>>>>>
>>>>> If people want to help, then help. Don't just ask for help. Start
>>>>> by being a giver, not a taker.
>>>>>
>>>>> If this sounds a bit harsh, great! Go for a walk and think about
>>>>> how things work in real life, then read it again. If you're still
>>>>> upset, read it again. Then go read all of the documents
>>>>> referenced. Then if you still have a question, send it on in, but
>>>>> PLEASE try to look at it from the point of a MEMBER of the OFBiz
>>>>> community, and not a user of OFBiz who really doesn't want to get
>>>>> involved.
>>>>>
>>>>> If you're asking "how are you going to solve this problem" then
>>>>> you're asking the wrong question. If you want to participate as
>>>>> "how can I solve this problem", if "I" can't, then do with "how
>>>>> can we solve this problem". I don't mean that is what should be in
>>>>> your email, I mean that is what should be in your head. If you
>>>>> can't find an answer yourself that is 100% okay, just start a
>>>>> discussion and accept what you asked for.
>>>>>
>>>>> If you don't like the answer explain why it doesn't work for you,
>>>>> which brings us back to the beginning of this email...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>>>
>>>>>> David
>>>>>>
>>>>>> Can you explain your reticence to adding an Apache OFBiz sandbox where
>>>>>> more members of the community could share their work?
>>>>>>
>>>>>> I can see this section possibly getting a disorganized over time with
>>>>>> *junk*... but it can be deleted easily enough. As a top level project
>>>>>> would it possible and better to organize a sub project for this?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>>>> I think we're talking about two different things. You're
>>>>>>> talking about
>>>>>>> developing and I'm talking about legal issues. The manner of
>>>>>>> developing was already discussed in OFBIZ-499. The only legal way to
>>>>>>> use JIRA to collaborate this type of thing is to keep sending updated
>>>>>>> patches to JIRA or to have a committer review and add it to a
>>>>>>> specialized application. Neither one of these is speed of
>>>>>>> development
>>>>>>> friendly.
>>>>>>>
>>>>>>> Legal concerns wouldn't have been one of the primary driving
>>>>>>> forces of
>>>>>>> moving to the ASF if it were true that "we've done fine for years".
>>>>>>> The project still has technical exposure to a C & D order as the CLA
>>>>>>> only covered works the copyright holder gave directly to the ASF not
>>>>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>>>>> incubation. IANAL, and I don't think there is significant exposure,
>>>>>>> but it is still there. That opinion isn't based on the vehicle
>>>>>>> used to
>>>>>>> create Apache OFBiz, but on the impression of kindheartedness
>>>>>>> from the
>>>>>>> members of the community prior to incubation.
>>>>>>>
>>>>>>> I don't want to speculate on the legal relationship the group that
>>>>>>> worked on the anon checkout had, but I would suspect that it
>>>>>>> generated
>>>>>>> some negative legal exposure as well and that the proposed setup of
>>>>>>> Developers Conference will add to that.
>>>>>>>
>>>>>>> The only feedback that I've received from the general incubator list
>>>>>>> are speculations, all with the caveat that the poster is not a lawyer
>>>>>>> either and no one has been willing to post it to the legal-discuss
>>>>>>> list.
>>>>>>>
>>>>>>> This issue is one of the MAJOR reasons for the existence of non-
>>>>>>> profit
>>>>>>> entities like the ASF, FSF, and SPI. So again, I ask you to
>>>>>>> reconsider
>>>>>>> the need of a more public sandbox where this kind of community
>>>>>>> collaboration can be done without the complications of copyright
>>>>>>> infringement, or at the very least pose the question to legal-discuss
>>>>>>> for a formal opinion from those representing the ASF's interests. It
>>>>>>> is my understanding that when it's added to Apache owned SVN, ASF is
>>>>>>> the copyright holder of the collective work instead of an impromptu
>>>>>>> partnership where the individuals have no legal authority to offer a
>>>>>>> collective work.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Chris
>>>>>>> --- "David E. Jones" <
[hidden email]
>>>>>>> <mailto:
[hidden email]>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I REALLY don't think you need a sandbox for this. We've done
>>>>>>>> fine for
>>>>>>>>
>>>>>>>> years without one, even with the recently re-done ecommerce
>>>>>>>> anonymous
>>>>>>>>
>>>>>>>> checkout process and alternative checkout processes which were
>>>>>>>> developed entirely outside of OFBiz.
>>>>>>>>
>>>>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>>>>> doing and having a clear goal to work towards, a design of sorts if
>>>>>>>> you will. A sandbox won't help that.
>>>>>>>>
>>>>>>>> Once you have a design you can start building it without
>>>>>>>> touching the
>>>>>>>>
>>>>>>>> current stuff, just make it an alternate path and don't break
>>>>>>>> anything existing along the way. Once it is complete, then another
>>>>>>>> patch can go in to remove the old code.
>>>>>>>>
>>>>>>>> It's that simple. That process has been followed well over a hundred
>>>>>>>>
>>>>>>>> times over the life of OFBiz and even for those with commit access
>>>>>>>> it's the only way to go. If you don't have commit access, it's even
>>>>>>>> better because you can develop until you're stuck or out of time,
>>>>>>>> then throw in a patch and have it committed without breaking
>>>>>>>> anything
>>>>>>>>
>>>>>>>> else, even if the new thing isn't working 100%.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>>>
>>>>>>>>> Hey Anil,
>>>>>>>>>
>>>>>>>>> I've begun some of this already. I'm taking the approach of
>>>>>>>> passing
>>>>>>>>> the cart to a simple method that first checks the order type and
>>>>>>>> then
>>>>>>>>> calls a method or service that is focused on that order type. Each
>>>>>>>>> order type service will call a multitude of methods/services that
>>>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>>>
>>>>>>>>> I would love to collaborate on this, but because of the size, it's
>>>>>>>>> rather difficult to do by passing patches back and forth through
>>>>>>>> JIRA
>>>>>>>>> without having a reference point that SVN provides. This is one of
>>>>>>>>> those things that the ofbiz-sandbox project would be good for, but
>>>>>>>> it
>>>>>>>>> still has a legal issue that will prevent it from being entered
>>>>>>>> back
>>>>>>>>> into the project. I can as an individual grant Apache the license
>>>>>>>> it
>>>>>>>>> needs for the work I do, you as an individual can grant Apache the
>>>>>>>>> license it needs for the work you do, but without each of us
>>>>>>>> assuming
>>>>>>>>> the liability of a partnership we cannot grant a license for the
>>>>>>>> work
>>>>>>>>> as a whole. The only way around this is to use ofbiz-sandbox SVN
>>>>>>>> and
>>>>>>>>> make patches for each commit and each of us resubmit our own patch
>>>>>>>> to
>>>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>>>
>>>>>>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>>>>> commit will be licensed to Apache, and Apache will be the owner of
>>>>>>>> the
>>>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>>>> owner.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --- Anil Patel <
[hidden email]
>>>>>>>>> <mailto:
[hidden email]>> wrote:
>>>>>>>>>
>>>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>>>> interested in
>>>>>>>>>> contributing towards making Order Entry process more flexible. If
>>>>>>>>>> there are
>>>>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>>>>> request one
>>>>>>>>>> of the commiters who has interest in this to Please lead this
>>>>>>>> effort.
>>>>>>>>>>
>>>>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>>>>> some
>>>>>>>>>> high
>>>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>>>>> simple
>>>>>>>>>> methods.
>>>>>>>>>> 2) Moving process control logic from event handlers to Controller
>>>>>>>>>> file.
>>>>>>>>>>
>>>>>>>>>> Any Ideas
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Anil Patel
>>>>>>>>>>
>>>>>>>>>> On 1/16/07, David E. Jones <
[hidden email]
>>>>>>>>>> <mailto:
[hidden email]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>>>>> meant
>>>>>>>>>>> mainly for those who want to be involved with development of
>>>>>>>> OFBiz
>>>>>>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>>>>>>> results will all be going right back into OFBiz. Still, everyone
>>>>>>>> is
>>>>>>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>>>>>>> who
>>>>>>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>>>>>>> please forward it on to them.
>>>>>>>>>>>
>>>>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>>>>>>> come. It would be great to have, for example, people like
>>>>>>>> business
>>>>>>>>>>> analysts and technical writers to help with requirements, design,
>>>>>>>>>> and
>>>>>>>>>>> documentation and such would be great!
>>>>>>>>>>>
>>>>>>>>>>> Included below is the original email about this, and most of the
>>>>>>>>>>> information there is still applicable. Here are a few decisions,
>>>>>>>>>>> based on feedback:
>>>>>>>>>>>
>>>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>>>>>>> and
>>>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>>>
>>>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>>>> recommend
>>>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>>>> big-group
>>>>>>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>>>>>>> the
>>>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>>>
>>>>>>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>>>>> here,
>>>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>>>>> deserts
>>>>>>>>>>> and canyons south of here)
>>>>>>>>>>>
>>>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>>>>>>> will
>>>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>>>> wireless
>>>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>>>> access;
>>>>>>>>>> we
>>>>>>>>>>> will have at least 2 projectors and perhaps other large monitors
>>>>>>>> to
>>>>>>>>>>> facilitate group development and discussion
>>>>>>>>>>>
>>>>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>>>>> we'll
>>>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>>>>> first
>>>>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>>>>> around
>>>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>>>> various
>>>>>>>>>>> restaurants within walking distance
>>>>>>>>>>>
>>>>>>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>>>>>>> lot
>>>>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>>>>> perhaps
>>>>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>>>>>>> big
>>>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>>>
>>>>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>>>>> quite
>>>>>>>>>>> a bit of interest in various things on the original list I
>>>>>>>> included
>>>>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>>>>> project
>>>>>>>>>>> management functionality
>>>>>>>>>>>
>>>>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>>>>> please
>>>>>>>>>>> contact me by email (
[hidden email]
>>>>>>>>>>> <mailto:
[hidden email]>) with the following
>>>>>>>>>>> information:
>>>>>>>>>>>
>>>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>>>> different
>>>>>>>>>>> than from address)
>>>>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>>>>> with
>>>>>>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>>>> 5. snack/diet preferences
>>>>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>>>>> rent/
>>>>>>>>
>>>>>>> === message truncated ===
>>>>>>>
>>>>>> --
>>>>>> Daniel
>>>>>>
>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>>> Have a GREAT Day!
>>>>>>
>>>>>> Daniel Kunkel
[hidden email]
>>>>>> <mailto:
[hidden email]>
>>>>>> BioWaves, LLC
http://www.BioWaves.com>>>>>> 14150 NE 20th St. Suite F1
>>>>>> Bellevue, WA 98007
>>>>>> 800-734-3588 425-895-0050
>>>>>>
http://www.Apartment-Pets.com http://www.Illusion-Optical.com>>>>>>
http://www.Card-Offer.com http://www.RackWine.com>>>>>>
http://www.JokesBlonde.com http://www.Brain-Fun.com>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>>>
>>>>>
>>>>
>>
>
Locked
smime.p7s (3K) 