You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2006/07/12 17:32:30 UTC

Postage SVN notifications

Hi Noel,

As a person having SVN karma, would you mind to turn on SVN 
notifications for postage 
(http://issues.apache.org/jira/browse/POSTAGE-4) or should I file an 
INFRA-JIRA or <something else>?

Thanks!

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Postage SVN notifications

Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> A sandbox is just a branch.  Long lived, short lived, whatever.  Just a
> branch.  I would move everything from under sandbox/ to branches/ and get
> rid of the former.

A further *logical* difference between branches and sandbox is (imo) 
that a branches subfolder will always start as a copy of a trunk version 
or another branches subfolder version, while sandbox could even contain 
new code written from scratch.

In sandbox we could try to setup a multimodule repository, we could put 
the code of a new project while we decide how to name it and where to 
finally put it.

I think my explanations are finished. You didn't convince me but maybe 
the other committers are with you: I believe in the power of the vote ;-)

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Postage SVN notifications

Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> A branch is a branch is a branch.  A branch is a copy of the code that is
> expected to change.  A tag is a copy of the code that is NOT expected to
> change.  That's it. Nice and simple.  The only reason to invent new
> structures is to deal with access control, and we do not need to do that
> with for JAMES.
> 
>> I think that having sandboxes can make us moving a little faster.
> 
> A sandbox is just a branch.  Long lived, short lived, whatever.  Just a
> branch.  I would move everything from under sandbox/ to branches/ and get
> rid of the former.

Imho it is cleaner if we use both the sandbox and the branches folders.
Btw feel free to start a vote if you want to change it.

I will probably vote -0 on that: I really prefer the sandbox folder, but 
I don't think it's fair (or James need it) to start a veto on this things.

Imho it was good to keep release branches and have it separated from 
other branches.

In my ideal world many of the branches currently under branches should 
be moved to sandbox and maybe deleted if their link is considered of no 
use for the time being.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: Postage SVN notifications

Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:

> Noel J. Bergman wrote:
>>> As a person having SVN karma, would you mind to turn on SVN
>>> notifications for postage
>>
>> For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless
>> you know how, and have authorization, to change the mailer configuration.

> Who, between James committers, have authorization to change this?

> For the next time I will ask even for the notification mail but I'd
> like to know what is the procedure for that and who to ask when you
> don't find the time to do that.

Serge and myself, and no one else I suspect.  Which is why no one else
should create content directly under james/, and if we do, we've got to
remember to update the mailer accordingly.  The ASF takes commit notices
seriously.  Something should have been said immediately when the notices
were not flowing, and commits should have been stopped until it was fixed.

> > As an aside, since we're talking about SVN and I'm in a snarky mood, we
> > should get rid of this sandbox nonsense.  Let's stick with the standard
> > tags, branches, trunk.  What's a sandbox?  A branch for playing in.
Fine.
> > Put it under branches.

> If you remember we voted for that so I don't think we should remove the
> sandbox.

I don't have a problem with a "sandbox", and was the one who said that we
could use a branch for such things as the M2 experiment, or other
experiements.  I only have an issue with how the "sandbox" is reflected in
svn.

> When I voted I thought at this differences between the branches and
> sandbox folder:
> - branches is for "official", long running, persistent product versions

A branch is a branch is a branch.  A branch is a copy of the code that is
expected to change.  A tag is a copy of the code that is NOT expected to
change.  That's it. Nice and simple.  The only reason to invent new
structures is to deal with access control, and we do not need to do that
with for JAMES.

> I think that having sandboxes can make us moving a little faster.

A sandbox is just a branch.  Long lived, short lived, whatever.  Just a
branch.  I would move everything from under sandbox/ to branches/ and get
rid of the former.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Postage SVN notifications

Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> As a person having SVN karma, would you mind to turn on SVN
>> notifications for postage
> 
> Yes.  And, honestly, I'm annoyed.  The mailer must be configured BEFORE the
> commits are made, not after.  As far as I know, we now need a list of every
> revision number for all of the commits to postage so that we can re-run the
> mailer to generate the notices.  But I realize that this wasn't intentional.
> No one meant to do anything wrong, they just don't know what they are doing
> in terms of how SVN is configured.
> 
> For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless
> you know how, and have authorization, to change the mailer configuration.

Who, between James committers, have authorization to change this?
- We voted for POSTAGE to be created on 2006/05/26
- the vote contained the JIRA and SVN references
- There is even a JIRA issue to remember to prepare the commit 
notifications and the JIRA project.

I waited almost a month and one week ago there was no JIRA issue: I 
asked Serge to do that and we finally have it.

For the next time I will ask even for the notification mail but I'd like 
to know what is the procedure for that and who to ask when you don't 
find the time to do that.

> As an aside, since we're talking about SVN and I'm in a snarky mood, we
> should get rid of this sandbox nonsense.  Let's stick with the standard
> tags, branches, trunk.  What's a sandbox?  A branch for playing in.  Fine.
> Put it under branches.
> 
> 	--- Noel

If you remember we voted for that so I don't think we should remove the 
sandbox.
If you have a different Idea you should have replied to the vote. If you 
missed it start an opposite vote ;-)

When I voted I thought at this differences between the branches and 
sandbox folder:
- branches is for "official", long running, persistent product versions
- sandbox is less formal and a place where branches are created and 
removed without the fear to create confusion in the branches folder.

I could reply to you: "what's a tag? A branch that is no changed" but 
even if at repository level there is no difference in the real life 
there is a clear and logical separation between the 2.

Btw, I think we can bring our ideas and our preferences but we should 
simply use the easy tool (the vote).

I'm still convinced that it is good to have a sandbox in the main james 
folder and the sandbox of the james/server folder because I saw that 
James PMCs with karma have not so much time to follow the project 
reactively and I think that having sandboxes can make us moving a little 
faster.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Postage SVN notifications

Posted by Bernd Fondermann <bf...@brainlounge.de>.
Noel J. Bergman wrote:
>>As a person having SVN karma, would you mind to turn on SVN
>>notifications for postage
> 
> 
> Yes.  And, honestly, I'm annoyed.  The mailer must be configured BEFORE the
> commits are made, not after.  As far as I know, we now need a list of every
> revision number for all of the commits to postage so that we can re-run the
> mailer to generate the notices.  But I realize that this wasn't intentional.
> No one meant to do anything wrong, they just don't know what they are doing
> in terms of how SVN is configured.

This went wrong, I am sorry for not speaking up sooner. (Or asking more 
politely.)

What can I do to drive this topic, so we can get over this?

We have JIRA POSTAGE-4 to track progress.

The revisions in question are:

414144 (initial directory creation)

415259, 415275, 415277 (initial import)

415580, 415588, 417957, 420489, 421286 (development)

> 
> For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless
> you know how, and have authorization, to change the mailer configuration.
> 
> As an aside, since we're talking about SVN and I'm in a snarky mood, we
> should get rid of this sandbox nonsense.  Let's stick with the standard
> tags, branches, trunk.  What's a sandbox?  A branch for playing in.  Fine.
> Put it under branches.

It's slightly off topic, but anyway:
+1, sandbox should live under branches/

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: Postage SVN notifications

Posted by "Noel J. Bergman" <no...@devtech.com>.
Norman Maurer wrote:

> I also like the sandbox. For example for the fastfail stuff the sandbox
> is cool. Cause after commit to trunk i whould simply remove it.

And how would any of what you just said be different if the directories
under sandbox/ were moved to being under branches/?  Exactly.  There would
be no difference.

All that I am saying is that we don't need the sandbox/ directory.  It
serves no purpose.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: Postage SVN notifications

Posted by Norman Maurer <nm...@byteaction.de>.
Am Mittwoch, den 12.07.2006, 20:45 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> >> As a person having SVN karma, would you mind to turn on SVN
> >> notifications for postage
> > 
> > Yes.  And, honestly, I'm annoyed.  The mailer must be configured BEFORE the
> > commits are made, not after.  As far as I know, we now need a list of every
> > revision number for all of the commits to postage so that we can re-run the
> > mailer to generate the notices.  But I realize that this wasn't intentional.
> > No one meant to do anything wrong, they just don't know what they are doing
> > in terms of how SVN is configured.
> > 
> > For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless
> > you know how, and have authorization, to change the mailer configuration.
> 
> Who, between James committers, have authorization to change this?
> - We voted for POSTAGE to be created on 2006/05/26
> - the vote contained the JIRA and SVN references
> - There is even a JIRA issue to remember to prepare the commit 
> notifications and the JIRA project.
> 
> I waited almost a month and one week ago there was no JIRA issue: I 
> asked Serge to do that and we finally have it.
> 
> For the next time I will ask even for the notification mail but I'd like 
> to know what is the procedure for that and who to ask when you don't 
> find the time to do that.
> 
> > As an aside, since we're talking about SVN and I'm in a snarky mood, we
> > should get rid of this sandbox nonsense.  Let's stick with the standard
> > tags, branches, trunk.  What's a sandbox?  A branch for playing in.  Fine.
> > Put it under branches.
> > 
> > 	--- Noel
> 
> If you remember we voted for that so I don't think we should remove the 
> sandbox.
> If you have a different Idea you should have replied to the vote. If you 
> missed it start an opposite vote ;-)
> 
> When I voted I thought at this differences between the branches and 
> sandbox folder:
> - branches is for "official", long running, persistent product versions
> - sandbox is less formal and a place where branches are created and 
> removed without the fear to create confusion in the branches folder.
> 
> I could reply to you: "what's a tag? A branch that is no changed" but 
> even if at repository level there is no difference in the real life 
> there is a clear and logical separation between the 2.
> 
> Btw, I think we can bring our ideas and our preferences but we should 
> simply use the easy tool (the vote).
> 
> I'm still convinced that it is good to have a sandbox in the main james 
> folder and the sandbox of the james/server folder because I saw that 
> James PMCs with karma have not so much time to follow the project 
> reactively and I think that having sandboxes can make us moving a little 
> faster.
> 
> Stefano
> 

I also like the sandbox. For example for the fastfail stuff the sandbox
is cool. Cause after commit to trunk i whould simply remove it.. 

Why we not simply write such thinks down to the wiki so anyone know if
its ok or not.. sometimes i feelin really "unclear" about many things in
james ;.(

bye
Norman


RE: Postage SVN notifications

Posted by "Noel J. Bergman" <no...@devtech.com>.
> As a person having SVN karma, would you mind to turn on SVN
> notifications for postage

Yes.  And, honestly, I'm annoyed.  The mailer must be configured BEFORE the
commits are made, not after.  As far as I know, we now need a list of every
revision number for all of the commits to postage so that we can re-run the
mailer to generate the notices.  But I realize that this wasn't intentional.
No one meant to do anything wrong, they just don't know what they are doing
in terms of how SVN is configured.

For future reference, DO NOT CREATE ANYTHING DIRECTLY UNDER james/ unless
you know how, and have authorization, to change the mailer configuration.

As an aside, since we're talking about SVN and I'm in a snarky mood, we
should get rid of this sandbox nonsense.  Let's stick with the standard
tags, branches, trunk.  What's a sandbox?  A branch for playing in.  Fine.
Put it under branches.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org