You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2008/07/25 16:49:42 UTC
SVN move
Les, have you been able to make your SVN dump yet? When can we expect
this?
Regards,
Alan
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Les,
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.
+1
>
> 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.
+1
>
>
> 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.
This is where I'd like to see the imported code go into a separate
import directory.
> And you would
> only see that distinction in tags and branches.
Well, if you have tags/0.9.0 that has the org.jsecurity package name
and tags/0.9.1 that has the org.apache.jsecurity package name; and the
org.jsecurity wasn't an Apache release, and the org.apache.jsecurity
was an Apache release, that's where I see an issue.
> 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.
>
> 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.
As Alan points out most Apache projects share the same repository,
including *all* of the incubating projects. So we're not going to
create our own repository. But I also recall that other projects have
imported their entire history when entering the incubator, so it's
something I'd leave for the experts in infrastructure to take care of.
Craig
>
>
> On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera
> <li...@toolazydogs.com>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 <Craig.Russell@sun.com
>>>>> 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 <
>>>>>> list@toolazydogs.com
>>>>>>
>>>>>>> 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 <
>>>>>>>> list@toolazydogs.com
>>>>>>>>
>>>>>>>> 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:Craig.Russell@sun.com
>>>>> 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:Craig.Russell@sun.com
>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Emmanuel Lecharny <el...@gmail.com>.
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.
>
+1
<snip/>
> 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.
That won't be possible here. We already are at rev 680 000 ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Yes. Most, if not all, all of ASF project's subversion repository
works this way. It seems bizarre to me as an ASF member.
Regards,
Alan
On Jul 26, 2008, at 9:25 AM, Les Hazlewood wrote:
> Really?
>
> So if I make a commit for my project, and that is revision N, then if
> someone immediately makes a commit for a totally different project,
> that
> would be N+1?
>
> I thought only the Incubator worked like that. Seems really bizzare
> to me
> as an ASF newbie....
>
> On Sat, Jul 26, 2008 at 12:12 PM, Noel J. Bergman <no...@devtech.com>
> wrote:
>
>>> when [graduating] to a TLP, were you able to retain
>>> the history while working in the Incubator when you
>>> moved to an SVN repo of your own?
>>
>> You don't move to an SVN repo of your own. You stay in the main ASF
>> repository, along with all other ASF projects and other public
>> content.
>>
>> --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Yes. Most, if not all, all of ASF project's subversion repository
works this way. It seems bizarre to me as an ASF member.
Regards,
Alan
On Jul 26, 2008, at 9:25 AM, Les Hazlewood wrote:
> Really?
>
> So if I make a commit for my project, and that is revision N, then if
> someone immediately makes a commit for a totally different project,
> that
> would be N+1?
>
> I thought only the Incubator worked like that. Seems really bizzare
> to me
> as an ASF newbie....
>
> On Sat, Jul 26, 2008 at 12:12 PM, Noel J. Bergman <no...@devtech.com>
> wrote:
>
>>> when [graduating] to a TLP, were you able to retain
>>> the history while working in the Incubator when you
>>> moved to an SVN repo of your own?
>>
>> You don't move to an SVN repo of your own. You stay in the main ASF
>> repository, along with all other ASF projects and other public
>> content.
>>
>> --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
Really?
So if I make a commit for my project, and that is revision N, then if
someone immediately makes a commit for a totally different project, that
would be N+1?
I thought only the Incubator worked like that. Seems really bizzare to me
as an ASF newbie....
On Sat, Jul 26, 2008 at 12:12 PM, Noel J. Bergman <no...@devtech.com> wrote:
> > when [graduating] to a TLP, were you able to retain
> > the history while working in the Incubator when you
> > moved to an SVN repo of your own?
>
> You don't move to an SVN repo of your own. You stay in the main ASF
> repository, along with all other ASF projects and other public content.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
Really?
So if I make a commit for my project, and that is revision N, then if
someone immediately makes a commit for a totally different project, that
would be N+1?
I thought only the Incubator worked like that. Seems really bizzare to me
as an ASF newbie....
On Sat, Jul 26, 2008 at 12:12 PM, Noel J. Bergman <no...@devtech.com> wrote:
> > when [graduating] to a TLP, were you able to retain
> > the history while working in the Incubator when you
> > moved to an SVN repo of your own?
>
> You don't move to an SVN repo of your own. You stay in the main ASF
> repository, along with all other ASF projects and other public content.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
> when [graduating] to a TLP, were you able to retain
> the history while working in the Incubator when you
> moved to an SVN repo of your own?
You don't move to an SVN repo of your own. You stay in the main ASF repository, along with all other ASF projects and other public content.
--- Noel
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
> when [graduating] to a TLP, were you able to retain
> the history while working in the Incubator when you
> moved to an SVN repo of your own?
You don't move to an SVN repo of your own. You stay in the main ASF repository, along with all other ASF projects and other public content.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
This brings up a follow-up question - when Wicket graduated to a TLP, were
you able to retain the history while working in the Incubator when you moved
to an SVN repo of your own?
On Sat, Jul 26, 2008 at 11:22 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>
> On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> >> Can you provide one example? Just curious....
>> >
>> > While it was incubating, Wicket did a few non-ASF releases on their
>> > old project site, to minimize disruption for their existing users
>> > while they were repackaging and cleaning up for an ASF release.
>>
>> And even after we had graduated. Wicket 1.2.7 (the final maintenance
>> release for the 1.2 branch) was created in last March. We didn't use
>> the Apache mirroring system and put a disclaimer in it that the
>> release was non-Apache. [1]
>
>
> In my opinion, this is more important than anything else. If we're going
> to import our code into ASF SVN, we must still be able to make edits to that
> code with the intention of releasing those edits later outside of the ASF to
> our existing community.
>
> To bring others up to speed, this is what we're looking at right now:
>
> The JSecurity team is trying to release 0.9.0 RC1 to our existing
> community, with no ties to the ASF. After that is out, it isn't unlikely
> that a few more changes will need to occur before 0.9.0 Final. (There might
> even be an RC2, but I hope not - we'll see). After 0.9.0 final is out, only
> then do I think would we want to call any of our releases an ASF release and
> go through the Incubator release approval process. Prior to that I have no
> problem not mentioning ASF anywhere.
>
> In other words, we would keep doing things exactly as we have for the last
> three years, its just we happen to be using ASF SVN hosting instead of
> SourceForge SVN hosting - that would be the only difference.
>
> The reason why this is critiical is if any source code changes go in to
> say, an 0.9.0 brach, they have to make their way into trunk at the same time
> - branch merging and all, etc. That would be a nightmare if we have to make
> these changes manually to two different repositories. If that is forced
> upon us, I would ask the previous JSecurity dev team to wait to do the code
> import into ASF until after that time.
>
> But I don't like this option - it doesn't attract other ASF developers
> because they don't have ASF access to the source code - they'd have to join
> the SF project until the time when the team says they want to do their first
> ASF release. Not ideal IMO.
>
> I don't see the early-import into ASF SVN as a problem though: to me at
> least, this is one of the things the incubation process helps to resolve -
> there is nothing IMO wrong with ASF SVN hosting source code for an existing
> oommunity under the knowledge that it will be actively converted to the ASF
> community in the process. That's part of migration, which to me, is a key
> point of incubation for projects with a previous history.
>
>
> Yep, and it really is a problem IMO when incoming *open source*
>> projects have to ditch their collected history. If we care about code
>> provenance, having the full history available is best.
>
>
> As far as I'm concerned, ditching history is not an option at all. We need
> to always be able to compare previous code, maybe resurrect things that were
> deleted, etc. I'd hate to lose that capability.
>
> Martjin, when you guys migrated your source code for Wicket, how did you
> retain history when it was imported into the Incubator SVN? Did you use
> 'svnadmin dump' and then load it into the Incubator repository via 'svnadmin
> load'? Or did you use svnsync? (this is all assuming that your previous
> repo was already SVN...)
>
> Cheers,
>
> Les
>
>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
This brings up a follow-up question - when Wicket graduated to a TLP, were
you able to retain the history while working in the Incubator when you moved
to an SVN repo of your own?
On Sat, Jul 26, 2008 at 11:22 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>
> On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> >> Can you provide one example? Just curious....
>> >
>> > While it was incubating, Wicket did a few non-ASF releases on their
>> > old project site, to minimize disruption for their existing users
>> > while they were repackaging and cleaning up for an ASF release.
>>
>> And even after we had graduated. Wicket 1.2.7 (the final maintenance
>> release for the 1.2 branch) was created in last March. We didn't use
>> the Apache mirroring system and put a disclaimer in it that the
>> release was non-Apache. [1]
>
>
> In my opinion, this is more important than anything else. If we're going
> to import our code into ASF SVN, we must still be able to make edits to that
> code with the intention of releasing those edits later outside of the ASF to
> our existing community.
>
> To bring others up to speed, this is what we're looking at right now:
>
> The JSecurity team is trying to release 0.9.0 RC1 to our existing
> community, with no ties to the ASF. After that is out, it isn't unlikely
> that a few more changes will need to occur before 0.9.0 Final. (There might
> even be an RC2, but I hope not - we'll see). After 0.9.0 final is out, only
> then do I think would we want to call any of our releases an ASF release and
> go through the Incubator release approval process. Prior to that I have no
> problem not mentioning ASF anywhere.
>
> In other words, we would keep doing things exactly as we have for the last
> three years, its just we happen to be using ASF SVN hosting instead of
> SourceForge SVN hosting - that would be the only difference.
>
> The reason why this is critiical is if any source code changes go in to
> say, an 0.9.0 brach, they have to make their way into trunk at the same time
> - branch merging and all, etc. That would be a nightmare if we have to make
> these changes manually to two different repositories. If that is forced
> upon us, I would ask the previous JSecurity dev team to wait to do the code
> import into ASF until after that time.
>
> But I don't like this option - it doesn't attract other ASF developers
> because they don't have ASF access to the source code - they'd have to join
> the SF project until the time when the team says they want to do their first
> ASF release. Not ideal IMO.
>
> I don't see the early-import into ASF SVN as a problem though: to me at
> least, this is one of the things the incubation process helps to resolve -
> there is nothing IMO wrong with ASF SVN hosting source code for an existing
> oommunity under the knowledge that it will be actively converted to the ASF
> community in the process. That's part of migration, which to me, is a key
> point of incubation for projects with a previous history.
>
>
> Yep, and it really is a problem IMO when incoming *open source*
>> projects have to ditch their collected history. If we care about code
>> provenance, having the full history available is best.
>
>
> As far as I'm concerned, ditching history is not an option at all. We need
> to always be able to compare previous code, maybe resurrect things that were
> deleted, etc. I'd hate to lose that capability.
>
> Martjin, when you guys migrated your source code for Wicket, how did you
> retain history when it was imported into the Incubator SVN? Did you use
> 'svnadmin dump' and then load it into the Incubator repository via 'svnadmin
> load'? Or did you use svnsync? (this is all assuming that your previous
> repo was already SVN...)
>
> Cheers,
>
> Les
>
>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> >> Can you provide one example? Just curious....
> >
> > While it was incubating, Wicket did a few non-ASF releases on their
> > old project site, to minimize disruption for their existing users
> > while they were repackaging and cleaning up for an ASF release.
>
> And even after we had graduated. Wicket 1.2.7 (the final maintenance
> release for the 1.2 branch) was created in last March. We didn't use
> the Apache mirroring system and put a disclaimer in it that the
> release was non-Apache. [1]
In my opinion, this is more important than anything else. If we're going to
import our code into ASF SVN, we must still be able to make edits to that
code with the intention of releasing those edits later outside of the ASF to
our existing community.
To bring others up to speed, this is what we're looking at right now:
The JSecurity team is trying to release 0.9.0 RC1 to our existing community,
with no ties to the ASF. After that is out, it isn't unlikely that a few
more changes will need to occur before 0.9.0 Final. (There might even be an
RC2, but I hope not - we'll see). After 0.9.0 final is out, only then do I
think would we want to call any of our releases an ASF release and go
through the Incubator release approval process. Prior to that I have no
problem not mentioning ASF anywhere.
In other words, we would keep doing things exactly as we have for the last
three years, its just we happen to be using ASF SVN hosting instead of
SourceForge SVN hosting - that would be the only difference.
The reason why this is critiical is if any source code changes go in to say,
an 0.9.0 brach, they have to make their way into trunk at the same time -
branch merging and all, etc. That would be a nightmare if we have to make
these changes manually to two different repositories. If that is forced
upon us, I would ask the previous JSecurity dev team to wait to do the code
import into ASF until after that time.
But I don't like this option - it doesn't attract other ASF developers
because they don't have ASF access to the source code - they'd have to join
the SF project until the time when the team says they want to do their first
ASF release. Not ideal IMO.
I don't see the early-import into ASF SVN as a problem though: to me at
least, this is one of the things the incubation process helps to resolve -
there is nothing IMO wrong with ASF SVN hosting source code for an existing
oommunity under the knowledge that it will be actively converted to the ASF
community in the process. That's part of migration, which to me, is a key
point of incubation for projects with a previous history.
Yep, and it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we care about code
> provenance, having the full history available is best.
As far as I'm concerned, ditching history is not an option at all. We need
to always be able to compare previous code, maybe resurrect things that were
deleted, etc. I'd hate to lose that capability.
Martjin, when you guys migrated your source code for Wicket, how did you
retain history when it was imported into the Incubator SVN? Did you use
'svnadmin dump' and then load it into the Incubator repository via 'svnadmin
load'? Or did you use svnsync? (this is all assuming that your previous
repo was already SVN...)
Cheers,
Les
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> >> Can you provide one example? Just curious....
> >
> > While it was incubating, Wicket did a few non-ASF releases on their
> > old project site, to minimize disruption for their existing users
> > while they were repackaging and cleaning up for an ASF release.
>
> And even after we had graduated. Wicket 1.2.7 (the final maintenance
> release for the 1.2 branch) was created in last March. We didn't use
> the Apache mirroring system and put a disclaimer in it that the
> release was non-Apache. [1]
In my opinion, this is more important than anything else. If we're going to
import our code into ASF SVN, we must still be able to make edits to that
code with the intention of releasing those edits later outside of the ASF to
our existing community.
To bring others up to speed, this is what we're looking at right now:
The JSecurity team is trying to release 0.9.0 RC1 to our existing community,
with no ties to the ASF. After that is out, it isn't unlikely that a few
more changes will need to occur before 0.9.0 Final. (There might even be an
RC2, but I hope not - we'll see). After 0.9.0 final is out, only then do I
think would we want to call any of our releases an ASF release and go
through the Incubator release approval process. Prior to that I have no
problem not mentioning ASF anywhere.
In other words, we would keep doing things exactly as we have for the last
three years, its just we happen to be using ASF SVN hosting instead of
SourceForge SVN hosting - that would be the only difference.
The reason why this is critiical is if any source code changes go in to say,
an 0.9.0 brach, they have to make their way into trunk at the same time -
branch merging and all, etc. That would be a nightmare if we have to make
these changes manually to two different repositories. If that is forced
upon us, I would ask the previous JSecurity dev team to wait to do the code
import into ASF until after that time.
But I don't like this option - it doesn't attract other ASF developers
because they don't have ASF access to the source code - they'd have to join
the SF project until the time when the team says they want to do their first
ASF release. Not ideal IMO.
I don't see the early-import into ASF SVN as a problem though: to me at
least, this is one of the things the incubation process helps to resolve -
there is nothing IMO wrong with ASF SVN hosting source code for an existing
oommunity under the knowledge that it will be actively converted to the ASF
community in the process. That's part of migration, which to me, is a key
point of incubation for projects with a previous history.
Yep, and it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we care about code
> provenance, having the full history available is best.
As far as I'm concerned, ditching history is not an option at all. We need
to always be able to compare previous code, maybe resurrect things that were
deleted, etc. I'd hate to lose that capability.
Martjin, when you guys migrated your source code for Wicket, how did you
retain history when it was imported into the Incubator SVN? Did you use
'svnadmin dump' and then load it into the Incubator repository via 'svnadmin
load'? Or did you use svnsync? (this is all assuming that your previous
repo was already SVN...)
Cheers,
Les
Fwd: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Good news for the team.
Begin forwarded message:
> From: "Martijn Dashorst" <ma...@gmail.com>
> Date: July 28, 2008 8:15:44 AM PDT
> To: general@incubator.apache.org
> Subject: Re: SVN move
> Reply-To: general@incubator.apache.org
>
> On Mon, Jul 28, 2008 at 4:55 PM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>> So, to make this a little more clear, when Wicket performed a few
>> non-ASF
>> releases on their old project site was their old Subversion
>> repository
>> shutdown and the ASF Subversion repository exclusively used?
>
> Yes. We are volunteers. Having to maintain 2 repositories would have
> been prohibitive. We made it absolutely clear that if we were not able
> to create releases from our code base, and had to maintain 2
> repositories, we would not have joined Apache.
>
>> Was work for the non-ASF release checked into and maintained on the
>> ASF Subversion
>> repository?
>
> Yes. When we imported our repository we included everything (full
> history) from our old SVN repository.
>
>> What about the older, pre-incubation, versions of Wicket? Were
>> they also stored and maintained on the ASF Subversion repository?
>
> Yes, but older versions are no longer maintained (we currently only
> support ASF releases, provided there are no security issues).
>
> Martijn
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Fwd: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
More good news.
Begin forwarded message:
> From: Janne Jalkanen <Ja...@ecyrd.com>
> Date: July 28, 2008 8:35:28 AM PDT
> To: general@incubator.apache.org
> Subject: Re: SVN move
> Reply-To: general@incubator.apache.org
>
>>> So, to make this a little more clear, when Wicket performed a few
>>> non-ASF
>>> releases on their old project site was their old Subversion
>>> repository
>>> shutdown and the ASF Subversion repository exclusively used?
>>
>> Yes. We are volunteers. Having to maintain 2 repositories would have
>> been prohibitive. We made it absolutely clear that if we were not
>> able
>> to create releases from our code base, and had to maintain 2
>> repositories, we would not have joined Apache.
>
> I can also say the same for JSPWiki. Having to maintain two code
> repositories, two issue trackers and a total of four mailing lists
> would be too much of a pain. Both to developers and users.
>
> I don't think JSPWiki would've attempted Apache Incubation if that
> were a requirement.
>
>> Yes. When we imported our repository we included everything (full
>> history) from our old SVN repository.
>
> Ditto. The Incubation work has been concentrating on relicensing
> the code under AL 2.0, and learning the Apache ways of working. We
> release updates to the old releases using our own distribution
> mechanism (for the general user, there is no trace of Apache
> anywhere, except the fact that the issue tracker is on ASFs site,
> and so is the mailing list). However, this gives us a great way to
> practice the Apache way of working with minimal disruption to
> development.
>
> Since JSPWiki code has been under various versions of GPL since
> 2001, this relicensing stuff has taken quite a while, including
> pieces of code which needed to be completely rewritten from
> scratch. If that work had to be done in two repositories at the
> same time, we might as well have forgotten about it.
>
> It was clear from the beginning that the transition of a large
> project into Apache would not be easy or fast, especially since all
> of the committers are working on a volunteer basis. I find the
> Incubator to be an excellent "safe haven" where this work can be done.
>
>> Yes, but older versions are no longer maintained (we currently only
>> support ASF releases, provided there are no security issues).
>
> This is also our plan; there is no desire to continue maintenance of
> the LGPL-version of the code, once the ASF transition and incubation
> is complete.
>
> /Janne, who is sorry he can't contribute much to this conversation -
> I'm on holiday behind a slow cell connection...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: SVN move
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>> So, to make this a little more clear, when Wicket performed a few
>> non-ASF
>> releases on their old project site was their old Subversion
>> repository
>> shutdown and the ASF Subversion repository exclusively used?
>
> Yes. We are volunteers. Having to maintain 2 repositories would have
> been prohibitive. We made it absolutely clear that if we were not able
> to create releases from our code base, and had to maintain 2
> repositories, we would not have joined Apache.
I can also say the same for JSPWiki. Having to maintain two code
repositories, two issue trackers and a total of four mailing lists
would be too much of a pain. Both to developers and users.
I don't think JSPWiki would've attempted Apache Incubation if that
were a requirement.
> Yes. When we imported our repository we included everything (full
> history) from our old SVN repository.
Ditto. The Incubation work has been concentrating on relicensing the
code under AL 2.0, and learning the Apache ways of working. We
release updates to the old releases using our own distribution
mechanism (for the general user, there is no trace of Apache
anywhere, except the fact that the issue tracker is on ASFs site, and
so is the mailing list). However, this gives us a great way to
practice the Apache way of working with minimal disruption to
development.
Since JSPWiki code has been under various versions of GPL since 2001,
this relicensing stuff has taken quite a while, including pieces of
code which needed to be completely rewritten from scratch. If that
work had to be done in two repositories at the same time, we might as
well have forgotten about it.
It was clear from the beginning that the transition of a large
project into Apache would not be easy or fast, especially since all
of the committers are working on a volunteer basis. I find the
Incubator to be an excellent "safe haven" where this work can be done.
> Yes, but older versions are no longer maintained (we currently only
> support ASF releases, provided there are no security issues).
This is also our plan; there is no desire to continue maintenance of
the LGPL-version of the code, once the ASF transition and incubation
is complete.
/Janne, who is sorry he can't contribute much to this conversation -
I'm on holiday behind a slow cell connection...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jul 28, 2008 at 4:55 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> So, to make this a little more clear, when Wicket performed a few non-ASF
> releases on their old project site was their old Subversion repository
> shutdown and the ASF Subversion repository exclusively used?
Yes. We are volunteers. Having to maintain 2 repositories would have
been prohibitive. We made it absolutely clear that if we were not able
to create releases from our code base, and had to maintain 2
repositories, we would not have joined Apache.
> Was work for the non-ASF release checked into and maintained on the ASF Subversion
> repository?
Yes. When we imported our repository we included everything (full
history) from our old SVN repository.
> What about the older, pre-incubation, versions of Wicket? Were
> they also stored and maintained on the ASF Subversion repository?
Yes, but older versions are no longer maintained (we currently only
support ASF releases, provided there are no security issues).
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:10 AM, Alan D. Cabrera wrote:
>
> On Jul 26, 2008, at 1:20 AM, Bertrand Delacretaz wrote:
>
>> On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera <list@toolazydogs.com
>> > wrote:
>>
>>>
>>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>>
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>>>>
>>>>>> 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?
>>>>
>>>> Of course.
>>>
>>> Can you provide one example? Just curious....
>>
>> While it was incubating, Wicket did a few non-ASF releases on their
>> old project site, to minimize disruption for their existing users
>> while they were repackaging and cleaning up for an ASF release.
>>
>> I haven't followed all of this discussion, but IIUC that's a
>> similar situation.
>
> So, to make this a little more clear, when Wicket performed a few
> non-ASF releases on their old project site was their old Subversion
> repository shutdown and the ASF Subversion repository exclusively
> used? Was work for the non-ASF release checked into and maintained
> on the ASF Subversion repository? What about the older, pre-
> incubation, versions of Wicket? Were they also stored and
> maintained on the ASF Subversion repository?
Can anyone shed some light on these questions?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:10 AM, Alan D. Cabrera wrote:
>
> On Jul 26, 2008, at 1:20 AM, Bertrand Delacretaz wrote:
>
>> On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera <list@toolazydogs.com
>> > wrote:
>>
>>>
>>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>>
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>>>>
>>>>>> 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?
>>>>
>>>> Of course.
>>>
>>> Can you provide one example? Just curious....
>>
>> While it was incubating, Wicket did a few non-ASF releases on their
>> old project site, to minimize disruption for their existing users
>> while they were repackaging and cleaning up for an ASF release.
>>
>> I haven't followed all of this discussion, but IIUC that's a
>> similar situation.
>
> So, to make this a little more clear, when Wicket performed a few
> non-ASF releases on their old project site was their old Subversion
> repository shutdown and the ASF Subversion repository exclusively
> used? Was work for the non-ASF release checked into and maintained
> on the ASF Subversion repository? What about the older, pre-
> incubation, versions of Wicket? Were they also stored and
> maintained on the ASF Subversion repository?
Can anyone shed some light on these questions?
Regards,
Alan
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 1:20 AM, Bertrand Delacretaz wrote:
> On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>
>>
>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>
>>> Alan D. Cabrera wrote:
>>>>
>>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>>>
>>>>> 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?
>>>
>>> Of course.
>>
>> Can you provide one example? Just curious....
>
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
>
> I haven't followed all of this discussion, but IIUC that's a similar
> situation.
So, to make this a little more clear, when Wicket performed a few non-
ASF releases on their old project site was their old Subversion
repository shutdown and the ASF Subversion repository exclusively
used? Was work for the non-ASF release checked into and maintained on
the ASF Subversion repository? What about the older, pre-incubation,
versions of Wicket? Were they also stored and maintained on the ASF
Subversion repository?
Regards,
Alan
RE: SVN move
Posted by Henning Schmiedehausen <he...@apache.org>.
Ask Cayenne who worked that way for a long time.
Ciao
Henning
On Sat, 2008-07-26 at 11:19 -0400, Noel J. Bergman wrote:
> Bertrand Delacretaz wrote:
>
> > While it was incubating, Wicket did a few non-ASF releases on their
> > old project site, to minimize disruption for their existing users
> > while they were repackaging and cleaning up for an ASF release.
>
> If I recall correctly, the first project that had to address this seriously was Roller. Dave Johnson and Justin Erenkrantz discussed issues in detail.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by Henning Schmiedehausen <he...@apache.org>.
Ask Cayenne who worked that way for a long time.
Ciao
Henning
On Sat, 2008-07-26 at 11:19 -0400, Noel J. Bergman wrote:
> Bertrand Delacretaz wrote:
>
> > While it was incubating, Wicket did a few non-ASF releases on their
> > old project site, to minimize disruption for their existing users
> > while they were repackaging and cleaning up for an ASF release.
>
> If I recall correctly, the first project that had to address this seriously was Roller. Dave Johnson and Justin Erenkrantz discussed issues in detail.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bertrand Delacretaz wrote:
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
If I recall correctly, the first project that had to address this seriously was Roller. Dave Johnson and Justin Erenkrantz discussed issues in detail.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 1:20 AM, Bertrand Delacretaz wrote:
> On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera
> <li...@toolazydogs.com> wrote:
>
>>
>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>
>>> Alan D. Cabrera wrote:
>>>>
>>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>>>
>>>>> 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?
>>>
>>> Of course.
>>
>> Can you provide one example? Just curious....
>
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
>
> I haven't followed all of this discussion, but IIUC that's a similar
> situation.
So, to make this a little more clear, when Wicket performed a few non-
ASF releases on their old project site was their old Subversion
repository shutdown and the ASF Subversion repository exclusively
used? Was work for the non-ASF release checked into and maintained on
the ASF Subversion repository? What about the older, pre-incubation,
versions of Wicket? Were they also stored and maintained on the ASF
Subversion repository?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bertrand Delacretaz wrote:
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
If I recall correctly, the first project that had to address this seriously was Roller. Dave Johnson and Justin Erenkrantz discussed issues in detail.
--- Noel
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:18 AM, Alan D. Cabrera wrote:
>
> On Jul 26, 2008, at 2:47 AM, Martijn Dashorst wrote:
>
>> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>>> Can you provide one example? Just curious....
>>>
>>> While it was incubating, Wicket did a few non-ASF releases on their
>>> old project site, to minimize disruption for their existing users
>>> while they were repackaging and cleaning up for an ASF release.
>>
>> And even after we had graduated. Wicket 1.2.7 (the final maintenance
>> release for the 1.2 branch) was created in last March. We didn't use
>> the Apache mirroring system and put a disclaimer in it that the
>> release was non-Apache. [1]
>
> I haven't been following the Wicket history too closely. I assume
> that this branch is in the ASF Subversion repository.
>
> So is it safe to say that the Wicket 1.2 branch is a pre-incubation
> branch? What changes were made with regards to ASF/Incubator
> policy? I'm wondering if this branch stayed the same, e.g. old
> package names, or were there changes made to this branch to bring it
> in line with ASF policies.
>
>> This is a service we provide for our users that were with us before
>> we
>> moved to apache and are counting on us to provide support on their
>> production systems. However, since we are a volunteer effort with
>> limited resources, we have discontinued to support the 1.2 branch
>> (though we will act on security issues) and now focus on Apache
>> software :).
>>
>>> I haven't followed all of this discussion, but IIUC that's a
>>> similar situation.
>>
>> Yep, and it really is a problem IMO when incoming *open source*
>> projects have to ditch their collected history. If we care about code
>> provenance, having the full history available is best.
>
>
> Keeping the history to maintain code provenance is one thing, and a
> good thing. Maintaining and making non-ASF releases on ASF
> infrastructure is another. It seems that the latter has been done
> before, e.g. Wicket. Are their any guidelines for doing this?
Can anyone confirm the above statements and provide any guidelines?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:18 AM, Alan D. Cabrera wrote:
>
> On Jul 26, 2008, at 2:47 AM, Martijn Dashorst wrote:
>
>> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>>> Can you provide one example? Just curious....
>>>
>>> While it was incubating, Wicket did a few non-ASF releases on their
>>> old project site, to minimize disruption for their existing users
>>> while they were repackaging and cleaning up for an ASF release.
>>
>> And even after we had graduated. Wicket 1.2.7 (the final maintenance
>> release for the 1.2 branch) was created in last March. We didn't use
>> the Apache mirroring system and put a disclaimer in it that the
>> release was non-Apache. [1]
>
> I haven't been following the Wicket history too closely. I assume
> that this branch is in the ASF Subversion repository.
>
> So is it safe to say that the Wicket 1.2 branch is a pre-incubation
> branch? What changes were made with regards to ASF/Incubator
> policy? I'm wondering if this branch stayed the same, e.g. old
> package names, or were there changes made to this branch to bring it
> in line with ASF policies.
>
>> This is a service we provide for our users that were with us before
>> we
>> moved to apache and are counting on us to provide support on their
>> production systems. However, since we are a volunteer effort with
>> limited resources, we have discontinued to support the 1.2 branch
>> (though we will act on security issues) and now focus on Apache
>> software :).
>>
>>> I haven't followed all of this discussion, but IIUC that's a
>>> similar situation.
>>
>> Yep, and it really is a problem IMO when incoming *open source*
>> projects have to ditch their collected history. If we care about code
>> provenance, having the full history available is best.
>
>
> Keeping the history to maintain code provenance is one thing, and a
> good thing. Maintaining and making non-ASF releases on ASF
> infrastructure is another. It seems that the latter has been done
> before, e.g. Wicket. Are their any guidelines for doing this?
Can anyone confirm the above statements and provide any guidelines?
Regards,
Alan
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 2:47 AM, Martijn Dashorst wrote:
> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>>> Can you provide one example? Just curious....
>>
>> While it was incubating, Wicket did a few non-ASF releases on their
>> old project site, to minimize disruption for their existing users
>> while they were repackaging and cleaning up for an ASF release.
>
> And even after we had graduated. Wicket 1.2.7 (the final maintenance
> release for the 1.2 branch) was created in last March. We didn't use
> the Apache mirroring system and put a disclaimer in it that the
> release was non-Apache. [1]
I haven't been following the Wicket history too closely. I assume
that this branch is in the ASF Subversion repository.
So is it safe to say that the Wicket 1.2 branch is a pre-incubation
branch? What changes were made with regards to ASF/Incubator policy?
I'm wondering if this branch stayed the same, e.g. old package names,
or were there changes made to this branch to bring it in line with ASF
policies.
> This is a service we provide for our users that were with us before we
> moved to apache and are counting on us to provide support on their
> production systems. However, since we are a volunteer effort with
> limited resources, we have discontinued to support the 1.2 branch
> (though we will act on security issues) and now focus on Apache
> software :).
>
>> I haven't followed all of this discussion, but IIUC that's a
>> similar situation.
>
> Yep, and it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we care about code
> provenance, having the full history available is best.
Keeping the history to maintain code provenance is one thing, and a
good thing. Maintaining and making non-ASF releases on ASF
infrastructure is another. It seems that the latter has been done
before, e.g. Wicket. Are their any guidelines for doing this?
Regards,
Alan
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
Martijn Dashorst wrote:
> it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we
> care about code provenance, having the full history
> available is best.
I concur, although I'm not sure that everyone does.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 2:47 AM, Martijn Dashorst wrote:
> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>>> Can you provide one example? Just curious....
>>
>> While it was incubating, Wicket did a few non-ASF releases on their
>> old project site, to minimize disruption for their existing users
>> while they were repackaging and cleaning up for an ASF release.
>
> And even after we had graduated. Wicket 1.2.7 (the final maintenance
> release for the 1.2 branch) was created in last March. We didn't use
> the Apache mirroring system and put a disclaimer in it that the
> release was non-Apache. [1]
I haven't been following the Wicket history too closely. I assume
that this branch is in the ASF Subversion repository.
So is it safe to say that the Wicket 1.2 branch is a pre-incubation
branch? What changes were made with regards to ASF/Incubator policy?
I'm wondering if this branch stayed the same, e.g. old package names,
or were there changes made to this branch to bring it in line with ASF
policies.
> This is a service we provide for our users that were with us before we
> moved to apache and are counting on us to provide support on their
> production systems. However, since we are a volunteer effort with
> limited resources, we have discontinued to support the 1.2 branch
> (though we will act on security issues) and now focus on Apache
> software :).
>
>> I haven't followed all of this discussion, but IIUC that's a
>> similar situation.
>
> Yep, and it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we care about code
> provenance, having the full history available is best.
Keeping the history to maintain code provenance is one thing, and a
good thing. Maintaining and making non-ASF releases on ASF
infrastructure is another. It seems that the latter has been done
before, e.g. Wicket. Are their any guidelines for doing this?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Martijn Dashorst <ma...@gmail.com>.
On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
>> Can you provide one example? Just curious....
>
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
And even after we had graduated. Wicket 1.2.7 (the final maintenance
release for the 1.2 branch) was created in last March. We didn't use
the Apache mirroring system and put a disclaimer in it that the
release was non-Apache. [1]
This is a service we provide for our users that were with us before we
moved to apache and are counting on us to provide support on their
production systems. However, since we are a volunteer effort with
limited resources, we have discontinued to support the 1.2 branch
(though we will act on security issues) and now focus on Apache
software :).
> I haven't followed all of this discussion, but IIUC that's a similar situation.
Yep, and it really is a problem IMO when incoming *open source*
projects have to ditch their collected history. If we care about code
provenance, having the full history available is best.
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: SVN move
Posted by Martijn Dashorst <ma...@gmail.com>.
On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
>> Can you provide one example? Just curious....
>
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.
And even after we had graduated. Wicket 1.2.7 (the final maintenance
release for the 1.2 branch) was created in last March. We didn't use
the Apache mirroring system and put a disclaimer in it that the
release was non-Apache. [1]
This is a service we provide for our users that were with us before we
moved to apache and are counting on us to provide support on their
production systems. However, since we are a volunteer effort with
limited resources, we have discontinued to support the 1.2 branch
(though we will act on security issues) and now focus on Apache
software :).
> I haven't followed all of this discussion, but IIUC that's a similar situation.
Yep, and it really is a problem IMO when incoming *open source*
projects have to ditch their collected history. If we care about code
provenance, having the full history available is best.
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>>
>>> 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?
>>
>> Of course.
>
> Can you provide one example? Just curious....
While it was incubating, Wicket did a few non-ASF releases on their
old project site, to minimize disruption for their existing users
while they were repackaging and cleaning up for an ASF release.
I haven't followed all of this discussion, but IIUC that's a similar situation.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
Oops, I should have said that "the conventional process is for the
podling to follow the usual Apache process and then call for a
Incubator PMC VOTE on the general incubator list."
Shouldn't have implied that some podlings might not follow the
conventional process.
Craig
On Aug 1, 2008, at 3:30 PM, William A. Rowe, Jr. wrote:
> Craig L Russell wrote:
>> It takes at least a week for an incubating release to get out
>> because in addition to getting everything right the first time, you
>> need a 3 day vote in the project and a 3 day vote in the incubator.
>
> Bullshit
>
> It takes 3 days. You need 3 binding PMC votes from the Incubator PMC.
>
> Announce the existence of the vote on general@ when it begins on the
> {podling}-dev@ list, and if you have 3 binding votes call it done.
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
Oops, I should have said that "the conventional process is for the
podling to follow the usual Apache process and then call for a
Incubator PMC VOTE on the general incubator list."
Shouldn't have implied that some podlings might not follow the
conventional process.
Craig
On Aug 1, 2008, at 3:30 PM, William A. Rowe, Jr. wrote:
> Craig L Russell wrote:
>> It takes at least a week for an incubating release to get out
>> because in addition to getting everything right the first time, you
>> need a 3 day vote in the project and a 3 day vote in the incubator.
>
> Bullshit
>
> It takes 3 days. You need 3 binding PMC votes from the Incubator PMC.
>
> Announce the existence of the vote on general@ when it begins on the
> {podling}-dev@ list, and if you have 3 binding votes call it done.
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Craig L Russell wrote:
>
> It takes at least a week for an incubating release to get out because in
> addition to getting everything right the first time, you need a 3 day
> vote in the project and a 3 day vote in the incubator.
Bullshit
It takes 3 days. You need 3 binding PMC votes from the Incubator PMC.
Announce the existence of the vote on general@ when it begins on the
{podling}-dev@ list, and if you have 3 binding votes call it done.
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Craig L Russell wrote:
>
> It takes at least a week for an incubating release to get out because in
> addition to getting everything right the first time, you need a 3 day
> vote in the project and a 3 day vote in the incubator.
Bullshit
It takes 3 days. You need 3 binding PMC votes from the Incubator PMC.
Announce the existence of the vote on general@ when it begins on the
{podling}-dev@ list, and if you have 3 binding votes call it done.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 28, 2008, at 10:49 AM, Les Hazlewood wrote:
>> Let's turn this around and look at it from a different light. What's
>> stopping us from doing a 0.9.0 release in the incubator? I'm
>> guessing that
>> you need the packages to be the same?
>
>
> Yes, that is one of the biggest reasons I can see at the moment.
>
> Probably more of a driving force though is that we're trying to
> release RC1
> in hopefully the next day or two - we have business users waiting on
> fixes
> that they really need, and I'm afraid we might make them wait much
> longer if
> we go through the the full release approval process.
It takes at least a week for an incubating release to get out because
in addition to getting everything right the first time, you need a 3
day vote in the project and a 3 day vote in the incubator.
Ok, it takes at least 6 days. Sue me. ;-)
Craig
>
>
> - Les
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>>
>>> 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?
>>
>> Of course.
>
> Can you provide one example? Just curious....
While it was incubating, Wicket did a few non-ASF releases on their
old project site, to minimize disruption for their existing users
while they were repackaging and cleaning up for an ASF release.
I haven't followed all of this discussion, but IIUC that's a similar situation.
-Bertrand
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 28, 2008, at 10:49 AM, Les Hazlewood wrote:
>> Let's turn this around and look at it from a different light. What's
>> stopping us from doing a 0.9.0 release in the incubator? I'm
>> guessing that
>> you need the packages to be the same?
>
>
> Yes, that is one of the biggest reasons I can see at the moment.
>
> Probably more of a driving force though is that we're trying to
> release RC1
> in hopefully the next day or two - we have business users waiting on
> fixes
> that they really need, and I'm afraid we might make them wait much
> longer if
> we go through the the full release approval process.
It takes at least a week for an incubating release to get out because
in addition to getting everything right the first time, you need a 3
day vote in the project and a 3 day vote in the incubator.
Ok, it takes at least 6 days. Sue me. ;-)
Craig
>
>
> - Les
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
> Let's turn this around and look at it from a different light. What's
> stopping us from doing a 0.9.0 release in the incubator? I'm guessing that
> you need the packages to be the same?
Yes, that is one of the biggest reasons I can see at the moment.
Probably more of a driving force though is that we're trying to release RC1
in hopefully the next day or two - we have business users waiting on fixes
that they really need, and I'm afraid we might make them wait much longer if
we go through the the full release approval process.
- Les
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
> Let's turn this around and look at it from a different light. What's
> stopping us from doing a 0.9.0 release in the incubator? I'm guessing that
> you need the packages to be the same?
Yes, that is one of the biggest reasons I can see at the moment.
Probably more of a driving force though is that we're trying to release RC1
in hopefully the next day or two - we have business users waiting on fixes
that they really need, and I'm afraid we might make them wait much longer if
we go through the the full release approval process.
- Les
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 28, 2008, at 10:37 AM, Craig L Russell wrote:
>
> On Jul 28, 2008, at 10:28 AM, Alan D. Cabrera wrote:
>
>>
>> On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>>
>>>>
>>>> Where I think that there is a problem is when they ditch their old
>>>> infrastructure and exclusively use ASF's infrastructure to build,
>>>> maintain,
>>>> and release non-ASF releases. To be sure in the case of
>>>> JSecurity the final
>>>> artifacts will not use the ASF mirrors but that does not hide
>>>> the fact that
>>>> they intend to build and maintain non-ASF releases exclusively
>>>> using our
>>>> infrastructure.
>>>>
>>>> Craig says that's fine.
>>>>
>>>> I think that they should release and maintain their new and
>>>> earlier non-ASF
>>>> releases on the infrastructure that they currently have or else
>>>> use ours and
>>>> follow the ASF/Incubator guidelines.
>>>
>>>
>>> If it turns out that it is *not* OK to do this (use ASF
>>> infrastructure
>>> exclusively to maintain our few remaining non-ASF releases), I'm
>>> perfectly
>>> ok with that and of course would respect the Incubator's wishes -
>>> but I
>>> myself would ask our current JSecurity team to delay the code
>>> import into
>>> the ASF.
>>>
>>> I don't think I would be willing to perform code modifications and
>>> patches
>>> for the next Release Candidate release(s) and maybe the few point
>>> releases
>>> that might follow on two different repositories. That's a
>>> nightmare to
>>> maintain - "Did I apply this patch to project-from-server-A and
>>> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
>>> method
>>> correctly in both locations...". No thanks :)
>>>
>>> Sure, this might delay our incubation process another few weeks or
>>> even a
>>> month or two, but I don't mind that at all - I feel comfortable that
>>> JSecurity will succeed at the ASF, so I don't feel a little extra
>>> delay
>>> would hurt things for us much... This is much less painful IMO than
>>> manually mantaining code in two separate locations.
>>
>> Let's turn this around and look at it from a different light.
>> What's stopping us from doing a 0.9.0 release in the incubator?
>> I'm guessing that you need the packages to be the same?
>
> I don't quite follow what you are proposing. Can you elaborate the
> details, please?
The 0.9.0 release gets done following ASF/Incubator procedures which
includes, changing package names to org.apache.jsecurity, making sure
it passes RAT, the PPMC must vote and it passes with at least 3
binding votes, etc.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 28, 2008, at 10:37 AM, Craig L Russell wrote:
>
> On Jul 28, 2008, at 10:28 AM, Alan D. Cabrera wrote:
>
>>
>> On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>>
>>>>
>>>> Where I think that there is a problem is when they ditch their old
>>>> infrastructure and exclusively use ASF's infrastructure to build,
>>>> maintain,
>>>> and release non-ASF releases. To be sure in the case of
>>>> JSecurity the final
>>>> artifacts will not use the ASF mirrors but that does not hide
>>>> the fact that
>>>> they intend to build and maintain non-ASF releases exclusively
>>>> using our
>>>> infrastructure.
>>>>
>>>> Craig says that's fine.
>>>>
>>>> I think that they should release and maintain their new and
>>>> earlier non-ASF
>>>> releases on the infrastructure that they currently have or else
>>>> use ours and
>>>> follow the ASF/Incubator guidelines.
>>>
>>>
>>> If it turns out that it is *not* OK to do this (use ASF
>>> infrastructure
>>> exclusively to maintain our few remaining non-ASF releases), I'm
>>> perfectly
>>> ok with that and of course would respect the Incubator's wishes -
>>> but I
>>> myself would ask our current JSecurity team to delay the code
>>> import into
>>> the ASF.
>>>
>>> I don't think I would be willing to perform code modifications and
>>> patches
>>> for the next Release Candidate release(s) and maybe the few point
>>> releases
>>> that might follow on two different repositories. That's a
>>> nightmare to
>>> maintain - "Did I apply this patch to project-from-server-A and
>>> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
>>> method
>>> correctly in both locations...". No thanks :)
>>>
>>> Sure, this might delay our incubation process another few weeks or
>>> even a
>>> month or two, but I don't mind that at all - I feel comfortable that
>>> JSecurity will succeed at the ASF, so I don't feel a little extra
>>> delay
>>> would hurt things for us much... This is much less painful IMO than
>>> manually mantaining code in two separate locations.
>>
>> Let's turn this around and look at it from a different light.
>> What's stopping us from doing a 0.9.0 release in the incubator?
>> I'm guessing that you need the packages to be the same?
>
> I don't quite follow what you are proposing. Can you elaborate the
> details, please?
The 0.9.0 release gets done following ASF/Incubator procedures which
includes, changing package names to org.apache.jsecurity, making sure
it passes RAT, the PPMC must vote and it passes with at least 3
binding votes, etc.
Regards,
Alan
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 28, 2008, at 10:28 AM, Alan D. Cabrera wrote:
>
> On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>
>>>
>>> Where I think that there is a problem is when they ditch their old
>>> infrastructure and exclusively use ASF's infrastructure to build,
>>> maintain,
>>> and release non-ASF releases. To be sure in the case of JSecurity
>>> the final
>>> artifacts will not use the ASF mirrors but that does not hide the
>>> fact that
>>> they intend to build and maintain non-ASF releases exclusively
>>> using our
>>> infrastructure.
>>>
>>> Craig says that's fine.
>>>
>>> I think that they should release and maintain their new and
>>> earlier non-ASF
>>> releases on the infrastructure that they currently have or else
>>> use ours and
>>> follow the ASF/Incubator guidelines.
>>
>>
>> If it turns out that it is *not* OK to do this (use ASF
>> infrastructure
>> exclusively to maintain our few remaining non-ASF releases), I'm
>> perfectly
>> ok with that and of course would respect the Incubator's wishes -
>> but I
>> myself would ask our current JSecurity team to delay the code
>> import into
>> the ASF.
>>
>> I don't think I would be willing to perform code modifications and
>> patches
>> for the next Release Candidate release(s) and maybe the few point
>> releases
>> that might follow on two different repositories. That's a
>> nightmare to
>> maintain - "Did I apply this patch to project-from-server-A and
>> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
>> method
>> correctly in both locations...". No thanks :)
>>
>> Sure, this might delay our incubation process another few weeks or
>> even a
>> month or two, but I don't mind that at all - I feel comfortable that
>> JSecurity will succeed at the ASF, so I don't feel a little extra
>> delay
>> would hurt things for us much... This is much less painful IMO than
>> manually mantaining code in two separate locations.
>
> Let's turn this around and look at it from a different light.
> What's stopping us from doing a 0.9.0 release in the incubator? I'm
> guessing that you need the packages to be the same?
I don't quite follow what you are proposing. Can you elaborate the
details, please?
Thanks,
Craig
>
>
>
> Regards,
> Alan
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 28, 2008, at 10:28 AM, Alan D. Cabrera wrote:
>
> On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>
>>>
>>> Where I think that there is a problem is when they ditch their old
>>> infrastructure and exclusively use ASF's infrastructure to build,
>>> maintain,
>>> and release non-ASF releases. To be sure in the case of JSecurity
>>> the final
>>> artifacts will not use the ASF mirrors but that does not hide the
>>> fact that
>>> they intend to build and maintain non-ASF releases exclusively
>>> using our
>>> infrastructure.
>>>
>>> Craig says that's fine.
>>>
>>> I think that they should release and maintain their new and
>>> earlier non-ASF
>>> releases on the infrastructure that they currently have or else
>>> use ours and
>>> follow the ASF/Incubator guidelines.
>>
>>
>> If it turns out that it is *not* OK to do this (use ASF
>> infrastructure
>> exclusively to maintain our few remaining non-ASF releases), I'm
>> perfectly
>> ok with that and of course would respect the Incubator's wishes -
>> but I
>> myself would ask our current JSecurity team to delay the code
>> import into
>> the ASF.
>>
>> I don't think I would be willing to perform code modifications and
>> patches
>> for the next Release Candidate release(s) and maybe the few point
>> releases
>> that might follow on two different repositories. That's a
>> nightmare to
>> maintain - "Did I apply this patch to project-from-server-A and
>> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
>> method
>> correctly in both locations...". No thanks :)
>>
>> Sure, this might delay our incubation process another few weeks or
>> even a
>> month or two, but I don't mind that at all - I feel comfortable that
>> JSecurity will succeed at the ASF, so I don't feel a little extra
>> delay
>> would hurt things for us much... This is much less painful IMO than
>> manually mantaining code in two separate locations.
>
> Let's turn this around and look at it from a different light.
> What's stopping us from doing a 0.9.0 release in the incubator? I'm
> guessing that you need the packages to be the same?
I don't quite follow what you are proposing. Can you elaborate the
details, please?
Thanks,
Craig
>
>
>
> Regards,
> Alan
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>>
>> Where I think that there is a problem is when they ditch their old
>> infrastructure and exclusively use ASF's infrastructure to build,
>> maintain,
>> and release non-ASF releases. To be sure in the case of JSecurity
>> the final
>> artifacts will not use the ASF mirrors but that does not hide the
>> fact that
>> they intend to build and maintain non-ASF releases exclusively
>> using our
>> infrastructure.
>>
>> Craig says that's fine.
>>
>> I think that they should release and maintain their new and earlier
>> non-ASF
>> releases on the infrastructure that they currently have or else use
>> ours and
>> follow the ASF/Incubator guidelines.
>
>
> If it turns out that it is *not* OK to do this (use ASF infrastructure
> exclusively to maintain our few remaining non-ASF releases), I'm
> perfectly
> ok with that and of course would respect the Incubator's wishes -
> but I
> myself would ask our current JSecurity team to delay the code import
> into
> the ASF.
>
> I don't think I would be willing to perform code modifications and
> patches
> for the next Release Candidate release(s) and maybe the few point
> releases
> that might follow on two different repositories. That's a nightmare
> to
> maintain - "Did I apply this patch to project-from-server-A and
> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
> method
> correctly in both locations...". No thanks :)
>
> Sure, this might delay our incubation process another few weeks or
> even a
> month or two, but I don't mind that at all - I feel comfortable that
> JSecurity will succeed at the ASF, so I don't feel a little extra
> delay
> would hurt things for us much... This is much less painful IMO than
> manually mantaining code in two separate locations.
Let's turn this around and look at it from a different light. What's
stopping us from doing a 0.9.0 release in the incubator? I'm guessing
that you need the packages to be the same?
Regards,
Alan
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
>>
>> Where I think that there is a problem is when they ditch their old
>> infrastructure and exclusively use ASF's infrastructure to build,
>> maintain,
>> and release non-ASF releases. To be sure in the case of JSecurity
>> the final
>> artifacts will not use the ASF mirrors but that does not hide the
>> fact that
>> they intend to build and maintain non-ASF releases exclusively
>> using our
>> infrastructure.
>>
>> Craig says that's fine.
>>
>> I think that they should release and maintain their new and earlier
>> non-ASF
>> releases on the infrastructure that they currently have or else use
>> ours and
>> follow the ASF/Incubator guidelines.
>
>
> If it turns out that it is *not* OK to do this (use ASF infrastructure
> exclusively to maintain our few remaining non-ASF releases), I'm
> perfectly
> ok with that and of course would respect the Incubator's wishes -
> but I
> myself would ask our current JSecurity team to delay the code import
> into
> the ASF.
>
> I don't think I would be willing to perform code modifications and
> patches
> for the next Release Candidate release(s) and maybe the few point
> releases
> that might follow on two different repositories. That's a nightmare
> to
> maintain - "Did I apply this patch to project-from-server-A and
> project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that
> method
> correctly in both locations...". No thanks :)
>
> Sure, this might delay our incubation process another few weeks or
> even a
> month or two, but I don't mind that at all - I feel comfortable that
> JSecurity will succeed at the ASF, so I don't feel a little extra
> delay
> would hurt things for us much... This is much less painful IMO than
> manually mantaining code in two separate locations.
Let's turn this around and look at it from a different light. What's
stopping us from doing a 0.9.0 release in the incubator? I'm guessing
that you need the packages to be the same?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
>
> Where I think that there is a problem is when they ditch their old
> infrastructure and exclusively use ASF's infrastructure to build, maintain,
> and release non-ASF releases. To be sure in the case of JSecurity the final
> artifacts will not use the ASF mirrors but that does not hide the fact that
> they intend to build and maintain non-ASF releases exclusively using our
> infrastructure.
>
> Craig says that's fine.
>
> I think that they should release and maintain their new and earlier non-ASF
> releases on the infrastructure that they currently have or else use ours and
> follow the ASF/Incubator guidelines.
If it turns out that it is *not* OK to do this (use ASF infrastructure
exclusively to maintain our few remaining non-ASF releases), I'm perfectly
ok with that and of course would respect the Incubator's wishes - but I
myself would ask our current JSecurity team to delay the code import into
the ASF.
I don't think I would be willing to perform code modifications and patches
for the next Release Candidate release(s) and maybe the few point releases
that might follow on two different repositories. That's a nightmare to
maintain - "Did I apply this patch to project-from-server-A and
project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that method
correctly in both locations...". No thanks :)
Sure, this might delay our incubation process another few weeks or even a
month or two, but I don't mind that at all - I feel comfortable that
JSecurity will succeed at the ASF, so I don't feel a little extra delay
would hurt things for us much... This is much less painful IMO than
manually mantaining code in two separate locations.
Regards,
Les
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
>
> Where I think that there is a problem is when they ditch their old
> infrastructure and exclusively use ASF's infrastructure to build, maintain,
> and release non-ASF releases. To be sure in the case of JSecurity the final
> artifacts will not use the ASF mirrors but that does not hide the fact that
> they intend to build and maintain non-ASF releases exclusively using our
> infrastructure.
>
> Craig says that's fine.
>
> I think that they should release and maintain their new and earlier non-ASF
> releases on the infrastructure that they currently have or else use ours and
> follow the ASF/Incubator guidelines.
If it turns out that it is *not* OK to do this (use ASF infrastructure
exclusively to maintain our few remaining non-ASF releases), I'm perfectly
ok with that and of course would respect the Incubator's wishes - but I
myself would ask our current JSecurity team to delay the code import into
the ASF.
I don't think I would be willing to perform code modifications and patches
for the next Release Candidate release(s) and maybe the few point releases
that might follow on two different repositories. That's a nightmare to
maintain - "Did I apply this patch to project-from-server-A and
project-from-server-B? Hrm.. I can't remember if I JavaDoc'd that method
correctly in both locations...". No thanks :)
Sure, this might delay our incubation process another few weeks or even a
month or two, but I don't mind that at all - I feel comfortable that
JSecurity will succeed at the ASF, so I don't feel a little extra delay
would hurt things for us much... This is much less painful IMO than
manually mantaining code in two separate locations.
Regards,
Les
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Alan D. Cabrera wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>> 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?
>> Of course.
>
> Can you provide one example? Just curious.
Try any project or product that integrates ASF code. The AL's permitted
applications are clear.
>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>>
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package. This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.
>>
>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts. If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
>
> Not that I believe that it will happen in the case of the JSecurity
> project but, does this not mean that the "original" project can continue
> for a potentially long time to develop their own releases off of the ASF
> repo? That's ok?
"off the asf". I presume you aren't talking about ASF tags. But there's
no reason someone can't use the ASF code under the AL at any given point
in time.
> What if the license for those releases was incompatible w/ AL2.0? They
> could continue to make releases on their own?
The license is AL. It can be packaged in any way that is compatible with
the AL. Whatever license, it must not violate the AL.
> What if there was absolutely no community involvement for those branches
> and their releases?
What release? We aren't talking about the ASF.
> What happens to that code base when the project graduates? I imagine
> that it would probably have to stay.
Huh? Which code base, where, and why would you imagine that?
There's ASF code. There is other people's code. We care about the code
and releases from the ASF. How others use it is their prerogative and
liability.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Roland Weber <os...@dubioso.net>.
Hi Craig,
> You have lost me here. Are you saying that the supposed license
> contradicts the patent grants in the Apache license, which are
> explicitly mentioned by the required notices?
>
> Has this ever happened, or are we in hypothetical-land?
Alan asked a what-if question, so we are safely within
hypothetical-land. Based on some stuff that I read on
legal-discuss (but won't bother to look up now), I believe
that the FSF believes that GPL 2.0 is incompatible
with AL 2.0, while some ASFers believe that the FSF is
in error on this point.
http://www.gnu.org/philosophy/license-list.html#AGPLv3.0
http://www.apache.org/licenses/GPL-compatibility.html
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Roland,
On Jul 28, 2008, at 12:49 AM, Roland Weber wrote:
> Hi Craig,
>
> Craig L Russell wrote:
>> [craig] I think I got the attribution correct in this. Please
>> correct if I got it wrong.
>
> You got it right (I think :-).
Whew!
>
>
>>> [roland]Yes, and why shouldn't it be? Anybody can pull Apache
>>> sources from
>>> our public SVN repo and make releases with or without modifications
>>> under any license that is compatible with the AL 2.0.
>> [craig]This is a misunderstanding. The Apache license is very
>> liberal. You can do pretty much anything you like with stuff you
>> pull from the Apache site *except* call it an Apache release or
>> remove notices.
>
> IIRC, the AL has a patent termination clause. The AL requires that
> the documentation of the redistributen says "contains software
> developed by the ASF" (that's not the exact wording here). If sb
> wants to redistribute AL code under a license that does not honor
> the patent termination clause, or that negates the ASF attribution
> requirement, there is a problem.
You have lost me here. Are you saying that the supposed license
contradicts the patent grants in the Apache license, which are
explicitly mentioned by the required notices?
Has this ever happened, or are we in hypothetical-land?
> That's what I am referring to with
> "compatible license". "Pretty much anything" means "not everything",
> and "compatible" means that you don't leave the "pretty much" area.
>
>
>>>> [alan]What if the license for those releases was incompatible w/
>>>> AL2.0?
>>>
>>> [roland]That would be a show stopper.
>> [craig]No, it's not a showstopper.
>
> You noticed the "incompatible" in the question?
> Not "different", but "incompatible".
As long as you preserve the notices in the AL2.0, you can relicense
stuff you get from Apache releases. So we don't focus on the term
"incompatible" with regard to stuff leaving Apache, but with stuff
entering Apache.
Maybe you can give an example of a license that is incompatible with
AL2.0 in the context of a downstream user/distributor of Apache stuff?
Craig
>
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Roland,
On Jul 28, 2008, at 12:49 AM, Roland Weber wrote:
> Hi Craig,
>
> Craig L Russell wrote:
>> [craig] I think I got the attribution correct in this. Please
>> correct if I got it wrong.
>
> You got it right (I think :-).
Whew!
>
>
>>> [roland]Yes, and why shouldn't it be? Anybody can pull Apache
>>> sources from
>>> our public SVN repo and make releases with or without modifications
>>> under any license that is compatible with the AL 2.0.
>> [craig]This is a misunderstanding. The Apache license is very
>> liberal. You can do pretty much anything you like with stuff you
>> pull from the Apache site *except* call it an Apache release or
>> remove notices.
>
> IIRC, the AL has a patent termination clause. The AL requires that
> the documentation of the redistributen says "contains software
> developed by the ASF" (that's not the exact wording here). If sb
> wants to redistribute AL code under a license that does not honor
> the patent termination clause, or that negates the ASF attribution
> requirement, there is a problem.
You have lost me here. Are you saying that the supposed license
contradicts the patent grants in the Apache license, which are
explicitly mentioned by the required notices?
Has this ever happened, or are we in hypothetical-land?
> That's what I am referring to with
> "compatible license". "Pretty much anything" means "not everything",
> and "compatible" means that you don't leave the "pretty much" area.
>
>
>>>> [alan]What if the license for those releases was incompatible w/
>>>> AL2.0?
>>>
>>> [roland]That would be a show stopper.
>> [craig]No, it's not a showstopper.
>
> You noticed the "incompatible" in the question?
> Not "different", but "incompatible".
As long as you preserve the notices in the AL2.0, you can relicense
stuff you get from Apache releases. So we don't focus on the term
"incompatible" with regard to stuff leaving Apache, but with stuff
entering Apache.
Maybe you can give an example of a license that is incompatible with
AL2.0 in the context of a downstream user/distributor of Apache stuff?
Craig
>
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Roland Weber <os...@dubioso.net>.
Hi Craig,
Craig L Russell wrote:
> [craig] I think I got the attribution correct in this. Please correct if
> I got it wrong.
You got it right (I think :-).
>> [roland]Yes, and why shouldn't it be? Anybody can pull Apache sources
>> from
>> our public SVN repo and make releases with or without modifications
>> under any license that is compatible with the AL 2.0.
>
> [craig]This is a misunderstanding. The Apache license is very liberal.
> You can do pretty much anything you like with stuff you pull from the
> Apache site *except* call it an Apache release or remove notices.
IIRC, the AL has a patent termination clause. The AL requires that
the documentation of the redistributen says "contains software
developed by the ASF" (that's not the exact wording here). If sb
wants to redistribute AL code under a license that does not honor
the patent termination clause, or that negates the ASF attribution
requirement, there is a problem. That's what I am referring to with
"compatible license". "Pretty much anything" means "not everything",
and "compatible" means that you don't leave the "pretty much" area.
>>> [alan]What if the license for those releases was incompatible w/ AL2.0?
>>
>> [roland]That would be a show stopper.
>
> [craig]No, it's not a showstopper.
You noticed the "incompatible" in the question?
Not "different", but "incompatible".
cheers,
Roland
Re: SVN move
Posted by Roland Weber <os...@dubioso.net>.
Hi Craig,
Craig L Russell wrote:
> [craig] I think I got the attribution correct in this. Please correct if
> I got it wrong.
You got it right (I think :-).
>> [roland]Yes, and why shouldn't it be? Anybody can pull Apache sources
>> from
>> our public SVN repo and make releases with or without modifications
>> under any license that is compatible with the AL 2.0.
>
> [craig]This is a misunderstanding. The Apache license is very liberal.
> You can do pretty much anything you like with stuff you pull from the
> Apache site *except* call it an Apache release or remove notices.
IIRC, the AL has a patent termination clause. The AL requires that
the documentation of the redistributen says "contains software
developed by the ASF" (that's not the exact wording here). If sb
wants to redistribute AL code under a license that does not honor
the patent termination clause, or that negates the ASF attribution
requirement, there is a problem. That's what I am referring to with
"compatible license". "Pretty much anything" means "not everything",
and "compatible" means that you don't leave the "pretty much" area.
>>> [alan]What if the license for those releases was incompatible w/ AL2.0?
>>
>> [roland]That would be a show stopper.
>
> [craig]No, it's not a showstopper.
You noticed the "incompatible" in the question?
Not "different", but "incompatible".
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
[craig] I think I got the attribution correct in this. Please correct
if I got it wrong.
On Jul 26, 2008, at 10:55 AM, Roland Weber wrote:
>>> [bill]The act of a tag-tar-vote-release at the ASF is an act of
>>> the foundation
>>> (as long as the RM/PMC follows the whole process) so it is a
>>> shield, of
>>> sorts. If the RM and project acts in good faith, the ASF backs the
>>> release and is a much more public face to settle any later disputes.
>> [alan]Not that I believe that it will happen in the case of the
>> JSecurity project but, does this not mean that the "original"
>> project can continue for a potentially long time to develop their
>> own releases off of the ASF repo? That's ok?
>
> [roland]Yes, and why shouldn't it be? Anybody can pull Apache
> sources from
> our public SVN repo and make releases with or without modifications
> under any license that is compatible with the AL 2.0.
[craig]This is a misunderstanding. The Apache license is very liberal.
You can do pretty much anything you like with stuff you pull from the
Apache site *except* call it an Apache release or remove notices.
[craig]You can take Apache code and relicense, redistribute,
repackage, and take it closed source if you like. But in order to call
it Apache you (the PMC) need to follow the Apache distribution rules.
> [roland]As long as they
> don't claim to do an Apache release. "Anybody" includes individuals
> that happen to be ASF committers.
>
>> [alan]What if the license for those releases was incompatible w/
>> AL2.0?
>
> [roland]That would be a show stopper. The code pulled from the ASF
> repo
> is licensed as AL 2.0 (with few exceptions), even if there are
> pre-Apache copies available under an incompatible license.
[craig]No, it's not a showstopper. See above. An Apache release is
covered by an Apache license. A non-Apache distribution of any kind is
not.
[craig] Redistribution of Apache-licensed code under a new license can
be tricky, since the license requires preserving the original notices.
There is a guide that many non-Apache projects use when relicensing
Apache code under a non-Apache license: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
>
>
> [roland]It is the responsibility of the people making the release to
> ensure that they obey all licensing requirements of the code
> they put into their release packages. The ASF has established
> processes to do that for Apache releases. How non-Apache
> releases are done is not our concern.
> [roland]If we learn about
> licensing violations, we will contact the responsible people
> to resolve the issue in good faith.
[craig]Generally, Apache complains about people removing notices from
code that they got from an Apache repository.
Craig
>
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 29, 2008, at 6:23 PM, Noel J. Bergman wrote:
>> Where I think that there is a problem is when they ditch their old
>> infrastructure and exclusively use ASF's infrastructure to build,
>> maintain, and release non-ASF releases. To be sure in the case of
>> JSecurity the final artifacts will not use the ASF mirrors but that
>> does not hide the fact that they intend to build and maintain non-
>> ASF
>> releases exclusively using our infrastructure.
>
> It should be fine to use our infrastructure to hold the source code,
> as long
> as we don't have license pollution issues. They cannot use it to do
> releases.
This seems at odds with what other incubating projects have done in
the past.
> Where do you see a problem with having a single source location?
I don't see a problem housing the history of the project at ASF. I
was concerned about non-ASF releases coming from our infrastructure.
I now know that this is common practice for incubating projects.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, 2008-07-31 at 11:49 +0800, Niclas Hedhman wrote:
> On Wednesday 30 July 2008 18:59, Upayavira wrote:
> > i.e. would it be acceptable to do a SourceForge release based upon code
> > in the ASF repository?
>
> Yes, you know that the license allows this. BUT it can't be called an Apache
> JSecurity release, nor should they portray it as such in correspondence and
> announcements from the Apache JSecurity community.
I agree, and yes, I do know this, but this is the point that seems to be
under question, which I was attempting to clarify.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 30 July 2008 18:59, Upayavira wrote:
> i.e. would it be acceptable to do a SourceForge release based upon code
> in the ASF repository?
Yes, you know that the license allows this. BUT it can't be called an Apache
JSecurity release, nor should they portray it as such in correspondence and
announcements from the Apache JSecurity community.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
Upayavira wrote:
> Noel J. Bergman wrote:
> > It should be fine to use our infrastructure to hold the source code, as
long
> > as we don't have license pollution issues. They cannot use it to do
> > releases.
> Can you clarify what you mean by 'releases'?
> They cannot use it to do ASF releases, or to do any releases at all?
I would have thought that clear from context. And, once again, this issue
has come up and been resolved in the past. This is hardly the first time to
the dance, and I don't recall too much angst over the prior resolutions.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by Upayavira <uv...@odoko.co.uk>.
On Tue, 2008-07-29 at 21:23 -0400, Noel J. Bergman wrote:
> > Where I think that there is a problem is when they ditch their old
> > infrastructure and exclusively use ASF's infrastructure to build,
> > maintain, and release non-ASF releases. To be sure in the case of
> > JSecurity the final artifacts will not use the ASF mirrors but that
> > does not hide the fact that they intend to build and maintain non-ASF
> > releases exclusively using our infrastructure.
>
> It should be fine to use our infrastructure to hold the source code, as long
> as we don't have license pollution issues. They cannot use it to do
> releases.
Can you clarify what you mean by 'releases'?
They cannot use it to do ASF releases, or to do any releases at all?
i.e. would it be acceptable to do a SourceForge release based upon code
in the ASF repository?
That is the clincher in this discussion.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 29, 2008, at 6:23 PM, Noel J. Bergman wrote:
>> Where I think that there is a problem is when they ditch their old
>> infrastructure and exclusively use ASF's infrastructure to build,
>> maintain, and release non-ASF releases. To be sure in the case of
>> JSecurity the final artifacts will not use the ASF mirrors but that
>> does not hide the fact that they intend to build and maintain non-
>> ASF
>> releases exclusively using our infrastructure.
>
> It should be fine to use our infrastructure to hold the source code,
> as long
> as we don't have license pollution issues. They cannot use it to do
> releases.
This seems at odds with what other incubating projects have done in
the past.
> Where do you see a problem with having a single source location?
I don't see a problem housing the history of the project at ASF. I
was concerned about non-ASF releases coming from our infrastructure.
I now know that this is common practice for incubating projects.
Regards,
Alan
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Where I think that there is a problem is when they ditch their old
> infrastructure and exclusively use ASF's infrastructure to build,
> maintain, and release non-ASF releases. To be sure in the case of
> JSecurity the final artifacts will not use the ASF mirrors but that
> does not hide the fact that they intend to build and maintain non-ASF
> releases exclusively using our infrastructure.
It should be fine to use our infrastructure to hold the source code, as long
as we don't have license pollution issues. They cannot use it to do
releases.
Where do you see a problem with having a single source location?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: SVN move
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Where I think that there is a problem is when they ditch their old
> infrastructure and exclusively use ASF's infrastructure to build,
> maintain, and release non-ASF releases. To be sure in the case of
> JSecurity the final artifacts will not use the ASF mirrors but that
> does not hide the fact that they intend to build and maintain non-ASF
> releases exclusively using our infrastructure.
It should be fine to use our infrastructure to hold the source code, as long
as we don't have license pollution issues. They cannot use it to do
releases.
Where do you see a problem with having a single source location?
--- Noel
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:55 AM, Roland Weber wrote:
> Hi Alan,
>
> see my 0.02€ below...
>
> Alan D. Cabrera wrote:
>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>> Alan D. Cabrera wrote:
>>>> 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.
>
> +1, except for the minimal restrictions stated in the AL 2.0.
>
>
>>>>> 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.
>
> The last sentence confused me a bit. Whether or not a code branch
> is maintained in the Apache repo does not depend on where exactly
> releases are published. Non-Apache releases are not published from
> Apache servers. Code can be maintained in the Apache repo without
> being Apache-released: sandboxes, experimental branches,...
I think people are missing the point that I am trying to make and
where Craig and I have different opinions.
I fully understand and support projects that are moving to the
incubator to support old versions for their community.
Where I think that there is a problem is when they ditch their old
infrastructure and exclusively use ASF's infrastructure to build,
maintain, and release non-ASF releases. To be sure in the case of
JSecurity the final artifacts will not use the ASF mirrors but that
does not hide the fact that they intend to build and maintain non-ASF
releases exclusively using our infrastructure.
Craig says that's fine.
I think that they should release and maintain their new and earlier
non-ASF releases on the infrastructure that they currently have or
else use ours and follow the ASF/Incubator guidelines.
Regards,
Alan
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 26, 2008, at 10:55 AM, Roland Weber wrote:
> Hi Alan,
>
> see my 0.02€ below...
>
> Alan D. Cabrera wrote:
>> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>>> Alan D. Cabrera wrote:
>>>> 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.
>
> +1, except for the minimal restrictions stated in the AL 2.0.
>
>
>>>>> 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.
>
> The last sentence confused me a bit. Whether or not a code branch
> is maintained in the Apache repo does not depend on where exactly
> releases are published. Non-Apache releases are not published from
> Apache servers. Code can be maintained in the Apache repo without
> being Apache-released: sandboxes, experimental branches,...
I think people are missing the point that I am trying to make and
where Craig and I have different opinions.
I fully understand and support projects that are moving to the
incubator to support old versions for their community.
Where I think that there is a problem is when they ditch their old
infrastructure and exclusively use ASF's infrastructure to build,
maintain, and release non-ASF releases. To be sure in the case of
JSecurity the final artifacts will not use the ASF mirrors but that
does not hide the fact that they intend to build and maintain non-ASF
releases exclusively using our infrastructure.
Craig says that's fine.
I think that they should release and maintain their new and earlier
non-ASF releases on the infrastructure that they currently have or
else use ours and follow the ASF/Incubator guidelines.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
[craig] I think I got the attribution correct in this. Please correct
if I got it wrong.
On Jul 26, 2008, at 10:55 AM, Roland Weber wrote:
>>> [bill]The act of a tag-tar-vote-release at the ASF is an act of
>>> the foundation
>>> (as long as the RM/PMC follows the whole process) so it is a
>>> shield, of
>>> sorts. If the RM and project acts in good faith, the ASF backs the
>>> release and is a much more public face to settle any later disputes.
>> [alan]Not that I believe that it will happen in the case of the
>> JSecurity project but, does this not mean that the "original"
>> project can continue for a potentially long time to develop their
>> own releases off of the ASF repo? That's ok?
>
> [roland]Yes, and why shouldn't it be? Anybody can pull Apache
> sources from
> our public SVN repo and make releases with or without modifications
> under any license that is compatible with the AL 2.0.
[craig]This is a misunderstanding. The Apache license is very liberal.
You can do pretty much anything you like with stuff you pull from the
Apache site *except* call it an Apache release or remove notices.
[craig]You can take Apache code and relicense, redistribute,
repackage, and take it closed source if you like. But in order to call
it Apache you (the PMC) need to follow the Apache distribution rules.
> [roland]As long as they
> don't claim to do an Apache release. "Anybody" includes individuals
> that happen to be ASF committers.
>
>> [alan]What if the license for those releases was incompatible w/
>> AL2.0?
>
> [roland]That would be a show stopper. The code pulled from the ASF
> repo
> is licensed as AL 2.0 (with few exceptions), even if there are
> pre-Apache copies available under an incompatible license.
[craig]No, it's not a showstopper. See above. An Apache release is
covered by an Apache license. A non-Apache distribution of any kind is
not.
[craig] Redistribution of Apache-licensed code under a new license can
be tricky, since the license requires preserving the original notices.
There is a guide that many non-Apache projects use when relicensing
Apache code under a non-Apache license: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
>
>
> [roland]It is the responsibility of the people making the release to
> ensure that they obey all licensing requirements of the code
> they put into their release packages. The ASF has established
> processes to do that for Apache releases. How non-Apache
> releases are done is not our concern.
> [roland]If we learn about
> licensing violations, we will contact the responsible people
> to resolve the issue in good faith.
[craig]Generally, Apache complains about people removing notices from
code that they got from an Apache repository.
Craig
>
>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Roland Weber <os...@dubioso.net>.
Hi Alan,
see my 0.02€ below...
Alan D. Cabrera wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>> 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.
+1, except for the minimal restrictions stated in the AL 2.0.
>>>> 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.
The last sentence confused me a bit. Whether or not a code branch
is maintained in the Apache repo does not depend on where exactly
releases are published. Non-Apache releases are not published from
Apache servers. Code can be maintained in the Apache repo without
being Apache-released: sandboxes, experimental branches,...
>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>>
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package. This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.
s/committer/individual/
It's not an Apache release, so it doesn't matter what
Apache hats the individual(s) could wear around here.
>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts. If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
>
> Not that I believe that it will happen in the case of the JSecurity
> project but, does this not mean that the "original" project can continue
> for a potentially long time to develop their own releases off of the ASF
> repo? That's ok?
Yes, and why shouldn't it be? Anybody can pull Apache sources from
our public SVN repo and make releases with or without modifications
under any license that is compatible with the AL 2.0. As long as they
don't claim to do an Apache release. "Anybody" includes individuals
that happen to be ASF committers.
> What if the license for those releases was incompatible w/ AL2.0?
That would be a show stopper. The code pulled from the ASF repo
is licensed as AL 2.0 (with few exceptions), even if there are
pre-Apache copies available under an incompatible license.
It is the responsibility of the people making the release to
ensure that they obey all licensing requirements of the code
they put into their release packages. The ASF has established
processes to do that for Apache releases. How non-Apache
releases are done is not our concern. If we learn about
licensing violations, we will contact the responsible people
to resolve the issue in good faith.
> What if there was absolutely no community involvement for those branches
> and their releases?
Only Apache committers can create branches in the Apache repo.
This is typically done for Apache releases and not for anybody
outside who wants to do a non-Apache release. But in the end,
it is the decision of the (P)PMC whether to branch code or not.
In your real case, I don't see a problem. In your hypothetical
case, I'd say that the PMC shouldn't allow a new branch.
That doesn't prevent anyone from pulling a specific revision
out of the Apache repo and making a non-Apache release off that.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Alan D. Cabrera wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>> 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?
>> Of course.
>
> Can you provide one example? Just curious.
Try any project or product that integrates ASF code. The AL's permitted
applications are clear.
>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>>
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package. This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.
>>
>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts. If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
>
> Not that I believe that it will happen in the case of the JSecurity
> project but, does this not mean that the "original" project can continue
> for a potentially long time to develop their own releases off of the ASF
> repo? That's ok?
"off the asf". I presume you aren't talking about ASF tags. But there's
no reason someone can't use the ASF code under the AL at any given point
in time.
> What if the license for those releases was incompatible w/ AL2.0? They
> could continue to make releases on their own?
The license is AL. It can be packaged in any way that is compatible with
the AL. Whatever license, it must not violate the AL.
> What if there was absolutely no community involvement for those branches
> and their releases?
What release? We aren't talking about the ASF.
> What happens to that code base when the project graduates? I imagine
> that it would probably have to stay.
Huh? Which code base, where, and why would you imagine that?
There's ASF code. There is other people's code. We care about the code
and releases from the ASF. How others use it is their prerogative and
liability.
Re: SVN move
Posted by Roland Weber <os...@dubioso.net>.
Hi Alan,
see my 0.02€ below...
Alan D. Cabrera wrote:
>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>> 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.
+1, except for the minimal restrictions stated in the AL 2.0.
>>>> 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.
The last sentence confused me a bit. Whether or not a code branch
is maintained in the Apache repo does not depend on where exactly
releases are published. Non-Apache releases are not published from
Apache servers. Code can be maintained in the Apache repo without
being Apache-released: sandboxes, experimental branches,...
>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>>
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package. This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.
s/committer/individual/
It's not an Apache release, so it doesn't matter what
Apache hats the individual(s) could wear around here.
>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts. If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
>
> Not that I believe that it will happen in the case of the JSecurity
> project but, does this not mean that the "original" project can continue
> for a potentially long time to develop their own releases off of the ASF
> repo? That's ok?
Yes, and why shouldn't it be? Anybody can pull Apache sources from
our public SVN repo and make releases with or without modifications
under any license that is compatible with the AL 2.0. As long as they
don't claim to do an Apache release. "Anybody" includes individuals
that happen to be ASF committers.
> What if the license for those releases was incompatible w/ AL2.0?
That would be a show stopper. The code pulled from the ASF repo
is licensed as AL 2.0 (with few exceptions), even if there are
pre-Apache copies available under an incompatible license.
It is the responsibility of the people making the release to
ensure that they obey all licensing requirements of the code
they put into their release packages. The ASF has established
processes to do that for Apache releases. How non-Apache
releases are done is not our concern. If we learn about
licensing violations, we will contact the responsible people
to resolve the issue in good faith.
> What if there was absolutely no community involvement for those branches
> and their releases?
Only Apache committers can create branches in the Apache repo.
This is typically done for Apache releases and not for anybody
outside who wants to do a non-Apache release. But in the end,
it is the decision of the (P)PMC whether to branch code or not.
In your real case, I don't see a problem. In your hypothetical
case, I'd say that the PMC shouldn't allow a new branch.
That doesn't prevent anyone from pulling a specific revision
out of the Apache repo and making a non-Apache release off that.
hope that helps,
Roland
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
> Alan D. Cabrera wrote:
>> 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?
>
> Of course.
Can you provide one example? Just curious.
> Understand that it's not Apache Foo x.x.x, and that the ASF
> doesn't publish or take account for the contents of such an external
> package.
>
> Which effectively means the committer (or their employer if they are
> acting on the behalf of such) is assuming all responsibilities for
> such
> a package. This is usually not the sort of personal responsibility an
> individual desires, so it would probably make more sense to resolve
> the
> issues at the project and vote on an ASF release.
>
> The act of a tag-tar-vote-release at the ASF is an act of the
> foundation
> (as long as the RM/PMC follows the whole process) so it is a shield,
> of
> sorts. If the RM and project acts in good faith, the ASF backs the
> release and is a much more public face to settle any later disputes.
Not that I believe that it will happen in the case of the JSecurity
project but, does this not mean that the "original" project can
continue for a potentially long time to develop their own releases off
of the ASF repo? That's ok?
What if the license for those releases was incompatible w/ AL2.0? They
could continue to make releases on their own?
What if there was absolutely no community involvement for those
branches and their releases?
What happens to that code base when the project graduates? I imagine
that it would probably have to stay.
Again, I don't think this will occur for JSecurity but I am just
trying to get my head in the same place a s you guys.
Regards,
Alan
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
> Alan D. Cabrera wrote:
>> 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?
>
> Of course.
Can you provide one example? Just curious.
> Understand that it's not Apache Foo x.x.x, and that the ASF
> doesn't publish or take account for the contents of such an external
> package.
>
> Which effectively means the committer (or their employer if they are
> acting on the behalf of such) is assuming all responsibilities for
> such
> a package. This is usually not the sort of personal responsibility an
> individual desires, so it would probably make more sense to resolve
> the
> issues at the project and vote on an ASF release.
>
> The act of a tag-tar-vote-release at the ASF is an act of the
> foundation
> (as long as the RM/PMC follows the whole process) so it is a shield,
> of
> sorts. If the RM and project acts in good faith, the ASF backs the
> release and is a much more public face to settle any later disputes.
Not that I believe that it will happen in the case of the JSecurity
project but, does this not mean that the "original" project can
continue for a potentially long time to develop their own releases off
of the ASF repo? That's ok?
What if the license for those releases was incompatible w/ AL2.0? They
could continue to make releases on their own?
What if there was absolutely no community involvement for those
branches and their releases?
What happens to that code base when the project graduates? I imagine
that it would probably have to stay.
Again, I don't think this will occur for JSecurity but I am just
trying to get my head in the same place a s you guys.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Alan D. Cabrera wrote:
>
> 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?
Of course. Understand that it's not Apache Foo x.x.x, and that the ASF
doesn't publish or take account for the contents of such an external
package.
Which effectively means the committer (or their employer if they are
acting on the behalf of such) is assuming all responsibilities for such
a package. This is usually not the sort of personal responsibility an
individual desires, so it would probably make more sense to resolve the
issues at the project and vote on an ASF release.
The act of a tag-tar-vote-release at the ASF is an act of the foundation
(as long as the RM/PMC follows the whole process) so it is a shield, of
sorts. If the RM and project acts in good faith, the ASF backs the
release and is a much more public face to settle any later disputes.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Alan D. Cabrera wrote:
>
> 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?
Of course. Understand that it's not Apache Foo x.x.x, and that the ASF
doesn't publish or take account for the contents of such an external
package.
Which effectively means the committer (or their employer if they are
acting on the behalf of such) is assuming all responsibilities for such
a package. This is usually not the sort of personal responsibility an
individual desires, so it would probably make more sense to resolve the
issues at the project and vote on an ASF release.
The act of a tag-tar-vote-release at the ASF is an act of the foundation
(as long as the RM/PMC follows the whole process) so it is a shield, of
sorts. If the RM and project acts in good faith, the ASF backs the
release and is a much more public face to settle any later disputes.
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <list@toolazydogs.com
>>> >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 <Craig.Russell@sun.com
>>>>>>> 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 <
>>>>>>>> list@toolazydogs.com
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> list@toolazydogs.com
>>>>>>>>>>
>>>>>>>>>> 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:Craig.Russell@sun.com
>>>>>>> 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:Craig.Russell@sun.com
>>>>> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <list@toolazydogs.com
>>> >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 <Craig.Russell@sun.com
>>>>>>> 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 <
>>>>>>>> list@toolazydogs.com
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> list@toolazydogs.com
>>>>>>>>>>
>>>>>>>>>> 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:Craig.Russell@sun.com
>>>>>>> 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:Craig.Russell@sun.com
>>>>> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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.
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 <list@toolazydogs.com
>> >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 <Craig.Russell@sun.com
>>>>>> 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 <
>>>>>>> list@toolazydogs.com
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>> list@toolazydogs.com
>>>>>>>>>
>>>>>>>>> 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:Craig.Russell@sun.com
>>>>>> 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:Craig.Russell@sun.com
>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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.
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 <list@toolazydogs.com
>> >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 <Craig.Russell@sun.com
>>>>>> 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 <
>>>>>>> list@toolazydogs.com
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>> list@toolazydogs.com
>>>>>>>>>
>>>>>>>>> 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:Craig.Russell@sun.com
>>>>>> 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:Craig.Russell@sun.com
>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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.
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
> <li...@toolazydogs.com>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 <Craig.Russell@sun.com
>>>>> 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 <
>>>>>> list@toolazydogs.com
>>>>>>
>>>>>>> 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 <
>>>>>>>> list@toolazydogs.com
>>>>>>>>
>>>>>>>> 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:Craig.Russell@sun.com
>>>>> 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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
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.
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.
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.
On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera <li...@toolazydogs.com>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 <Craig.Russell@sun.com
>>> >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 <
>>>>> list@toolazydogs.com
>>>>>
>>>>>> 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 <
>>>>>>> list@toolazydogs.com
>>>>>>>
>>>>>>> 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:Craig.Russell@sun.com
>>>> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <Craig.Russell@sun.com
>> >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 <list@toolazydogs.com
>>>>> 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 <list@toolazydogs.com
>>>>>>
>>>>>>> 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:Craig.Russell@sun.com
>>> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Craig.Russell@sun.com
> >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 <list@toolazydogs.com
>>>> 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 <list@toolazydogs.com
>>>>>
>>>>>> 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:Craig.Russell@sun.com
>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Yeah, we should be able to move things around once it's imported. I
imagine that it would initially get tagged as "import" with work
continuing on in trunk.
Regards,
Alan
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 <Craig.Russell@sun.com
> >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 <list@toolazydogs.com
>>>> 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 <list@toolazydogs.com
>>>>>
>>>>>> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
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 <Cr...@sun.com>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 <list@toolazydogs.com
>> >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 <list@toolazydogs.com
>>>>
>>>>> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: SVN move
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <list@toolazydogs.com
> >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 <list@toolazydogs.com
>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
It turns out 'svnsync' is the appropriate way to do this. I'll open an
issue ticket for them now. I'm disabling SVN commit access to the current
repo (read access still allowed of course).
On Fri, Jul 25, 2008 at 11:43 AM, Les Hazlewood <le...@hazlewood.com> 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 <li...@toolazydogs.com>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 <list@toolazydogs.com
>>> >wrote:
>>>
>>> Les, have you been able to make your SVN dump yet? When can we expect
>>>> this?
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>>
>>
>
Re: SVN move
Posted by Les Hazlewood <le...@hazlewood.com>.
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 <li...@toolazydogs.com>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 <list@toolazydogs.com
>> >wrote:
>>
>> Les, have you been able to make your SVN dump yet? When can we expect
>>> this?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>>
>
Re: SVN move
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <list@toolazydogs.com
> >wrote:
>
>> Les, have you been able to make your SVN dump yet? When can we
>> expect
>> this?
>>
>>
>> Regards,
>> Alan
>>
>>
Re: SVN move
Posted by Les Hazlewood <lh...@apache.org>.
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 <li...@toolazydogs.com>wrote:
> Les, have you been able to make your SVN dump yet? When can we expect
> this?
>
>
> Regards,
> Alan
>
>