Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Gerald (Jerry) Carter wrote:
> Karolin has called for the 3.20pre3 on Friday, April 25.

She had also announced the code freeze for April 22.
So it seems slightly untimely to me to raise these
questions just now... :-)

> 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

Basically, I was done filing my commits for picking.

But I am *really* curioues how you produced that list.
With Metze's git cherry-script? Somehow git cherry seems=20
There are 28 patches by me listed. But only 12 of these
have not yet been merged!

Of these, 5 are the last vfs api change (removing the redundant
fd parameter from close_fn) just committed a couple of days
ago. I would of course *like* to see that in 3.2.0 to have the
API cleanup complete. (But I did not propose for picking becuse
I was too late.)

The other commits are more random, a couple of compiler warning
fixes and comment additions. I am not emotional about these.

Maybe the winbindd validation UA keylength path of Holger
Hetterich (fcd35232e111f9b046ae35d939d08c29d0d43438) and my
subsequent cleanup commit (e489f3d988feafe35b486b31a9e60c2399e6a6e7)
would make sense to be picked.

> Main questions I need some help with:
> * Michael, Are all of you registry changes to be merged?

This is done, thanks.

Cheers - Michael

> 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.

Michael Adam
SerNet GmbH, Bahnhofsallee 1b, 37081 G=F6ttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG G=F6ttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: comment