Re: Importing packages into CVS

Alexey Borzov wrote:

> My suggestion is to give a developer some limited time
for pulling the
> release (like a week, two weeks at most) since the
problems warranting
> said pull are usually quite obvious. And let's remove
that "Delete"
> button except for the packages that don't yet have any
releases. Our
> main goal is to ensure that whatever was released via
PEAR stays there.
> 
> Of course deleting the packages will still be possible
with the help of
> the admin, but I hope our admins learned that lesson
already. 
> 
> So what I propose is writing guidelines for deleting
packages / releases
> and making changes to pearweb to enforce these.

These are *excellent* suggestions.  Would you mind writing
up a draft
for guidelines?  I would like to see this implemented very
soon.

> cvs.php.net may be of some help, but consider the
wonders of "cvs admin
> -o" command. A person *really* dedicated to taking
his ball and going
> home can use this as a nice addition to clicking that
"Delete" buttons.

Let it be said right now that any individual who performs
this command
will incur the wrath of not just me, but the entire PHP
project, and I
will personally see to it that this individual is
permanently banned
from ever again participating in development of PECL, PEAR,
or the core
of PHP.  This action is the equivalent of dropping a nuclear
bomb on the
server, and it is the only mortal sin of PHP.

>> One solution is to save a copy of all deleted
releases "just in case."
>> This is impractical for many reasons, but if any of
you have a better
>> suggestion I would love to hear it.
>>
>> As for orphaned packages, this is far simpler: if
the package is not
>> maintained, and the RCS is external or
non-existent, there is no other
>> alternative, development is essentially over unless
it is imported into
>> cvs.php.net.
> 
> Well, I think you are putting a proverbial cart before
the horse here.
> If a person comes up wishing to restart development, it
is up to him
> whether to import into PEAR CVS or some other SCM (I
tend to agree with
> Helgi's view on requirements for such SCM).
> 
> The same goes for QA releases, find the QA engineer
first, then he
> imports the code to PHP CVS.

In this case, Christian Weiske is the horse in your
proverbial analogy
, as
he is both the QA engineer and the person wishing to
restart
development.

At this moment, PEAR has an open bug count of 377 bugs, the
lowest it
has been since recording open bugs began 2 years ago.  This
is directly
due to Christian's work and if I might take some credit, I
believe also
due to the bug statistics rankings per package, as we were
hovering at
around 500 bugs before the statistics were put in place. 
(So keep up
the good work folks)

Are we cool?  Do the Horde folks and everyone feel their
needs are
addressed?

Greg

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

Quoting Greg Beaver <gregchiaraquartet.net>:

>> My suggestion is to give a developer some limited
time for pulling the
>> release (like a week, two weeks at most) since the
problems warranting
>> said pull are usually quite obvious. And let's
remove that "Delete"
>> button except for the packages that don't yet have
any releases. Our
>> main goal is to ensure that whatever was released
via PEAR stays there.
>>
>> Of course deleting the packages will still be
possible with the help of
>> the admin, but I hope our admins learned that
lesson already. 
>>
>> So what I propose is writing guidelines for
deleting packages / releases
>> and making changes to pearweb to enforce these.
>
> These are *excellent* suggestions.  Would you mind
writing up a draft
> for guidelines?  I would like to see this implemented
very soon.

That all sounds reasonable to me.

> In this case, Christian Weiske is the horse in your
proverbial analogy
> ,
as he is both the QA engineer and the person wishing to
restart
> development.

[deletia]

> Are we cool?  Do the Horde folks and everyone feel
their needs are
> addressed?

So the specific orphaned package(s) in question will be
imported, but  
otherwise the changes that will be implemented are the ones
about  
pulling releases described above? Sounds good to me.

Best,
-chuck

-- 
"we are plastered to the windshield of the bus that is
time." - Chris

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

On Thu, 29 Mar 2007 13:06:56 -0400, Greg Beaver wrote:

> Alexey Borzov wrote:
> 
>> My suggestion is to give a developer some limited
time for pulling the
>> release (like a week, two weeks at most) since the
problems warranting
>> said pull are usually quite obvious. And let's
remove that "Delete"
>> button except for the packages that don't yet have
any releases. Our
>> main goal is to ensure that whatever was released
via PEAR stays there.
>> 
>> Of course deleting the packages will still be
possible with the help of
>> the admin, but I hope our admins learned that
lesson already. 
>> 
>> So what I propose is writing guidelines for
deleting packages /
>> releases and making changes to pearweb to enforce
these.
> 
> These are *excellent* suggestions.  Would you mind
writing up a draft
> for guidelines?  I would like to see this implemented
very soon.
> 
>> cvs.php.net may be of some help, but consider the
wonders of "cvs admin
>> -o" command. A person *really* dedicated to
taking his ball and going
>> home can use this as a nice addition to clicking
that "Delete" buttons.
> 
> Let it be said right now that any individual who
performs this command
> will incur the wrath of not just me, but the entire PHP
project, and I
> will personally see to it that this individual is
permanently banned
> from ever again participating in development of PECL,
PEAR, or the core
> of PHP.  This action is the equivalent of dropping a
nuclear bomb on the
> server, and it is the only mortal sin of PHP.
> 
>>> One solution is to save a copy of all deleted
releases "just in case."
>>> This is impractical for many reasons, but if
any of you have a better
>>> suggestion I would love to hear it.
>>>
>>> As for orphaned packages, this is far simpler:
if the package is not
>>> maintained, and the RCS is external or
non-existent, there is no other
>>> alternative, development is essentially over
unless it is imported
>>> into cvs.php.net.
>> 
>> Well, I think you are putting a proverbial cart
before the horse here.
>> If a person comes up wishing to restart
development, it is up to him
>> whether to import into PEAR CVS or some other SCM
(I tend to agree with
>> Helgi's view on requirements for such SCM).
>> 
>> The same goes for QA releases, find the QA engineer
first, then he
>> imports the code to PHP CVS.
> 
> In this case, Christian Weiske is the horse in your
proverbial analogy
> ,
as he is both the QA engineer and the person wishing to
restart
> development.
> 
> At this moment, PEAR has an open bug count of 377 bugs,
the lowest it
> has been since recording open bugs began 2 years ago. 
This is directly
> due to Christian's work and if I might take some
credit, I believe also
> due to the bug statistics rankings per package, as we
were hovering at
> around 500 bugs before the statistics were put in
place.  (So keep up
> the good work folks)

Well it's good seeing that Christian resumed the work I did
back in the 
days, I don't know how many hours I spent weeding through
the bug list, 
bug fixing some old ones, CS fixes, etc etc etc. the thought
of it gives 
me nightmares ;)

Regards
Helgi

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

Hi,

Greg Beaver wrote:
>> My suggestion is to give a developer some limited
time for pulling the
>> release (like a week, two weeks at most) since the
problems warranting
>> said pull are usually quite obvious. And let's
remove that "Delete"
>> button except for the packages that don't yet have
any releases. Our
>> main goal is to ensure that whatever was released
via PEAR stays there.
>>
>> Of course deleting the packages will still be
possible with the help of
>> the admin, but I hope our admins learned that
lesson already. 
>>
>> So what I propose is writing guidelines for
deleting packages / releases
>> and making changes to pearweb to enforce these.
> 
> These are *excellent* suggestions.  Would you mind
writing up a draft
> for guidelines?  I would like to see this implemented
very soon.

Yes, I'll do the draft. Should I create an RFC or a post to
pear-dev is sufficient?

>> Well, I think you are putting a proverbial cart
before the horse here.
>> If a person comes up wishing to restart
development, it is up to him
>> whether to import into PEAR CVS or some other SCM
(I tend to agree with
>> Helgi's view on requirements for such SCM).
>>
>> The same goes for QA releases, find the QA engineer
first, then he
>> imports the code to PHP CVS.
> 
> In this case, Christian Weiske is the horse in your
proverbial analogy
> ,
as he is both the QA engineer and the person wishing to
restart
> development.
> 
> At this moment, PEAR has an open bug count of 377 bugs,
the lowest it
> has been since recording open bugs began 2 years ago. 
This is directly
> due to Christian's work and if I might take some
credit, I believe also
> due to the bug statistics rankings per package, as we
were hovering at
> around 500 bugs before the statistics were put in
place.  (So keep up
> the good work folks)

Well, kudos to Christian for his work, it does help PEAR's
image quite a bit!

Although I doubt that even Christian is some kind of
superhero able to work on 
all packages at once. ;] Thus my suggestion on importing the
packages to CVS 
only when some actual work is to be done on them still
stands.

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