hi,
As you have noticed bugs.php.net has been down for almost two weeks
now. We are working on restoring the service completely within the
next couple of days.
In the mean time, https://bugs.php.net will be back online tonight
with the following restrictions:
- existing bugs (prior the disappearance) will be available in read only mode
- patches attached to a report are not available
- only new bugs can be reported and then edited/modified
A significant change is that now bugs.php.net is only available via
https://bugs.php.net.
The ideal plan is to restore the old bugs as soon as we get a hand on
the old server. That should happen in the next two days. However, if
we fail to get a hand on the server, we will restore the contents
using the mail archives. Patches may still be missed sadly.
The reason to push bugs.php.net back online today is that PHP
5.4.0-alpha1 is about to be released (see the RMs mail earlier). It
makes little to no sense to do it without giving our users a way to
give us feedback via the bug tracker.
Thanks for your understanding and thanks to the guys working hard to
restore this service!
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net
hi,
Everything is now back to normal, all bugs can be edited, new ones
have been reindexed to match the old IDs, etc.
Thanks for your patience and thanks Felipe, Tyrael, Dan and David for
their efforts.
Cheers,
hi,
As you have noticed bugs.php.net has been down for almost two weeks
now. We are working on restoring the service completely within the
next couple of days.In the mean time, https://bugs.php.net will be back online tonight
with the following restrictions:
- existing bugs (prior the disappearance) will be available in read only mode
- patches attached to a report are not available
- only new bugs can be reported and then edited/modified
A significant change is that now bugs.php.net is only available via
https://bugs.php.net.The ideal plan is to restore the old bugs as soon as we get a hand on
the old server. That should happen in the next two days. However, if
we fail to get a hand on the server, we will restore the contents
using the mail archives. Patches may still be missed sadly.The reason to push bugs.php.net back online today is that PHP
5.4.0-alpha1 is about to be released (see the RMs mail earlier). It
makes little to no sense to do it without giving our users a way to
give us feedback via the bug tracker.Thanks for your understanding and thanks to the guys working hard to
restore this service!Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Everything is now back to normal, all bugs can be edited, new ones
have been reindexed to match the old IDs, etc.Thanks for your patience and thanks Felipe, Tyrael, Dan and David for
their efforts.Cheers,
also for Hannes and Derick for getting the bugsdb back and David
Coallier for offering to pay a visit to the hosting. :)
ps: please make sure that the offsite backup is set up everywhere. ;)
Tyrael
great news
thanks you all !
2011/6/30 Ferenc Kovacs tyra3l@gmail.com:
hi,
Everything is now back to normal, all bugs can be edited, new ones
have been reindexed to match the old IDs, etc.Thanks for your patience and thanks Felipe, Tyrael, Dan and David for
their efforts.Cheers,
also for Hannes and Derick for getting the bugsdb back and David
Coallier for offering to pay a visit to the hosting. :)ps: please make sure that the offsite backup is set up everywhere. ;)
Tyrael
A significant change is that now bugs.php.net is only available via
https://bugs.php.net.
May I suggest that the interface doesn't redirect to https:// by default? http:// plays much nicer with proxies, and browsers cache resources to disk, which is helpful not only on slow connections :)
The bug report form and anything else that transmits a password or similar could of course still be done via https://.
If the current web interface doesn't allow this, I'd be happy to help with adding that feature.
David
May I suggest that the interface doesn't redirect to https:// by default? http:// plays much nicer with proxies, and browsers cache resources to disk, which is helpful not only on slow connections :)
Newish browsers do cache to disk if the Cache-Control header has the
"public" directive in it.
The bug report form and anything else that transmits a password or similar could of course still be done via https://.
What about session cookies? Full-https is the only safe thing really.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
hi,
Sadly we won't change it. we may provide a non editable http: version
at some point, but for now it is just easier to have https: only (as
login is required anyway).
Cheers,
On Thu, Jun 30, 2011 at 7:11 AM, David Zülke
david.zuelke@bitextender.com wrote:
A significant change is that now bugs.php.net is only available via
https://bugs.php.net.May I suggest that the interface doesn't redirect to https:// by default? http:// plays much nicer with proxies, and browsers cache resources to disk, which is helpful not only on slow connections :)
The bug report form and anything else that transmits a password or similar could of course still be done via https://.
If the current web interface doesn't allow this, I'd be happy to help with adding that feature.
David
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org