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

Jeremy Allison wrote:
> On Fri, May 23, 2008 at 01:17:21PM -0500, coffeedude@samba.org wrote:
>> The branch, v3-0-test has been updated
>> via cf9ef3a45b2cdd150ec77a811e3d4927c3bfbc85 (commit)
>> via 8dc4e979776aae0ecaa74b51dc1eac78a7631405 (commit)
>> via fd0ae47046d37ec8297396a2733209c4d999ea91 (commit)
>> from a7ad5189670d6497c958edc1a85e41ecb50df837 (commit)
>>
>> http://gitweb.samba.org/?p=samba.git...og;h=v3-0-test
>>
>>
>> - Log -----------------------------------------------------------------
>> commit cf9ef3a45b2cdd150ec77a811e3d4927c3bfbc85
>> Author: Gerald Carter
>> Date: Fri May 23 13:15:02 2008 -0500
>>
>> Set version in v3-0-test to 3.0.30-GIT
>>
>> commit 8dc4e979776aae0ecaa74b51dc1eac78a7631405
>> Author: Steven Danneman
>> Date: Wed May 7 13:34:26 2008 -0700
>>
>> spnego SPN fix when contacting trusted domains
>
> Are you going to port this to 3.2 / 3.3 or shall I do it ?

I'm working on it. You know me better than that.
Everything has changed so Can't really cherry pick.


jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINx/DIR7qMdg1EfYRAk2UAJ41tTYoj2oeZ45sN7ae8y7BaHh/VQCgrxJt
GUa+d3N/+f7uSO55ER+ELn4=
=AruQ
-----END PGP SIGNATURE-----

On Fri, May 23, 2008 at 02:49:23PM -0500, Gerald (Jerry) Carter wrote:

> I'm working on it. You know me better than that.

Yeah I do know you better. I just hate waiting :-).

> Everything has changed so Can't really cherry pick.

Ok, thanks !

Jeremy.

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

Jeremy Allison wrote:
> On Fri, May 23, 2008 at 02:49:23PM -0500, Gerald (Jerry) Carter wrote:
>
>> I'm working on it. You know me better than that.
>
> Yeah I do know you better. I just hate waiting :-).
>
>> Everything has changed so Can't really cherry pick.
>
> Ok, thanks !

Done.


btw....Karolin, can we now assume that *everything* in v3-2-test
will be merged for release and not go through the step of asking
you to pull into -stable? That it will just happen?



jerry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINzOWIR7qMdg1EfYRAsdDAKDDapSOS5w7ypcy/qn/NqCCWrlS3QCfQ2J0
wMHb/h59XCyVFyZ45Dkv1xk=
=Mb/S
-----END PGP SIGNATURE-----

Jerry,

On Fri, May 23, 2008 at 04:13:58PM -0500, Gerald (Jerry) Carter wrote:
> btw....Karolin, can we now assume that *everything* in v3-2-test
> will be merged for release and not go through the step of asking
> you to pull into -stable? That it will just happen?

No, I would prefer to stick to the notification.
My plan was to use v3-2-test as upcoming 3.2.1 and to pull only bug fixes
to v3-2-stable (after proper notification).

Are there any arguments against this strategy?

Karolin

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIOnEfKGi9fisXk1ERAqrRAKCMPHXpDdiraRpnSsXsqU A3nLUpIQCfU2fi
11ipAjvqG6MUGa5bz9wLUF8=
=ZsTN
-----END PGP SIGNATURE-----

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

Karolin Seeger wrote:
| Jerry,
|
| On Fri, May 23, 2008 at 04:13:58PM -0500, Gerald (Jerry) Carter wrote:
|> btw....Karolin, can we now assume that *everything* in v3-2-test
|> will be merged for release and not go through the step of asking
|> you to pull into -stable? That it will just happen?
|
| No, I would prefer to stick to the notification.
| My plan was to use v3-2-test as upcoming 3.2.1 and to pull only bug fixes
| to v3-2-stable (after proper notification).
|
| Are there any arguments against this strategy?

It's you're call.





cheers, jerry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIOspjIR7qMdg1EfYRApKrAKCcc/MKkAuufJKyy9aQaPt12c34PQCg8c5z
UPJSbMnv4zXB+8GSLovesFI=
=C37F
-----END PGP SIGNATURE-----

On Mon, May 26, 2008 at 10:13:19AM +0200, Karolin Seeger wrote:
> Jerry,
>
> On Fri, May 23, 2008 at 04:13:58PM -0500, Gerald (Jerry) Carter wrote:
> > btw....Karolin, can we now assume that *everything* in v3-2-test
> > will be merged for release and not go through the step of asking
> > you to pull into -stable? That it will just happen?
>
> No, I would prefer to stick to the notification.
> My plan was to use v3-2-test as upcoming 3.2.1 and to pull only bug fixes
> to v3-2-stable (after proper notification).
>
> Are there any arguments against this strategy?

Yeah :-). Most new development goes into 3.3,
that branch has nicely separated out the new
features problem.

The fixes that go into 3.2-test people assume
will be in the next 3.2 release.

My vote would be to automatically pull 3.2-test
into release without explicit notification.
No one should be doing new feature/experimental
work in that branch anyway, just bugfixes.

Having the explicit notification step just
allows people to forget.

Jeremy.

Jeremy,

On Mon, May 26, 2008 at 10:03:04AM -0700, Jeremy Allison wrote:
> Yeah :-). Most new development goes into 3.3,
> that branch has nicely separated out the new
> features problem.
>
> The fixes that go into 3.2-test people assume
> will be in the next 3.2 release.
>
> My vote would be to automatically pull 3.2-test
> into release without explicit notification.
> No one should be doing new feature/experimental
> work in that branch anyway, just bugfixes.
>
> Having the explicit notification step just
> allows people to forget.

Ok, that is a possible solution, too.

From my point of view, it would be very nice to have double checks of all
patches which might go into v3-2-stable now. The main advantage of the
notification is that developers can argue why this one should go into the
final release (and I want arguments now! ;-). But of course it is possible
to ask them before pulling the patches, too.

But there is another point:
I would have the chance to put patches which should be included in
3.2.1, but not in 3.2.0 in v3-2-test. Testing would be much easier then...

To clarify:
v3-2-stable: 3.2.0rcX, final 3.2.0
v3-2-test: upcoming 3.2.1
v3-3-test: 3.3.0

Do you agree?

Karolin

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIO6rOKGi9fisXk1ERAgiQAJ9mrKCEKzJdxk6j/u13jpXmygDCTwCgoEXy
8dwt/TynpV2AaAiWd61PQ9s=
=w1QV
-----END PGP SIGNATURE-----

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

Karolin,

| But there is another point:
| I would have the chance to put patches which should be included in
| 3.2.1, but not in 3.2.0 in v3-2-test. Testing would be much easier then...
|
| To clarify:
| v3-2-stable: 3.2.0rcX, final 3.2.0
| v3-2-test: upcoming 3.2.1

My only response is that if it is a bug fix credible
for 3.2.1, why not include it in 3.2.0? I know that
any change involves risk, but these should be low risk
or obvious bug fixes anyways. Anything that is risky or
questionable should be discussed and reviewed prior to
being checked in. That is my philosophy at least.

You can always "freeze" the v3-2-test tree a few days prior
to release for escrow. Just announce that no more
fixes will be pulled into v3-2-stable at that point.
But developers should be confident that every thing in
v3-2-test has been merged to -stable.




cheers, jerry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPAF0IR7qMdg1EfYRAm4SAKC14WWy2keCTVOuugWqtF H+JPFI6QCeLTHH
R5F+qbfXuEYpQAa4xz7UAaM=
=wFhM
-----END PGP SIGNATURE-----

On Tue, May 27, 2008 at 07:41:24AM -0500, Gerald (Jerry) Carter wrote:
> My only response is that if it is a bug fix credible
> for 3.2.1, why not include it in 3.2.0? I know that
> any change involves risk, but these should be low risk
> or obvious bug fixes anyways. Anything that is risky or
> questionable should be discussed and reviewed prior to
> being checked in. That is my philosophy at least.

That's true for bug fixes, but there might be fixes for build warnings,
new parameters and things like that which should be included in 3.2.1, but
not in 3.2.0.

I would like to pick up as little patches as possible after the first
release candidate.

> You can always "freeze" the v3-2-test tree a few days prior
> to release for escrow. Just announce that no more
> fixes will be pulled into v3-2-stable at that point.
> But developers should be confident that every thing in
> v3-2-test has been merged to -stable.

I already noticed how well freezing works! ;-)

Let me give an example:
Jeremy's (sorry, Jeremy ;-) 79bda4467f3:
The commit message: Re-enable the evil "aio write behind" parameter.

I would not like to pick that one up automatically, because I don't
understand why I should re-enable an evil parameter. That's why I asked
Jeremy why this should be in v3-2-stable. What I mean is, the effort for
the developers is the same as saying: Karolin, pick that one up, because...

I would feel a little bit more comfortable with this procedure until 3.2.0 is
out.

Karolin

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIPA/tKGi9fisXk1ERAvG9AKCAvvcviXEBatSgNjdWqVbfh1sHuACgy Zhg
4+d7VQSn39on1ixymu5ytFE=
=gUio
-----END PGP SIGNATURE-----

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

Karolin Seeger wrote:
| On Tue, May 27, 2008 at 07:41:24AM -0500, Gerald (Jerry) Carter wrote:
|> My only response is that if it is a bug fix credible
|> for 3.2.1, why not include it in 3.2.0? I know that
|> any change involves risk, but these should be low risk
|> or obvious bug fixes anyways. Anything that is risky or
|> questionable should be discussed and reviewed prior to
|> being checked in. That is my philosophy at least.
|
| That's true for bug fixes, but there might be fixes
| for build warnings, new parameters and things like
| that which should be included in 3.2.1, but not in 3.2.0.
|
| I would like to pick up as little patches as possible
| after the first release candidate.

Like I said before., it's your call.

|> You can always "freeze" the v3-2-test tree a few days prior
|> to release for escrow. Just announce that no more
|> fixes will be pulled into v3-2-stable at that point.
|> But developers should be confident that every thing in
|> v3-2-test has been merged to -stable.
|
| I already noticed how well freezing works! ;-)

You misunderstand. You tried to freeze v3-2-test. You can
freeze v3-2-stable because no one can check into that except
release managers.


| Let me give an example:
| Jeremy's (sorry, Jeremy ;-) 79bda4467f3:
| The commit message: Re-enable the evil "aio write
| behind" parameter.
|
| I would not like to pick that one up automatically, because
| I don't understand why I should re-enable an evil parameter.

That's why the RM has to trust developers to do the right
thing and why developers have to act responsibly. If the release
is brown bagged because a developer screwed up, it's their fault.
Not yours. This is your game so you have to run it however
you feel most comfortable. I'm only offering advice. The
end decision is yours and everyone will back you up on it.






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.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPBaHIR7qMdg1EfYRAsEzAJwJZjhNoseDE4llq42lT2 XF0QUwOgCgzCLj
HJGrSnXP5PBX5EOdsjeyWTM=
=6Jtk
-----END PGP SIGNATURE-----

On Tue, May 27, 2008 at 09:11:19AM -0500, Gerald (Jerry) Carter wrote:
> |> You can always "freeze" the v3-2-test tree a few days prior
> |> to release for escrow. Just announce that no more
> |> fixes will be pulled into v3-2-stable at that point.
> |> But developers should be confident that every thing in
> |> v3-2-test has been merged to -stable.
> |
> | I already noticed how well freezing works! ;-)
>
> You misunderstand. You tried to freeze v3-2-test. You can
> freeze v3-2-stable because no one can check into that except
> release managers.

Ok, then the two of you are talking about different things :-)

As far as I understood Karolin this discussion is about the
process how things go from 3-2-test to 3-2-stable.

One assumption is that everything a developer put into
3-2-test went into 3-2-stable automatically without explicit
notice. This would mean 3-2-test is frozen for anything
beyond strict bugfixing.

The other assumption would be that 3-2-test is open for
3-2-1 development already now. This means that pulling stuff
into -stable needs an explicit notice.

Or did I get anything wrong?

Volker

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFIPBnVUzqjrWwMRl0RArv4AJ4lLJMWtD/eVosnznKqAvmTE8JlCQCdEN4G
/eVR53WUIWOV8/RjEU9Ze6Q=
=xjE0
-----END PGP SIGNATURE-----

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

Volker Lendecke wrote:

>>
>> You misunderstand. You tried to freeze v3-2-test. You can
>> freeze v3-2-stable because no one can check into that except
>> release managers.
>
> Ok, then the two of you are talking about different
> things :-)

No. We're not actually. We are talking about the same thing.

> As far as I understood Karolin this discussion is about the
> process how things go from 3-2-test to 3-2-stable.

yup.

> One assumption is that everything a developer put into
> 3-2-test went into 3-2-stable automatically without explicit
> notice. This would mean 3-2-test is frozen for anything
> beyond strict bugfixing.

yup again.

> The other assumption would be that 3-2-test is open for
> 3-2-1 development already now. This means that pulling stuff
> into -stable needs an explicit notice.

There is no 3-2-1 development I think. We only have biug fixes
in v3-2-test from here on out right? Or possibly features backports
I guess if everyone agrees first.

I think the discussion has run its course. Karolin is RM and whatever
she's decides to do is fine with me.



cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPB4sIR7qMdg1EfYRAvOQAKC4pqCPuKAFGJ7oV4Lf98/oDGb6vQCdEf89
ZFr+WIRxFg0avm3TuUMlzW8=
=cDNb
-----END PGP SIGNATURE-----

Volker Lendecke wrote:
> The other assumption would be that 3-2-test is open for
> 3-2-1 development already now. This means that pulling stuff
> into -stable needs an explicit notice.

Well, I thought that tere was no such thing as "3-2-1 development".
To my understanding, everything to go into 3.2.X after 3.2.0rc1
has to be strict bugfixing.

Apart from that, I can understand Karolin being more comfortable
with explicitly letting patches through. The alternative of
freezing 3-2-test temporarily could be tried in a next release.
But in that case, no-one can add patches to the release but

On the other hand, with 3-2-test open for anyone, this can be
understood as the platform for developers to publicly prepare
their patches for the release.

Well, as you said, Jerry, it is up to Karolin to decide.
She'll see what works best over the next couple of releases!

:-)

Cheers - Michael

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: comment

iD8DBQFIPDIdyU9JOBhPkDQRAv1VAJ46mgHWsh1vlrpiI6tcak tlG7eZFgCdHAfd
NfC1YhrP22X+Y5HkJ4meI3U=
=PK9U
-----END PGP SIGNATURE-----

On Tue, May 27, 2008 at 08:31:42AM +0200, Karolin Seeger wrote:
> But there is another point:
> I would have the chance to put patches which should be included in
> 3.2.1, but not in 3.2.0 in v3-2-test. Testing would be much easier then...
>
> To clarify:
> v3-2-stable: 3.2.0rcX, final 3.2.0
> v3-2-test: upcoming 3.2.1
> v3-3-test: 3.3.0
>
> Do you agree?

Ok, works for me - thanks !

Jeremy.