This is not an official proposal from the Chicago guys, but here's a
hint about what's floating in our heads right now.
On Wed, 2004-03-31 at 15:52, Justin Erenkrantz wrote:
> I'd like to have the Java bindings straightened out for a 1.1 release. A
> large portion of this work has already been done in trunk by myself and
> dlr, but we need to get more eyes and testing with it (both the javahl and
> SWIG/Java bindings). The current situation in trunk/ is far better than in
> the 1.0.x branch, so the amount of work that remains is probably not that
Mmmmm... java. Not important to me, but whatever floats your boat. :-)
> As far as i18n work, I think having a first cut at client-side translations
> is going to be feasible in a 1.1 timeframe.
Absolutely. Collabnet really wants (at a minimum) localized error
messages ASAP. Hence my enthusiasm for gettext support in 1.1. Expect
the Chicago guys to help out on this l18n stuff however we can.
> I think the server-side error
> messages are going to require serious discussion, so they may not be
> feasible for a 1.1-timeframe.
Yah, not necessarily as important. Could be 1.1, or maybe not. There's
a lot of design to work out.
> Perhaps we need to run a straw poll to see who can help
> with i18n translations? I'd see recruiting translators as the largest
> obstacle here.
That would be awesome.
> As I've mentioned before, I'd like to see us clarify and simplify our
> release practices and procedures.
Fantastic. /me throws confetti.
> I think we can also get the locking-plan.txt implemented for a 1.1. This
> is probably the 'largest' cross-cutting feature that I think we should add
> into a 1.1.
Yah. Out in Chicago, this is the "really big" feature we're hoping to
propose for 1.1.
About a week ago, cmpilato and I dusted off the very old locking
proposal that a bunch of us wrote up at ApacheCon 2002. We worked it
out on a whiteboard together, and Mike had a bunch of interesting
comments, optimizations, and tweaks to make.
That proposal has a lot of hand-waving going on, and our hope was to
present a *concrete* version of it to the list real soon. We've just
been too busy with internal stuff lately.
> For my pie-in-the-sky feature, I'd like to see full DeltaV-compliance for a
> 1.1. I don't know my time commitments yet, but this omission has been an
> annoyance to me so far - it certainly isn't critical though. I've heard
> we've got a Java-based DeltaV client floating around the office here. So,
> I might pick that up and see what happens (I know it doesn't work quite
> right against SVN); but certainly no promises for how involved I'd be.
Well, that's certaintly not going to be part of our 1.1 proposal, but
hey, it sounds fun enough for me to at least work on "after hours" with
The only other thing on our 1.1 checklist is 'make subcommands follow
copy history'. I've already started working on it, as you've seen in
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Apr 1 00:06:18 2004