On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
Hi Alan,
On Jul 25, 2008, at 3:31 PM, Alan D. Cabrera wrote:
Some things to consider in this discussion:
- The 0.9.0 release cannot be performed off of the copy in ASF
- The 0.9.0 or earlier releases cannot be supported off of the copy
in ASF
Maybe that's what everyone is thinking. I just want to make sure
that it's clear.
I don't agree with either of the above opinions. We don't restrict
what people do with Apache code.
I don't see anything wrong with publishing a release off the
artifacts stored in Apache. It cannot be called "an Apache
incubating release" but it can certainly be called JSecurity 0.9
whatever.
Follow-on releases can similarly be built from code checked into the
Apache repository. They just cannot be called "Apache anything". And
if they're published in the jsecurity.org download area they can be
maintained in the Apache repository.
I'm not so sure about this. Is there a precedent for this?
At some point, the community will have re-packaged stuff into the
org.apache.jsecurity name space and built a release from the
jsecurity trunk. At that time, they can build an apache incubating
jsecurity release and try to get it out "the Apache Way".
The incubator is concerned about the Apache brand. Not with pulling
stuff out and calling it jsecurity.org.
I'm copying general at incubator because this discussion needs some
more eyes.
Thanks. I am very interested in what others have to say about this.
Regards,
Alan
Craig
On Jul 25, 2008, at 1:07 PM, Les Hazlewood wrote:
I'd like to keep all history, so we don't lose anything along the
way. You
never know when you might need to go look back at something for
comparison.
Plus since SVN atomically increments version numbers across trunk,
branches
and tags collectively, I don't think you can select just one or
the other
and still retain all revisions.
Yeah, I'm all for importing it with the full history as it's
currently organized at SourceForge. I just think that we shouldn't
keep anything other than trunk *after* the import for the above
reasons. If someone really wants that stuff then could dig it up
since it's in SVN.
There's a convention here at ASF that anything lying around in SVN
should be supported.
I personally don't think its a big deal just to have a 1:1 move
and keep
everything the way it is - just my opinion. After 0.9.0 final is
released
and we make the switch to org.apache.jsecurity.*, I think it would
be
self-evident that if you saw something that didn't match that
package
structure, that it is code that came in before the import. And
you would
only see that distinction in tags and branches. I just don't
think that
many people would notice that, and if they did, they'd probably be a
developer of the project who was specifically looking for an old
branch to
begin with.
Yeah, but given the above points we really can't have that stuff
lying around, imo.
But this may all be a moot point. The 'svnsync' command (outlined
in the
jira issue), requires the very first operation to be revision 0.
The import
must start on revision 1. If we were to create an import
directory in the
repository, that modification would bump up the revision to 1, and
the
actual code import wouldn't be able to start on revision 1. I
don't think
SVN sync allows this - it is a tool for an exact copy only as far
as I know.
Well then I know that this will be impossible then because I know
that ASF, in its infinite wisdumb, put all projects in a single
Subversion database. So it will be impossible for the very first
operation on our project to be revision 0.
Regards,
Alan
On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera <[EMAIL PROTECTED]
>wrote:
Ahh, ok. My idea was to drop the imported branches and tags and
just keep
trunk. We would tag it as "import". Then re-org everything
inside trunk
with the goal of making a 1.0 release that would be acceptable to
the
Incubator.
I guess I just assumed that the history in trunk would be good
enough. If
someone wanted to look at the old branches and tags it would be
simple
enough to get copies of them using the svn update command.
Just a tought.
Regards,
Alan
On Jul 25, 2008, at 12:32 PM, Craig L Russell wrote:
All the code being imported has the org.jsecurity package name,
including
the trunk, tags, and branches, I think it would be less
confusing to put
trunk, tags, and branches under a new top level directory called
import.
The new top level trunk, tags, and branches would then be where
we migrate
the imports/trunk to while changing package names (and licenses as
required).
It's not clear to me that we should have
incubator/jsecurity/tags/0.90-beta2 in the Apache repo. I'd much
prefer to
see incubator/jsecurity/import/tags/0.90-beta2.
My thoughts on this process are (obviously) evolving. I just
want to make
it clear to anyone browsing the Apache repository that there is
legacy code
being imported and there is code that will become the Apache
distribution.
Just throwing out ideas to make it less opaque.
Craig
On Jul 25, 2008, at 12:09 PM, Les Hazlewood wrote:
Actually I don't think that is possible - the existing repo
already has
'trunk', 'branches' and 'tags' that need to be preserved in the
same
location.
To achieve what you're talking about, I was hoping we could
just create
an
'import' branch immediately after the migration and then start
using the
trunk after that point as desired.
Would that be acceptable?
On Fri, Jul 25, 2008 at 2:49 PM, Craig L Russell <[EMAIL PROTECTED]
wrote:
Is it too late to suggest that the top level directory for the
imported
code be "import" and not "trunk"? Using the import directory
would allow
development to continue (in import) and put all of the future
Apache
deliverables into trunk.
Craig
On Jul 25, 2008, at 8:43 AM, Les Hazlewood wrote:
Ok, I'll let the infrastructure folks know they can blast away
the
existing
one when performing the load.
Thanks,
Les
On Fri, Jul 25, 2008 at 11:04 AM, Alan D. Cabrera <
[EMAIL PROTECTED]
wrote:
Crickey, you may be right. It's simple enough to recreate
those few
files.
Regards,
ALan
On Jul 25, 2008, at 7:58 AM, Les Hazlewood wrote:
I want to do it today or tomorrow. Sunday at the latest for
sure.
Just out of curiosity - I see the new SVN is being used.
Won't that
cause
a
conflict for an svnadmin load of the migrated repo? I
mean, I've
never
done
an svnadmin load on anything other than a fresh repository
- anyone
know
if
this is possible?
On Fri, Jul 25, 2008 at 10:49 AM, Alan D. Cabrera <
[EMAIL PROTECTED]
wrote:
Les, have you been able to make your SVN dump yet? When
can we
expect
this?
Regards,
Alan
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
