One thing we haven’t talked about yet is the Ref Guide for 9.0. SOLR-14444 re-organized the entire guide and changed a lot of page names. At the time I merged this into the main branch there was a little bit of comment about trying to provide page redirects for the changed page names but AFAIK no one has worked on that yet at all (SOLR-15557).
Then I embarked on trying to move us to use Antora instead of Jekyll (https://cwiki.apache.org/confluence/display/SOLR/Antora+Migration+Notes), which when complete will dramatically change page URL paths. It would be sensible and less disruptive for users if we only make page name/path changes once, but it isn’t ready yet. I could try to make a big push to get it done, but I will need some help, and of course it is a major change so sort of technically violates the intent of code freeze so I won’t kill myself if folks are going to balk at some point in February if it does actually get done in time. On Jan 9, 2022, 7:56 AM -0600, Jan Høydahl <[email protected]>, wrote: > Hi, > > This is quite simple. > - The 9.0 release is on-going - now on branch_9_0 > - The normal feature feeze rules apply. Anything explicitly approved as > blocker gets in > > We can still consider adding features to the branch if the benfit/risk ratio > is high enough. Having a long stabilization period also helps. But please ask > before merging. > > The discussion whether we have "enough features" is i.m.o. silly, that's not > how it works, we release as often as possible, and major versions annually. > But this time around we wanted to wait for Lucene 9 which was also delayed. > Now, after almost 2 years on 8.x we have Java11, Lucene 9, gradle build, > embedded Docker image and tons of litle improvements for devs as well as > users. 8x is in bugfix mode so no new feature releases there. We are > currenlty blocked from getting ANY new feature into our users hands. > > Wrt node roles, it was not ok to knowingly sabotage the feature freeze, but > I'm not going to revert your commit. I'll put the incident on the > branch-confusion account. The feature appears to be backward compat and high > benefit, but it touches lots of core code paths, so I'd say there is a > medium/high risk of introducing new bugs. If you do not intend to revert, > please follow test failures and other feedback wrt that feature closely. I'd > also wish the Admin UI would show roles in some way. You can see the > properties in dashboard, but can you see the resolved roles for nodes > explicitly anywhere? I'm also surprised not to find an explicit NODE_ROLES > variable in solr.in.sh for a prominent feature like this - it would be so > much easier for e.g. solr-operator to configure roles for a node if it was > contained in a single env-var. > > Wrt vector search, it may go in if it is ready soon-ish, guess the code is > isolated enough to be low-risk, it can also be called out as experimental. > But i'm not willing to delay the release another month or more (March-April?) > just to wait for yet another feature. > > I'm excited to get 9.0 into the hands of users. Let's make this happen! > > Jan > > > > 9. jan. 2022 kl. 08:16 skrev Ishan Chattopadhyaya > > <[email protected]>: > > > > > Ishan: What warrants a release is subjective, but noone can accuse the > > > Solr project of RUSHING with the 9.0 release. Have a look at the Major > > > Changes in Solr 9 page if you need a reminder of what we have been > > > keeping from our users (and developers not the least) for too long. > > > > Apache Solr is a search engine. In that list, except for the UI page for > > SQL, I don't see a new *search* related feature. A major release without > > any compelling feature will keep users from upgrading. I don't understand > > the hurry now when the vector search support is just around the corner. Why > > can't we make an exception for that particular feature and include it in > > the release, if it gets ready before the release? > > > > > On Sun, Jan 9, 2022 at 11:35 AM Ishan Chattopadhyaya > > > <[email protected]> wrote: > > > > > Ishan, that also means that you only need to revert SOLR-15694 on > > > > > branch_9_0 > > > > > > > > In Apache Solr, committers don't tell other committers to revert > > > > commits without a proper technical justification. You were late in > > > > cutting the release branch for 9.0, and now "need" me to revert my > > > > commit because you're not comfortable with the commit making it to the > > > > release? > > > > > > > > This is very demoralizing. When contributors work for months on a > > > > feature, they hope to see a released version of Solr with that feature. > > > > In the case of SOLR-15694, we took several extra steps to ensure > > > > broader community participation. If you still demand of me to revert > > > > the commit, I'll comply since I don't want to hold up this release. In > > > > that case, I'll backport to a 8.12 release so that users can use the > > > > feature sooner than waiting another 2-3 months for a 9.1 release. > > > > > > > > > On Sun, Jan 9, 2022 at 11:05 AM Noble Paul <[email protected]> > > > > > wrote: > > > > > > The New feature list for 9.0 is > > > > > > > > > > > > * Replica placement plugins > > > > > > * Rate limiting and task management > > > > > > * Certificate Auth Plugin > > > > > > * SQL Query interface in UI > > > > > > > > > > > > None of these are compelling search features which will motivate > > > > > > anyone to upgrade OTOH , vector search is a very attractive feature > > > > > > and even if it we release that as "experimental" users are likely to > > > > > > upgrade > > > > > > > > > > > > So, please consider including that > > > > > > > > > > > > > > > > > > On Sun, Jan 9, 2022 at 11:35 AM Jan Høydahl <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > IMPORTANT > > > > > > > > > > > > > > Just created branch_9_0 off of branch_9x, and bumped version on > > > > > > > branch_9x to 9.1. > > > > > > > > > > > > > > This means that everything is back to normal branch structure, > > > > > > > and the feature freeze is now only on branch_9_0. > > > > > > > > > > > > > > Ishan, that also means that you only need to revert SOLR-15694 on > > > > > > > branch_9_0, and let it remain on branch_9x, while you let it bake. > > > > > > > > > > > > > > I also added these Jenkins jobs: > > > > > > > - Solr-Artifacts-9x > > > > > > > - Solr-Check-9.x > > > > > > > - Solr-reference-guide-9.x > > > > > > > - Solr-Artifacts-9.0 > > > > > > > - Solr-Check-9.0 > > > > > > > - Solr-reference-guide-9.0 > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > 9. jan. 2022 kl. 01:04 skrev Jan Høydahl <[email protected]>: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > This is indeed a deliberate deviation from established branch > > > > > > > process, as debated and decided in the "Solr 9.0.0 release in > > > > > > > February" thread > > > > > > > https://lists.apache.org/thread/pzqvmcxcjhkrj2xb31sj3pwzrn6x9vd3 > > > > > > > and repeated on this very thread, so this is far from some SNEAKY > > > > > > > attempt to trick you all :) However, the intent of minimizing > > > > > > > number of backports in a period where the project is in 9.0 > > > > > > > release focus (there will be tons of commits) seemd brilliant > > > > > > > just a week ago, but I can see that we also need a place to land > > > > > > > 9.1 features now and not wait until February. > > > > > > > > > > > > > > As several committers are in support of freeing branch_9x for > > > > > > > feature development for 9.1, I'll go ahead and create the > > > > > > > branch_9_0 branch now. > > > > > > > > > > > > > > Ishan: What warrants a release is subjective, but noone can > > > > > > > accuse the Solr project of RUSHING with the 9.0 release. Have a > > > > > > > look at the Major Changes in Solr 9 page if you need a reminder > > > > > > > of what we have been keeping from our users (and developers not > > > > > > > the least) for too long. > > > > > > > Someone will always have a "killer feature" around the corner. > > > > > > > Fine, then 9.1 will also get a nice killer feature. Or 9.2. More > > > > > > > champagne! But lack of a brand new feature is never a blocker for > > > > > > > any release. > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > 8. jan. 2022 kl. 02:45 skrev Ishan Chattopadhyaya > > > > > > > <[email protected]>: > > > > > > > > > > > > > > > branch_9x is in feature freeze! We want to stabilize > > > > > > > > > > > > > > Feature freeze is meant for the release branches. There is no > > > > > > > precedent for having a feature freeze on the stable branch. I > > > > > > > urge you to follow well established processes and not invent new > > > > > > > processes on the fly and hold the project hostage to those new > > > > > > > processes. If you have concerns about the stability of the > > > > > > > commit, we can consider reverting from the stable branch. > > > > > > > > > > > > > > On Sat, Jan 8, 2022 at 7:11 AM Ishan Chattopadhyaya > > > > > > > <[email protected]> wrote: > > > > > > >> > > > > > > >> > What do we think about a "beta" release, to give users > > > > > > >> > (including *ourselves* in many cases) more time to try out 9.0 > > > > > > >> > to report issues? > > > > > > >> +1 > > > > > > >> > > > > > > >> > It would be a shame to release Solr 9 without support for the > > > > > > >> > vector based index in Lucene 9. Thankfully there's a JIRA > > > > > > >> > issue with a PR! > > > > > > >> > https://issues.apache.org/jira/browse/SOLR-15880 . It's as > > > > > > >> > much about optics as anything. I think many users are > > > > > > >> > probably more at a curiosity / exploratory stage with this > > > > > > >> > topic but still -- Solr 9 without the ability to explore this > > > > > > >> > is disappointing, leaving them to consider other options to > > > > > > >> > scratch that itch. > > > > > > >> > > > > > > >> Fully agree with the sentiment here, David. Without the vector > > > > > > >> search feature, I see no other important enough feature in a 9.0 > > > > > > >> release to capture users' excitement. Commentators are already > > > > > > >> writing off Solr as legacy search [0], and such a milestone > > > > > > >> release should address some of the areas in which we're falling > > > > > > >> behind. > > > > > > >> > > > > > > >> If that feature is just a few weeks out, what is the need for > > > > > > >> this artificial rush to get 9.0 out now? > > > > > > >> > > > > > > >> [0] - https://twitter.com/jobergum/status/1476657317768749062 > > > > > > >> > > > > > > >> > > > > > > >> On Sat, Jan 8, 2022 at 5:15 AM Jan Høydahl > > > > > > >> <[email protected]> wrote: > > > > > > >>> > > > > > > >>> branch_9x is in feature freeze! We want to stabilize, fix bugs > > > > > > >>> and remove blockers on that branch, not add features - unless > > > > > > >>> they are agreed as a blocker for the release. > > > > > > >>> If everyone starts pushing all kinds of new features to 9x now, > > > > > > >>> it will never stabilize. > > > > > > >>> > > > > > > >>>>>>>> >>> Q: But my feature is almost ready and low-risk, I can > > > > > > >>>>>>>> >>> surely put it on branch_9x ? > > > > > > >>>>>>>> >>> A: No, only blockers and bugfixes please. You can > > > > > > >>>>>>>> >>> argue on dev@ that your feature is a blocker > > > > > > >>> > > > > > > >>> > > > > > > >>> I think it all looks a bit messy and rushed. SOLR-15694 is > > > > > > >>> open, PR is open, with no approvals from any of the reviwers? > > > > > > >>> > > > > > > >>> Please revert on branch_9x and then "argue on dev@ that your > > > > > > >>> feature is a blocker". > > > > > > >>> > > > > > > >>> Jan > > > > > > >>> > > > > > > >>> 7. jan. 2022 kl. 20:09 skrev Ishan Chattopadhyaya > > > > > > >>> <[email protected]>: > > > > > > >>> > > > > > > >>> Since a 9.0 release branch has not been cut, I backported the > > > > > > >>> SOLR-15694 to branch_9x. If there are any concerns, we can > > > > > > >>> discuss reverting it from branch_9_0 later. > > > > > > >>> Thanks and regards. > > > > > > >>> > > > > > > >>> On Fri, Jan 7, 2022 at 10:34 PM Ishan Chattopadhyaya > > > > > > >>> <[email protected]> wrote: > > > > > > >>>> > > > > > > >>>> > let it bake in main (10.0) for some time, letting more devs > > > > > > >>>> > try it out > > > > > > >>>> > > > > > > >>>> Please define "some time". Is 3 weeks until the 9.0 release > > > > > > >>>> not enough? > > > > > > >>>> > > > > > > >>>> On Fri, Jan 7, 2022 at 10:26 PM Jan Høydahl > > > > > > >>>> <[email protected]> wrote: > > > > > > >>>>> > > > > > > >>>>> I think it is premature to add it to branch_9x yet. First get > > > > > > >>>>> +1 from key stakeholders on the PR, then let it bake in main > > > > > > >>>>> (10.0) for some time, letting more devs try it out. If all > > > > > > >>>>> looks good at that point, we may consider it, especially if > > > > > > >>>>> the default behaviour is === 8.x. > > > > > > >>>>> > > > > > > >>>>> What do others think? > > > > > > >>>>> > > > > > > >>>>> Jan > > > > > > >>>>> > > > > > > >>>>> 7. jan. 2022 kl. 11:26 skrev Ishan Chattopadhyaya > > > > > > >>>>> <[email protected]>: > > > > > > >>>>> > > > > > > >>>>> > Btw - does Solr have any benchmarks published yet, that we > > > > > > >>>>> > can compare 8.11 with 9.0? Would be very useful. > > > > > > >>>>> > > > > > > >>>>> I can work on it over the weekend. I have some suites ready > > > > > > >>>>> with me, but not automated yet. > > > > > > >>>>> > > > > > > >>>>> > Today: Cut branch_9x and enter feature freeze on that branch > > > > > > >>>>> > > > > > > >>>>> I'd like to include SOLR-15694 (node roles) in 9.0, if that's > > > > > > >>>>> okay with you. It is dev complete, we're just running the > > > > > > >>>>> tests to make sure the failing tests are not due to our > > > > > > >>>>> changes (and unrelated); we can commit it over the weekend. > > > > > > >>>>> > > > > > > >>>>> On Fri, Jan 7, 2022 at 3:13 AM Jan Høydahl > > > > > > >>>>> <[email protected]> wrote: > > > > > > >>>>>> > > > > > > >>>>>> I don't think we are allowed by Apache policy to broadly > > > > > > >>>>>> announce non-official releases like nightlies. > > > > > > >>>>>> > > > > > > >>>>>> There should be more than enough in 9.0 to warrant a major > > > > > > >>>>>> release. > > > > > > >>>>>> Most users will be reluctant to jump on a X.0.0 release, so > > > > > > >>>>>> we can mature a lot in 9.0.x. > > > > > > >>>>>> > > > > > > >>>>>> Perhaps if we start authoring the Release Notes (any > > > > > > >>>>>> volunteers?), we'll see more clearly what we are about to > > > > > > >>>>>> relase. > > > > > > >>>>>> And if we can have new sexy features in 9.1 and 9.2 that > > > > > > >>>>>> even warrants blog posts and twitter bragging, even better :) > > > > > > >>>>>> > > > > > > >>>>>> Let's keep this release train rolling and force ourselves > > > > > > >>>>>> into getting this out there sooner rather than later. We're > > > > > > >>>>>> not releasing the reference-branch or anything, so I think a > > > > > > >>>>>> beta is not necessary, unless the release phase ends up in > > > > > > >>>>>> endless RCs due to tons of bugs and regressions. > > > > > > >>>>>> > > > > > > >>>>>> Btw - does Solr have any benchmarks published yet, that we > > > > > > >>>>>> can compare 8.11 with 9.0? Would be very useful. > > > > > > >>>>>> > > > > > > >>>>>> Jan > > > > > > >>>>>> > > > > > > >>>>>> 6. jan. 2022 kl. 22:24 skrev David Smiley > > > > > > >>>>>> <[email protected]>: > > > > > > >>>>>> > > > > > > >>>>>> What do we think about a "beta" release, to give users > > > > > > >>>>>> (including *ourselves* in many cases) more time to try out > > > > > > >>>>>> 9.0 to report issues? I don't think a beta release would > > > > > > >>>>>> necessitate a typical feature freeze. If we ultimately > > > > > > >>>>>> decline on a beta release, a counter-proposal would be to > > > > > > >>>>>> promote our nightly docker images everywhere (solr-users > > > > > > >>>>>> list, twitter, Slack) to solicit feedback. > > > > > > >>>>>> > > > > > > >>>>>> It would be a shame to release Solr 9 without support for > > > > > > >>>>>> the vector based index in Lucene 9. Thankfully there's a > > > > > > >>>>>> JIRA issue with a PR! > > > > > > >>>>>> https://issues.apache.org/jira/browse/SOLR-15880 . It's as > > > > > > >>>>>> much about optics as anything. I think many users are > > > > > > >>>>>> probably more at a curiosity / exploratory stage with this > > > > > > >>>>>> topic but still -- Solr 9 without the ability to explore > > > > > > >>>>>> this is disappointing, leaving them to consider other > > > > > > >>>>>> options to scratch that itch. > > > > > > >>>>>> > > > > > > >>>>>> ~ David Smiley > > > > > > >>>>>> Apache Lucene/Solr Search Developer > > > > > > >>>>>> http://www.linkedin.com/in/davidwsmiley > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> On Thu, Jan 6, 2022 at 2:11 PM Timothy Potter > > > > > > >>>>>> <[email protected]> wrote: > > > > > > >>>>>>> > > > > > > >>>>>>> thanks Jan, PR looks good now! 😀 > > > > > > >>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl > > > > > > >>>>>>> <[email protected]> wrote: > > > > > > >>>>>>>> > > > > > > >>>>>>>> False alarm, I had a dirty checkout. > > > > > > >>>>>>>> Please see if your PR passes precommit. > > > > > > >>>>>>>> > > > > > > >>>>>>>> Jan > > > > > > >>>>>>>> > > > > > > >>>>>>>> > 6. jan. 2022 kl. 19:49 skrev Jan Høydahl > > > > > > >>>>>>>> > <[email protected]>: > > > > > > >>>>>>>> > > > > > > > >>>>>>>> > Tim, I pushed a change to gradle that now uses hardcoded > > > > > > >>>>>>>> > 9.0.0 for tests.luceneMatchVersion. That's a stop-gap, > > > > > > >>>>>>>> > will make it dynamically follow the current > > > > > > >>>>>>>> > lucene-version, but somehow my gradle project picked up > > > > > > >>>>>>>> > an old version of org.apache.lucene.utils.Version > > > > > > >>>>>>>> > class... > > > > > > >>>>>>>> > > > > > > > >>>>>>>> > Now I get a new error > > > > > > >>>>>>>> > > > > > > > >>>>>>>> > * What went wrong: > > > > > > >>>>>>>> > Execution failed for task ':validateSourcePatterns'. > > > > > > >>>>>>>> >> Found 10 violations in source files (@author javadoc > > > > > > >>>>>>>> >> tag, svn keyword, tabs instead spaces). > > > > > > >>>>>>>> > > > > > > > >>>>>>>> > Jan > > > > > > >>>>>>>> > > > > > > > >>>>>>>> >> 6. jan. 2022 kl. 17:53 skrev Timothy Potter > > > > > > >>>>>>>> >> <[email protected]>: > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> Thanks for the update Jan! > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> One of my PRs (sync'd with main) is now failing > > > > > > >>>>>>>> >> precommit with: > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> 105 actionable tasks: 103 executed, 2 up-to-date > > > > > > >>>>>>>> >> 201FAILURE: Build failed with an exception. > > > > > > >>>>>>>> >> 202 > > > > > > >>>>>>>> >> 203* Where: > > > > > > >>>>>>>> >> 204Script > > > > > > >>>>>>>> >> '/home/runner/work/solr/solr/gradle/validation/solr.config-file-sanity.gradle' > > > > > > >>>>>>>> >> line: 40 > > > > > > >>>>>>>> >> 205 > > > > > > >>>>>>>> >> 206* What went wrong: > > > > > > >>>>>>>> >> 207Execution failed for task > > > > > > >>>>>>>> >> ':solr:validateConfigFileSanity'. > > > > > > >>>>>>>> >> 208> Configset does not refer to the correct > > > > > > >>>>>>>> >> luceneMatchVersion > > > > > > >>>>>>>> >> (10.0.0): > > > > > > >>>>>>>> >> /home/runner/work/solr/solr/solr/server/solr/configsets/_default/conf/solrconfig.xml > > > > > > >>>>>>>> >> 209 > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> Any ideas what's wrong there? > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> On Thu, Jan 6, 2022 at 9:40 AM Jan Høydahl > > > > > > >>>>>>>> >> <[email protected]> wrote: > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> NOTICE: > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Branch branch_9_x has been cut and versions updated to > > > > > > >>>>>>>> >>> 10.0 on 'main' branch. > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> This follows the plan from previous notice about 9.0 > > > > > > >>>>>>>> >>> release [1]. Here is what will happen: > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Today: Cut branch_9x and enter feature freeze on that > > > > > > >>>>>>>> >>> branch > > > > > > >>>>>>>> >>> Next few weeks: Remove blockers, prepare build & > > > > > > >>>>>>>> >>> release machinery > > > > > > >>>>>>>> >>> February: Cut branch_9_0 and build RC1 > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> This is how we'll use the branches until we cut the > > > > > > >>>>>>>> >>> branch_9_0 release-branch: > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> main: All new features and bug fixes (as today) > > > > > > >>>>>>>> >>> branch_9x: Only backport of bugfixes and blockers for > > > > > > >>>>>>>> >>> the 9.0 release. > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> FAQ: > > > > > > >>>>>>>> >>> ------ > > > > > > >>>>>>>> >>> Q: Where do I put a feature intended for 9.1? > > > > > > >>>>>>>> >>> A: On main branch. Then in February, bulk backport to > > > > > > >>>>>>>> >>> branch_9x > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Q: Can we go to Java17 on main branch now? > > > > > > >>>>>>>> >>> A: Not yet, let's keep main branch as-is until > > > > > > >>>>>>>> >>> branch_9_0 is cut, to easen backporting > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Q: But my feature is almost ready and low-risk, I can > > > > > > >>>>>>>> >>> surely put it on branch_9x ? > > > > > > >>>>>>>> >>> A: No, only blockers and bugfixes please. You can > > > > > > >>>>>>>> >>> argue on dev@ that your feature is a blocker > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Q: How can I help with the 9.0 release? > > > > > > >>>>>>>> >>> A: You can check out the JIRA for blockers [2] and > > > > > > >>>>>>>> >>> help fix those > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> Q: Why do we need to wait until February with cutting > > > > > > >>>>>>>> >>> the release branch? > > > > > > >>>>>>>> >>> A: We don't - if blockers are resolved and we feel > > > > > > >>>>>>>> >>> close to RC1 before then... > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> > > > > > > >>>>>>>> >>> [1] > > > > > > >>>>>>>> >>> https://lists.apache.org/thread/qv9n2b7jkmzr26ov5p50lc3h2dy7htzo > > > > > > >>>>>>>> >>> [2] > > > > > > >>>>>>>> >>> https://issues.apache.org/jira/issues/?filter=12351219 > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> >> --------------------------------------------------------------------- > > > > > > >>>>>>>> >> To unsubscribe, e-mail: [email protected] > > > > > > >>>>>>>> >> For additional commands, e-mail: > > > > > > >>>>>>>> >> [email protected] > > > > > > >>>>>>>> >> > > > > > > >>>>>>>> > > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>> --------------------------------------------------------------------- > > > > > > >>>>>>>> To unsubscribe, e-mail: [email protected] > > > > > > >>>>>>>> For additional commands, e-mail: [email protected] > > > > > > >>>>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ----------------------------------------------------- > > > > > > Noble Paul > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > >
