This file tracks the status of changes proposed for inclusion in 1.0.
Each candidate consists of a short identifying block (e.g., a revision
number, maybe an issue number), a brief description of the change, an
at-most-one-line justification of why it should be in 1.0, perhaps
some notes/concerns, and finally the votes.  The notes and concerns
are meant to be brief summaries to help a reader get oriented; please
don't use the STATUS file for actual discussion, use the dev@ list or
irc instead.

Here's an example, probably as complex as an entry would ever get:

   * r98765 (issue #56789)
     Make commit editor take a closure object for future mindreading.
     Justification: API stability, as prep for future enhancement.
     Notes: There was consensus on the desirability of this feature in
       the near future; see thread at http://... (Message-Id:
       blahblahblah).
     Concerns: Vetoed by jerenkrantz due to privacy concerns with the
       implementation; see thread at http://... (Message-Id: blahblahblah)
     Votes:
       +1: ghudson, bliss
       +0: cmpilato
       -0: gstein
       -1: jerenkrantz

A change needs three +1 votes from full committers (or partial committers
with access to the involved paths), and no vetoes, to go into the release.

If you cast a veto (i.e. -1), please state the reason in the concerns
field, and include a url / message-id for the list discussion if any.
You can go back and add the link later if the thread isn't available
at the time you commit the veto.

Voting +1 on a change doesn't just mean you approve of it in principle.
It means you have thoroughly reviewed the change, and find it correct
and as nondisruptive as possible.  When it is committed to the release
branch, the log message will include the names of all who voted for
it, as well as the original author and the person making the commit.
All of these people are considered equally answerable for bugs.

If you've reviewed a patch, and like it but have some reservations,
you can write "+1 (concept)" and then ask questions on the list about
your concerns.  You can write "+0" if you like the general idea but
haven't reviewed the patch carefully.  Neither of these votes counts
toward the total, but they can be useful for tracking down people who
are following the change and might be willing to spend more time on
it.

-*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*-

Core changes that don't have three +1's yet, or have a veto.  (If you
make the threshold vote on one of these items, please move it to the
section for approved changes.)

   * Issue #408
     Date parser rewrite.
     Justification: API change; avoid permanent support for bizarre and
     unpredictable date formats.
     Votes:
      +1: ghudson, epg, mbk
     Outdated votes (veto still applies until withdrawn, of course):
      +1: mbk, ghudson, dionisos, epg, striker
      +0: cmpilato
      -1: gstein. see:
           http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=53839
           Message-ID: <20040107033850.A9399@lyra.org>


   * Issue #1682
     'svn blame' should adjust to max username width
     Justification: Improved blame display, API change, low risk.
     Notes: bindings would need updating
     Votes:
      +1: mbk
      -0: gstein
      -1: kfogel. see:
           http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=54039
           Message-Id:  <200401082033.i08KXMv45357@newton.ch.collab.net>


Core changes that already have three +1 votes and no vetos.  (If you
veto something below, or remove a threshold vote, please move it to
the section for unapproved changes.)

   [none pending right now]

-*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*-

These changes are to Subversion bindings.  Many are dependent on
specific "core" changes in the previous section, so we're planning to
finalize this list (and its votes) after we know the core changes,
that is, after Thursday, Jan. 8th 2004.

Bindings changes that affect the build system:

   [none pending right now]

Bindings changes that don't affect the build system:
Already have three +1 votes:

   [none pending right now]

Don't yet have three +1 votes:


   * r8057 (depends on core changes r8053, r8054)
     Constructor for svn_client_ctx_t used in javahl bindings.
     Justification: Implementation of above API change in javahl bindings.
     Notes: this obviously assumes svn_client_ctx_t gets imp'd (see above)
     Votes:
      +1: ghudson, rooneg
      +1 (concept): gstein


   * r8031  ('svn revert' performance fix, API change)
     Implementing API change of r8021 in javahl bindings.
     Justification: with 8021 and without 8031 javahl breaks. Local change.
     Votes:
      +1: ghudson
      +1 (concept): gstein (assuming base change imp'd)


   * r8012 (add retry-count to SSL auth providers)
     Implementing API change of r8006 in javahl bindings.
     Justification: with 8006 and without 8012 javahl breaks. Local change.
     Votes:
      +1: ghudson
      +1 (concept): gstein (assuming base change imp'd)


   * r8015,r8020  (add 'may_save' option to auth providers, for GUIs)
     Implementing API change of r8013 in javahl bindings.
     Justification: with 8013 and without 8015,8020 javahl breaks. Local change
     Votes:
      +1 (concept): gstein (assuming base change is imp'd)


   * r8022, r8024, r8038
     Improved interface for blame in javahl bindings.
     Justification: API stability; low risk because of bindings only change.
     Votes:
      +0: gstein


   * r8039
     javahl bindings did not know status external.
     Justification: API stability; low risk because of bindings only change.
     Votes:
      +0: gstein

   * r8270
     Perl bindings fixes and enhancements.
     Justification: More changes to try and get the bindings in
                1.0 state.  In particular this implements most
                of the client library support.
     Votes:
      +1: breser, clkao