Hi,
Now that the git migration is reaching php-src, I would like to know what
will we do with cvs.php.net (eg. the pserver still running on it).
There is also a mention of cvsup.php.net on http://php.net/cvsup.php I
guess that also uses/depends on the pserver, but I'm not that familiar with
the setup.
Should we keep that cvs up and running, or maybe it is time to kill it
completely?
What do you think?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi,
Now that the git migration is reaching php-src, I would like to know what
will we do with cvs.php.net (eg. the pserver still running on it).
There is also a mention of cvsup.php.net on http://php.net/cvsup.php I
guess that also uses/depends on the pserver, but I'm not that familiar with
the setup.
Should we keep that cvs up and running, or maybe it is time to kill it
completely?
What do you think?
bump
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
25 марта 2012 г. 23:33 пользователь Ferenc Kovacs tyra3l@gmail.com написал:
Hi,
Now that the git migration is reaching php-src, I would like to know what
will we do with cvs.php.net (eg. the pserver still running on it).
There is also a mention of cvsup.php.net on http://php.net/cvsup.php I
guess that also uses/depends on the pserver, but I'm not that familiar with
the setup.
Should we keep that cvs up and running, or maybe it is time to kill it
completely?
What do you think?
I think it's the time to say good bye to cvs. If somebody still uses
it (I doubt) he is already two steps back :)
bump
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Regards,
Shein Alexey
25 марта 2012 г. 23:33 пользователь Ferenc Kovacs tyra3l@gmail.com
написал:Hi,
Now that the git migration is reaching php-src, I would like to know
what
will we do with cvs.php.net (eg. the pserver still running on it).
There is also a mention of cvsup.php.net on http://php.net/cvsup.php I
guess that also uses/depends on the pserver, but I'm not that familiar
with
the setup.
Should we keep that cvs up and running, or maybe it is time to kill it
completely?
What do you think?I think it's the time to say good bye to cvs. If somebody still uses
it (I doubt) he is already two steps back :)
judging from the lack of interest I guess you are right.
I will remove the cvs/cvsup subdomain from our zone file, and the cvsup.php
file (any any other cvs(up).php.net reference from the codebase, and I
cc'ed the systems@ list, so that somebody with shell there can stop the cvs
service.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
judging from the lack of interest I guess you are right.
I will remove the cvs/cvsup subdomain from our zone file, and the cvsup.php
file (any any other cvs(up).php.net reference from the codebase, and I cc'ed
the systems@ list, so that somebody with shell there can stop the cvs
service.
The cvs subdomain automatically forwards (HTTP 301) to
svn.php.net, and cvsup (same method) to bugs-beta.php.net. This was
originally set up years ago, when we switched to SVN, in large part to
jog people's memory ("oh, yeah, CVS is gone"). I don't see any harm
in keeping the subdomains in the zone file, but I also don't see any
reason they couldn't be removed.
On a related note, the wiki entry mentions that the "userlist and
digest auth files are fetched from master2.php.net...." If this is
still the case, can someone switch that back to simply master.php.net
so we can decommission the master2 entry from the zone? Or, if anyone
would rather, just throw my key (on master) on there and I'll be glad
to do it today.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
judging from the lack of interest I guess you are right.
I will remove the cvs/cvsup subdomain from our zone file, and the
cvsup.php
file (any any other cvs(up).php.net reference from the codebase, and I
cc'ed
the systems@ list, so that somebody with shell there can stop the cvs
service.The cvs subdomain automatically forwards (HTTP 301) tosvn.php.net, and cvsup (same method) to bugs-beta.php.net. This was
originally set up years ago, when we switched to SVN, in large part to
jog people's memory ("oh, yeah, CVS is gone"). I don't see any harm
in keeping the subdomains in the zone file, but I also don't see any
reason they couldn't be removed.
yeah, it is forwarding the http traffic, but the cvspserver is still
running on cvs.php.net(and I was able to checkout from there):
tyrael@thor:~/checkouts$ nmap cvs.php.net|grep cvs
2401/tcp open cvspserver
would be nice if somebody could kill that.
On a related note, the wiki entry mentions that the "userlist and
digest auth files are fetched from master2.php.net...." If this is
still the case, can someone switch that back to simply master.php.net
so we can decommission the master2 entry from the zone? Or, if anyone
would rather, just throw my key (on master) on there and I'll be glad
to do it today.
I remember using master2 on people.php.net while we was in the process to
migrate the master to the new box, I will check and change back those
references to master.php.net
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
judging from the lack of interest I guess you are right.
I will remove the cvs/cvsup subdomain from our zone file, and the
cvsup.php
file (any any other cvs(up).php.net reference from the codebase, and I
cc'ed
the systems@ list, so that somebody with shell there can stop the cvs
service.The cvs subdomain automatically forwards (HTTP 301) tosvn.php.net, and cvsup (same method) to bugs-beta.php.net. This was
originally set up years ago, when we switched to SVN, in large part to
jog people's memory ("oh, yeah, CVS is gone"). I don't see any harm
in keeping the subdomains in the zone file, but I also don't see any
reason they couldn't be removed.yeah, it is forwarding the http traffic, but the cvspserver is still
running on cvs.php.net(and I was able to checkout from there):
tyrael@thor:~/checkouts$ nmap cvs.php.net|grep cvs
2401/tcp open cvspserver
would be nice if somebody could kill that.
the cvs server is still running there.
any reason why we should still keep that up?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu