I've done a couple releases in this project so far (a Log4j and Logging Parent release), so it shouldn't be too hard. I'm thinking we need to copy over the log4j-distribution stuff so we can create source and binary assemblies for uploading to apache.org as well.
On 8 March 2017 at 11:55, Mikael Ståldal <mikael.stal...@magine.com> wrote: > I have never made any Apache release before, so it's probably good if > someone more experienced does it the first time. So I would be grateful if > Matt could do it. > > I can maybe do it the next time. > > On Mar 8, 2017 5:43 PM, "Matt Sicker" <boa...@gmail.com> wrote: > >> If you don't have time to do it, Mikael, I could probably take care of >> it. I'm planning on doing some Commons releases starting this week anyways, >> and the process is fairly similar. >> >> On 8 March 2017 at 06:41, Apache <ralph.go...@dslextreme.com> wrote: >> >>> Yes, go for it. You can look at the Log4J release guide although some >>> steps won't apply. >>> >>> Ralph >>> >>> On Mar 8, 2017, at 5:32 AM, Remko Popma <remko.po...@gmail.com> wrote: >>> >>> I won't be able to do it. :-) Why don't you give it a shot? I suspect >>> you will be driving future changes often so it would be good if you can >>> release such changes without having to wait for others to make time. >>> >>> Remko >>> >>> Sent from my iPhone >>> >>> On Mar 8, 2017, at 18:45, Mikael Ståldal <mikael.stal...@magine.com> >>> wrote: >>> >>> OK, I have updated the log4j-scala repo to bump version to 11.0, and >>> note in README about independent versioning. It should now be ready for >>> release. Who will do the release? >>> >>> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>> >>>> Yes. Scala should be released asap and the site manually modified to >>>> point to it. We would then modify the log4j source to permanently point >>>> there. >>>> >>>> Ralph >>>> >>>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>> Ralph pointed out that we can't make a release of the main repo without >>>> the scala modules until there is a release of the scala modules on their >>>> own. Otherwise, there'd be a regression in the main repo by removing >>>> modules that were there before. >>>> >>>> On 7 March 2017 at 10:54, Remko Popma <remko.po...@gmail.com> wrote: >>>> >>>>> No objection from me to release log4j-scala. >>>>> >>>>> Do you have a versioning scheme that lets log4j-scala and log4j >>>>> upgrade independently? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.stal...@magine.com> >>>>> wrote: >>>>> >>>>> Can we release log4j-scala now? Or to we have to wait for the next >>>>> release of main repo with Scala modules removed? Should we remove the >>>>> Scala >>>>> modules from main repo now? >>>>> >>>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>>> The Scala language versions is already done the same standard way >>>>>> everyone implements Scala libraries (hence the strange naming scheme we >>>>>> already have). I'd imagine that the versions can be completely decoupled >>>>>> by >>>>>> specifying a minimum Log4j API version it requires (though should >>>>>> generally >>>>>> be whatever the latest was at release) and bumping its own version as new >>>>>> features or bugfixes are added. I'd like to see that follow semantic >>>>>> versioning properly, too. >>>>>> >>>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.stal...@magine.com> >>>>>> wrote: >>>>>> >>>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should >>>>>>> be independent in both ways, right? >>>>>>> >>>>>>> I think I have coordination between log4j-scala and Scala language >>>>>>> covered already. >>>>>>> >>>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Mikael, you probably need to plan your versioning scheme to handle >>>>>>>> any combination of the following: >>>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala >>>>>>>> modules >>>>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is >>>>>>>> that >>>>>>>> once they are decoupled, the log4j-scala modules won't be released >>>>>>>> automatically with log4j anymore, someone needs to do the work for >>>>>>>> a log4j-scala release separately. >>>>>>>> * Scala releases: how do you want to sync up with Scala language >>>>>>>> versions? (I guess include major&minor Scala version in the log4j-scala >>>>>>>> module version) >>>>>>>> * log4j-scala module versions: enhancements to these modules, >>>>>>>> independent of the above >>>>>>>> >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I would like to keep package and artifact names, and bump version >>>>>>>> to 11.0. >>>>>>>> >>>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote: >>>>>>>> >>>>>>>>> If you change artifact ids, it's generally a good idea to change >>>>>>>>> packages, too. I've had issues in the past with Feign for instance >>>>>>>>> because >>>>>>>>> they changed groupId/artifactId at one point but kept the same API, >>>>>>>>> so I >>>>>>>>> had two copies on the classpath until I found out there was a >>>>>>>>> duplicate and >>>>>>>>> excluded them (though admittedly not a problem in OSGi environments >>>>>>>>> :P). >>>>>>>>> >>>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> You can do that, but that will probably confuse users too. I >>>>>>>>>> would suggest changing the artifactId and then start at either 1.0 >>>>>>>>>> or 2.0. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal < >>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>> >>>>>>>>>> OK, but then at least we have to start with a version > 2.8. >>>>>>>>>> >>>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache < >>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>> >>>>>>>>>>> I guarantee if you try to keep the same versioning you will >>>>>>>>>>> regret it. >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal < >>>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>>> >>>>>>>>>>> I was under the impression that we were not ready to integrate >>>>>>>>>>> the site from log4j-scala. That's why I considered the release of >>>>>>>>>>> log4j-scala as delayed, since there is no point of releasing it if >>>>>>>>>>> we >>>>>>>>>>> cannot get the site integrated. >>>>>>>>>>> >>>>>>>>>>> But now when Ralph says he's ready to integrate the site, I >>>>>>>>>>> guess we can go ahead and release log4j-scala. >>>>>>>>>>> >>>>>>>>>>> I don't like the idea of having separate versioning for >>>>>>>>>>> log4j-scala, that will be confusing since we have already started >>>>>>>>>>> with the >>>>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on >>>>>>>>>>> log4j-api, >>>>>>>>>>> and I think we want to keep that in sync. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> One issue we came across in practice is that Scala 2.12 >>>>>>>>>>>> requires Java 8, but we don't want to require that for the entire >>>>>>>>>>>> build, so >>>>>>>>>>>> we separated the repo. This also helps avoid making the main log4j >>>>>>>>>>>> repo >>>>>>>>>>>> from taking forever to build and release which can help the RERO >>>>>>>>>>>> idea. >>>>>>>>>>>> Plus, these non-core modules don't change nearly as often as >>>>>>>>>>>> log4j-core or >>>>>>>>>>>> log4j-api, so they don't really need new releases all that often. >>>>>>>>>>>> >>>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma < >>>>>>>>>>>> remko.po...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> To be honest I still don't understand >>>>>>>>>>>>> >>>>>>>>>>>>> * the vision of what we ultimately want to achieve >>>>>>>>>>>>> * how different repos fit into that vision >>>>>>>>>>>>> * what different websites we are planning to create to give >>>>>>>>>>>>> users access to these different modules >>>>>>>>>>>>> * what websites are going to be driven from which modules or >>>>>>>>>>>>> projects >>>>>>>>>>>>> * who of us is going to be driving what aspect of the above >>>>>>>>>>>>> >>>>>>>>>>>>> My lack of understanding is not just limited to the Scala >>>>>>>>>>>>> modules but is about the whole splitting up the release. >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I >>>>>>>>>>>>> think there's already a JIRA or an epic for the above. Adding >>>>>>>>>>>>> some diagrams >>>>>>>>>>>>> there would be very useful.) >>>>>>>>>>>>> >>>>>>>>>>>>> Remko >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I'd be in favour of starting a new release train for the >>>>>>>>>>>>>> Log4j Scala APIs. Not exactly sure which version to start from, >>>>>>>>>>>>>> though. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you use that excuse they will never get released as it >>>>>>>>>>>>>> creates a catch-22. If I release without them then we have a >>>>>>>>>>>>>> regression >>>>>>>>>>>>>> until they are released. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the >>>>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, >>>>>>>>>>>>>> 2.0 or >>>>>>>>>>>>>> whatever. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Once you create the release and deploy it to the web site I >>>>>>>>>>>>>> can modify the web site to point to it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of >>>>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of >>>>>>>>>>>>>> the three >>>>>>>>>>>>>> artifacts will already exist. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why is the release of log4j-scala delayed? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal < >>>>>>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the >>>>>>>>>>>>>> next release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo >>>>>>>>>>>>>> since I thought that it would be released as part of 2.8, >>>>>>>>>>>>>> otherwise I would >>>>>>>>>>>>>> have put it to the main repo as well. But now releasing of the >>>>>>>>>>>>>> log4j-scala >>>>>>>>>>>>>> repo has been delayed and I start to get disappointed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker < >>>>>>>>>>>>>> boa...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Relative symlinks would work for that regardless of version. >>>>>>>>>>>>>> Option 1 it is, then? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink >>>>>>>>>>>>>> so that the log4j site never has to change when the Scala site >>>>>>>>>>>>>> is updated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the >>>>>>>>>>>>>> release manager for log4j-scala. In order for me to implement >>>>>>>>>>>>>> option 2 I >>>>>>>>>>>>>> would have to include the log4j-scala site into the log4j >>>>>>>>>>>>>> release process - >>>>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just >>>>>>>>>>>>>> not doable. >>>>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier >>>>>>>>>>>>>> to maintain >>>>>>>>>>>>>> independently of log4j. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The site repository is laid out like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/ >>>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/ >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Option 1 is to put it here instead: >>>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; >>>>>>>>>>>>>> that's a pretty ugly URL honestly) >>>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory >>>>>>>>>>>>>> >>>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but >>>>>>>>>>>>>> you'd have to manage it alongside log4j core releases. Option 1 >>>>>>>>>>>>>> still >>>>>>>>>>>>>> requires maintenance, too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a specific location in svn where the site pages have >>>>>>>>>>>>>> to be committed, so I don’t really understand option 1. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see two ways of doing that, though: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to >>>>>>>>>>>>>> what I started doing with Log4j Boot. Add redirect pages or >>>>>>>>>>>>>> rewrite rules >>>>>>>>>>>>>> via .htaccess if possible to keep links from breaking. >>>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the >>>>>>>>>>>>>> main site. Depending on how you update the files in svn for a >>>>>>>>>>>>>> site update, >>>>>>>>>>>>>> could this be more annoying to maintain? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would >>>>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, >>>>>>>>>>>>>> otherwise it >>>>>>>>>>>>>> will be a dead link. >>>>>>>>>>>>>> >>>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be >>>>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site >>>>>>>>>>>>>> just has a >>>>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t >>>>>>>>>>>>>> really be >>>>>>>>>>>>>> “integrated” - they will just have links to each other. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that >>>>>>>>>>>>>> need fixes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is >>>>>>>>>>>>>> mostly cosmetic. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory < >>>>>>>>>>>>>> garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving >>>>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I >>>>>>>>>>>>>> really >>>>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue >>>>>>>>>>>>>> I see that >>>>>>>>>>>>>> fixing now is the null classloader issue for which we have a >>>>>>>>>>>>>> patch but it >>>>>>>>>>>>>> does not work for me (see JIRA). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gary >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker < >>>>>>>>>>>>>> boa...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm hoping we can get this released soon as we have some >>>>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with >>>>>>>>>>>>>> 2.9 changes >>>>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or >>>>>>>>>>>>>> forking master >>>>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Integrated log4j-api-scala website into main site >>>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo >>>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo >>>>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, >>>>>>>>>>>>>> but that's for another day. I think getting everything working >>>>>>>>>>>>>> properly in >>>>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can >>>>>>>>>>>>>> figure out if >>>>>>>>>>>>>> our APIs will still work properly in the future or if we need to >>>>>>>>>>>>>> break >>>>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help >>>>>>>>>>>>>> in >>>>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather >>>>>>>>>>>>>> unorthodox abuse of the feature. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> >>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> >>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> >>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ... > > -- Matt Sicker <boa...@gmail.com>
