Re: Importing packages into CVS

On Tue, Mar 27, 2007 at 05:23:16PM -0700, Joshua Eichorn
wrote:

> >>>Do you want it to be hosted on cvs.php.net
as a reference resource?
> >>>The code will never be current, and the
active external repository can
> >>>already be used as a reference.
> >>>      
> My point is that this is solvable.

It is only really solvable, using CVS, in a way in which
the
cvs.php.net version should be considered read-only.

> >>>Do yo want to allow PEAR QA folks to commit
changes to a package's
> >>>code?  The code will become forked from the
active development line.
> >>>      
> Commiting to a fork could be a reasonable short term
solution if the 
> maintainer wasn't available for whatever reason, and an
emergency bug 
> fix was needed.

While this is a valid case, I think it's exceptionally rare.
 If this
is the only true reason to mirror copies of active code on
cvs.php.net,
I don't think it's worth the effort.

> >>>Do you want to archive a historic copy of
the code, perhaps on a
> >>>per-release basis?  pear.php.net already
has a copy of the source code
> >>>on a per-release basis.
> >>>      
> This code is available in the tarballs but not easily
accessible since 
> its all compressed, and has no tools associated with
it.
> 
> I think the biggest benefit is allowing for easy access
to all the code 
> by QA scripts.
 
I'm inclined to disagree with this, as well.  Sure, it's
nice for QA
to 'cvs checkout pear/' to get all possible PEAR source
code, but they
could also use a system that does:

    for package in allPackages:
        extractPackageArchive()
        results += analyzePackage()
        cleanupPackage()

-- 
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On Tue, 27 Mar 2007 20:50:30 -0400, Jon Parise wrote:

>> >>>Do yo want to allow PEAR QA folks to
commit changes to a package's
>> >>>code?  The code will become forked from
the active development line.
>> >>>      
>> Commiting to a fork could be a reasonable short
term solution if the
>> maintainer wasn't available for whatever reason,
and an emergency bug
>> fix was needed.
> 
> While this is a valid case, I think it's exceptionally
rare.  If this is
> the only true reason to mirror copies of active code on
cvs.php.net, I
> don't think it's worth the effort.

If that ever happens then QA can import the package from a
release and 
apply patches and do a release that way.

>> >>>Do you want to archive a historic copy
of the code, perhaps on a
>> >>>per-release basis?  pear.php.net
already has a copy of the source
>> >>>code on a per-release basis.
>> >>>      
>> This code is available in the tarballs but not
easily accessible since
>> its all compressed, and has no tools associated
with it.
>> 
>> I think the biggest benefit is allowing for easy
access to all the code
>> by QA scripts.
>  
> I'm inclined to disagree with this, as well.  Sure,
it's nice for QA to
> 'cvs checkout pear/' to get all possible PEAR source
code, but they
> could also use a system that does:
> 
>     for package in allPackages:
>         extractPackageArchive()
>         results += analyzePackage()
>         cleanupPackage()

QA shouldn't really be checking cvs unless the maintainer
asks them, else 
just test releases, if there ever will be a QA auto rcs
checker then it 
will just checkout from all relevant repos since it is a
requirement to 
have a web/cli accessible repo if you want to be outside of
the php cvs, 
shouldn't be hard to manage the info for each package if it
comes to that.

- Helgi

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php