You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-dev@incubator.apache.org by Brett Porter <br...@apache.org> on 2010/09/08 12:50:05 UTC

cleaning up tags/releases

Hi,

Now that we have the code imported as it was in Codeplex, we can actually see the tags and releases directories again :)

For background, the releases moved to /releases/ earlier in the year when tagging to /tags/ started failing without reason (and we were unable to view it in the browser, check it out, etc., even though we knew they were there).

I'd like to propose doing the following:
- removing all "RC" tags from either location
- moving the real tags in /releases/ back to /tags/ and removing /releases/ (and likewise for npanday-its).
- set /tags/ as the location to use going forward.

The code & POMs (which still refer to codeplex anyway) would be left as is - so changing the location shouldn't impact them. It just gives a more compact view of the actual releases, and a unified place for going forward.

Thoughts? Anyone know what impact all this has on git mirrors? (I know some committers are interested in having that set up for the new repo)

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





Re: cleaning up tags/releases

Posted by Dennis Lundberg <de...@apache.org>.
+1 Best to use the standard SVN layout

On 2010-09-08 14:50, Brett Porter wrote:
> Hi,
> 
> Now that we have the code imported as it was in Codeplex, we can actually see the tags and releases directories again :)
> 
> For background, the releases moved to /releases/ earlier in the year when tagging to /tags/ started failing without reason (and we were unable to view it in the browser, check it out, etc., even though we knew they were there).
> 
> I'd like to propose doing the following:
> - removing all "RC" tags from either location
> - moving the real tags in /releases/ back to /tags/ and removing /releases/ (and likewise for npanday-its).
> - set /tags/ as the location to use going forward.
> 
> The code & POMs (which still refer to codeplex anyway) would be left as is - so changing the location shouldn't impact them. It just gives a more compact view of the actual releases, and a unified place for going forward.
> 
> Thoughts? Anyone know what impact all this has on git mirrors? (I know some committers are interested in having that set up for the new repo)
> 
> Cheers,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

Re: cleaning up tags/releases

Posted by Craig <su...@gmail.com>.
+1

On Wed, Sep 8, 2010 at 10:50 PM, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Now that we have the code imported as it was in Codeplex, we can actually see the tags and releases directories again :)
>
> For background, the releases moved to /releases/ earlier in the year when tagging to /tags/ started failing without reason (and we were unable to view it in the browser, check it out, etc., even though we knew they were there).
>
> I'd like to propose doing the following:
> - removing all "RC" tags from either location
> - moving the real tags in /releases/ back to /tags/ and removing /releases/ (and likewise for npanday-its).
> - set /tags/ as the location to use going forward.
>
> The code & POMs (which still refer to codeplex anyway) would be left as is - so changing the location shouldn't impact them. It just gives a more compact view of the actual releases, and a unified place for going forward.
>
> Thoughts? Anyone know what impact all this has on git mirrors? (I know some committers are interested in having that set up for the new repo)
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>

Re: cleaning up tags/releases

Posted by Liit Padilla <ap...@maestrodev.com>.
+ 1 on cleaning tags/releases

On 9/9/2010 7:25 AM, Josimpson Ocaba wrote:
> ----- "Brett Porter"<br...@apache.org>  wrote:
>
>    
>> Hi,
>>
>> Now that we have the code imported as it was in Codeplex, we can
>> actually see the tags and releases directories again :)
>>
>> For background, the releases moved to /releases/ earlier in the year
>> when tagging to /tags/ started failing without reason (and we were
>> unable to view it in the browser, check it out, etc., even though we
>> knew they were there).
>>
>> I'd like to propose doing the following:
>> - removing all "RC" tags from either location
>> - moving the real tags in /releases/ back to /tags/ and removing
>> /releases/ (and likewise for npanday-its).
>> - set /tags/ as the location to use going forward.
>>
>> The code&  POMs (which still refer to codeplex anyway) would be left
>> as is - so changing the location shouldn't impact them. It just gives
>> a more compact view of the actual releases, and a unified place for
>> going forward.
>>
>> Thoughts? Anyone know what impact all this has on git mirrors? (I know
>> some committers are interested in having that set up for the new
>> repo)
>>      
> +1 on the cleaning and sorting out between tags and releases.
>
>
>
>    
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>>      


Re: cleaning up tags/releases

Posted by Josimpson Ocaba <jo...@maestrodev.com>.
----- "Brett Porter" <br...@apache.org> wrote:

> Hi,
> 
> Now that we have the code imported as it was in Codeplex, we can
> actually see the tags and releases directories again :)
> 
> For background, the releases moved to /releases/ earlier in the year
> when tagging to /tags/ started failing without reason (and we were
> unable to view it in the browser, check it out, etc., even though we
> knew they were there).
> 
> I'd like to propose doing the following:
> - removing all "RC" tags from either location
> - moving the real tags in /releases/ back to /tags/ and removing
> /releases/ (and likewise for npanday-its).
> - set /tags/ as the location to use going forward.
> 
> The code & POMs (which still refer to codeplex anyway) would be left
> as is - so changing the location shouldn't impact them. It just gives
> a more compact view of the actual releases, and a unified place for
> going forward.
> 
> Thoughts? Anyone know what impact all this has on git mirrors? (I know
> some committers are interested in having that set up for the new
> repo)

+1 on the cleaning and sorting out between tags and releases.


 
> Cheers,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/