Question of changes in v3-2-test and beyond

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karolin has called for the 3.20pre3 on Friday, April 25.

I've posted a list of changes in v3-2-test that have yet
to be merged at http://www.samba.org/~jerry/picks.log

Main questions I need some help with:

  * Derrell, Are the libsmbclient changes to be merged for
    release?  (post meg note: Had a chat with Volker and
    he believes you intended these to be merged).

  * Jelmer & Gunther, what about the librpc and IDL changes?

  * Guenther, what about the group policy work?  Since
    that is not feature complete (am I wrong here?), should
    we bother with continual merging?

  * Michael, Are all of you registry changes to be merged?

  * Volker, you changes are more hit and miss and not localized
    to one feature.  Should I just cherry pick everything
    with a bug number or compile fix associated?

If this is to be the code freeze for 3.2.0pre3, then Karolin
needs to be reasonable assured that the rate of merging
will significantly drop after this.  Which means that all
bug fixes may not be able to be directly cherry-picked and
could require back-porting.

Some discussion has already occurred and so will just be
a restatement here.  After today:

  * No changes to v3-2-test will be merged unless specifically
    requested.  This relieves the burden from Karolin
    having to investigate the difference between branches
    and spend time tracking people down.  It also means that
    each person carries the burden of their own code which is
    as it should be.  It also implies that you may need to
    specifically backport changes to v3-2-stable and ask
    Karolin to "pull" those changes (either through email
    or git-pull)

  * To request a change to be merged, it must meet
    the following requirements:
     1. Has an bug report on file,
     2. Fixes either a crash, compile, error regression, or
        issue that renders a feature unusable.  The last being
        more vague and up for discussion based on the amount
        of change necessary
     3. Have a fairly low risk of introducing a regression
     4. Passes "make test"

As to the topic of ongoing development, everyone seems to
agree that the 11-2008 release should be v3.3. Yes?

If so, I propose branch v3-3-test immediately and let
development continue since the trees seem to be diverging.
It seems a bit silly to me to allow new work to
be checked into v3-2-test which it will not be accepted
into the 3.2 release series.  Alternatively, we just put a
hold on any incoming feature work.  The latter is difficult
to do with a shared repo.

If we do branch, then *every* change that goes to the
existing v3-2-test has to be of release quality and intended
for an upcoming release.  This is how we treat the v3-0-test
branch today.





cheers, jerry
- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFID5hSIR7qMdg1EfYRAgFcAKCifGH8lGNSFjim7Qm0x0oqFbsyHQCdEWNi
Cw4BHb9ZoVvh6GdifoaA0Hk=
=JlXd
-----END PGP SIGNATURE-----