Hi!
Since we've got voting on the process RFCs finally going on, after much
deliberation we've decided it'd be best to let the votes finish before
the first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1
until June 28th (next Tuesday). The updated schedule is at
https://wiki.php.net/todo/php54 , please check out.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Since we've got voting on the process RFCs finally going on, after much
deliberation we've decided it'd be best to let the votes finish before the
first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1 until
June 28th (next Tuesday). The updated schedule is at
https://wiki.php.net/todo/php54 , please check out.
I think we should delay it a little until we have the bugs data back.
Bjori has been in contact with them on the phone today.
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:
http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
cheers,
Derick
Hi!
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:
http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
It doesn't say there Thursday is our general release day. If we want to
make it so - ok, let's everybody agree on that and put it there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
It doesn't say there Thursday is our general release day. If we want to make
it so - ok, let's everybody agree on that and put it there.
What we actually did during the last years was to release on Tuesday
or Thursday, with a little preference to release final (stable) on
Thursday.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
It doesn't say there Thursday is our general release day. If we want to make
it so - ok, let's everybody agree on that and put it there.What we actually did during the last years was to release on Tuesday
or Thursday, with a little preference to release final (stable) on
Thursday.
Little preference?
According http://www.php.net/releases/
array(4) {
["Thursday"]=>
int(30)
["Tuesday"]=>
int(3)
["Monday"]=>
int(3)
["Wednesday"]=>
int(1)
}
-Hannes
hi,
On Tue, Jun 28, 2011 at 6:54 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Little preference?
According http://www.php.net/releases/
array(4) {
["Thursday"]=>
int(30)
["Tuesday"]=>
int(3)
["Monday"]=>
int(3)
["Wednesday"]=>
int(1)
}
So Thursday was the big preference, wed uploads mean "stable" as we
upload it one day before so they get mirrored when the announce is
sent.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:
http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markupIt doesn't say there Thursday is our general release day. If we want
to make it so - ok, let's everybody agree on that and put it there.
I'm actually surprised it isn't in there. I did write that document
some eons ago. But anyway, let's add it then :)
cheers,
Derick
Hi!
I'm actually surprised it isn't in there. I did write that document
some eons ago. But anyway, let's add it then :)
OK, as soon as we are all agreed on Thursday and it's there I'll shift
the schedule for next releases so it'll actually be on Thursday, though
I'm not sure why would it actually matter :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'm actually surprised it isn't in there. I did write that document
some eons ago. But anyway, let's add it then :)OK, as soon as we are all agreed on Thursday and it's there I'll shift the schedule for next releases so it'll actually be on Thursday, though I'm not sure why would it actually matter :)
The day an alpha/beta is released doesn't feel important, unlike stable releases, but I suppose consistency has its good points. :) I think the main point is to wait for bugs.php.net, which is making real progress and should be available Thursday.
Also, it's important to clarify that the [soon-to-be-popular] built-in web server is not part of this alpha because the alpha was tagged a few days before its addition. I think repackaging would be worth it for this case, but waiting for alpha2 is feasible.
Regards,
Philip
Hi!
Also, it's important to clarify that the [soon-to-be-popular]
built-in web server is not part of this alpha because the alpha was
tagged a few days before its addition. I think repackaging would be
worth it for this case, but waiting for alpha2 is feasible.
We'll have alpha2 in a month. I'm really not a fan on last minute
repackaging, that's when screw ups happen almost every time.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Also, it's important to clarify that the [soon-to-be-popular]
built-in web server is not part of this alpha because the alpha was
tagged a few days before its addition. I think repackaging would be
worth it for this case, but waiting for alpha2 is feasible.We'll have alpha2 in a month. I'm really not a fan on last minute
repackaging, that's when screw ups happen almost every time.
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.
It takes 1h~ to do it, no big deal.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
We'll have alpha2 in a month. I'm really not a fan on last minute
repackaging, that's when screw ups happen almost every time.I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.
+1
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Hi!
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.
Really, guys, if we ever want to have scheduled and orderly releases,
changing release schedule in the last minute repeatedly and repackaging
in the last second is exactly NOT the way to do it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.Really, guys, if we ever want to have scheduled and orderly releases,
changing release schedule in the last minute repeatedly and repackaging in
the last second is exactly NOT the way to do it.
Usually I would agree, but in the current situation I would vote for
the repackaging.
we already streched our release date, and going with the current 5.4
HEAD still seems a better idea than with the current alpha.
Tyrael
On June-28-11 2:06 PM Stas Malyshev wrote:
I do think we should repackage. There are many issues fixed since
last week and it makes no sense to release something not representing
what the current 5.4 branch is.Really, guys, if we ever want to have scheduled and orderly releases,
changing release schedule in the last minute repeatedly and repackaging
in the last second is exactly NOT the way to do it.
IMHO, exactly right. Not much point in having a plan if it isn't followed,
and that usually ends up causing problems - what the plan is supposed to
prevent.
Best Regards,
Mike Robinson
Hi!
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.Really, guys, if we ever want to have scheduled and orderly releases,
changing release schedule in the last minute repeatedly and repackaging
in the last second is exactly NOT the way to do it.
I agree with Stas. Repackaging in the last second might cause troubles
and include obvious bugs. I prefer having a some time between packaging
and releasing, if it's an alpha or not it doesn't matter. So in this
case, to really try to finally stay on schedule , so we should release the
already pacakged version and have an alpha2 in two weeks.
Hi!
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.Really, guys, if we ever want to have scheduled and orderly releases,
changing release schedule in the last minute repeatedly and repackaging
in the last second is exactly NOT the way to do it.I agree with Stas. Repackaging in the last second might cause troubles
and include obvious bugs. I prefer having a some time between packaging
and releasing, if it's an alpha or not it doesn't matter. So in this
case, to really try to finally stay on schedule , so we should release the
already pacakged version and have an alpha2 in two weeks.--
wasn't the alpha1 packaged in the last second?
it was packaged on Jun 19, and it was planned to be released on Jun 20.
and it did include obvious bugs.
so if we already screwed up, we could at least fix what we can instead
of releasing a version, which we all know is broken.
this can make a bad impression in the early adopters.
but I won't whine much about this, just told my 2 cents.
Tyrael
Hi!
wasn't the alpha1 packaged in the last second?
it was packaged on Jun 19, and it was planned to be released on Jun 20.
and it did include obvious bugs.
No, it was not. It was checked, ensured it builds on all systems I have
access too, etc, and it was done in advance of the release. And I'm sure
it has bugs - as every alpha in the world does. That's why it is alpha
and not final release. The point of alpha is not to provide a stable
platform but initial point for the release and flush out bugs by
expanding the user base. It's not a production release.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
final release. The point of alpha is not to provide a stable platform but
initial point for the release and flush out bugs by expanding the user base.
It's not a production release.
Exactly. Requiring a working bug tracker.
Postponing the release for a week if I can't get in touch with the
guys early enough is the logical thing in my opinion.
We do however have a 5.4RC out there for some reason..
As for repacking, I totally agree with not repackage - even though it
is very annoying that it doesn't include many things people have been
working on :)
If you opt for waiting another week, I would like to see a
retagging+packaging on Tuesday :]
-Hannes
Hi!
final release. The point of alpha is not to provide a stable platform but
initial point for the release and flush out bugs by expanding the user base.
It's not a production release.Exactly. Requiring a working bug tracker.
Postponing the release for a week if I can't get in touch with the
guys early enough is the logical thing in my opinion.
We do however have a 5.4RC out there for some reason..
It looks like we could have some working tracker (even though without
all the old stuff back yet) very soon - at least so it seems from the
info that I've got - so provided that we already delayed it a number of
times, I'd rather have it out sooner. We could though advance the next
alpha - say, to Thursday July 21, if we are settled on Thursday being
the Release Day :) - which is not that far out, and will have all the
new goodies.
I'd rather have something out to get the release process finally
officially kick off than to wait again.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
On Tue, Jun 28, 2011 at 21:00, Stas Malyshevsmalyshev@sugarcrm.com
wrote:final release. The point of alpha is not to provide a stable platform but
initial point for the release and flush out bugs by expanding the user
base.
It's not a production release.Exactly. Requiring a working bug tracker.
Postponing the release for a week if I can't get in touch with the
guys early enough is the logical thing in my opinion.
We do however have a 5.4RC out there for some reason..
That was ofcourse supposed to say 5.3RC :)
It looks like we could have some working tracker (even though without all
the old stuff back yet) very soon - at least so it seems from the info that
I've got - so provided that we already delayed it a number of times, I'd
rather have it out sooner. We could though advance the next alpha - say, to
Hang on.. wait what?
So Pierres weird threats on IRC weren't silly jokes?
Heck, we could apt-get install bugzilla on a random mirror if you just
want some bug tracker database to ignore and "have something".
-Hannes
Hang on.. wait what?
So Pierres weird threats on IRC weren't silly jokes?Heck, we could apt-get install bugzilla on a random mirror if you just
want some bug tracker database to ignore and "have something".
merging the new bugs would be a little more work though.
and it would be weird that we change to bugzilla, then back to the old
bugtracker when we get the backup from the hoster.
Tyrael
On Tue, Jun 28, 2011 at 10:06 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Hang on.. wait what?
So Pierres weird threats on IRC weren't silly jokes?Heck, we could apt-get install bugzilla on a random mirror if you just
want some bug tracker database to ignore and "have something".
Hannes, with all respects to your work, such comments are not welcome
in this list.
As I told you, it is not me, but the release managers who decide when
a release can be done. And despite our efforts to get the situation
around bugs.php.net sorted out, nothing, absolutely nothing happened
in two weeks. We bring it back and we will restore the existing data
as soon as we have the backups. See my other mail for the details.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
wasn't the alpha1 packaged in the last second?
it was packaged on Jun 19, and it was planned to be released on Jun 20.
and it did include obvious bugs.No, it was not. It was checked, ensured it builds on all systems I
have access too, etc, and it was done in advance of the release. And
I'm sure it has bugs - as every alpha in the world does. That's why it
is alpha and not final release. The point of alpha is not to provide a
stable platform but initial point for the release and flush out bugs
by expanding the user base. It's not a production release.
But it missed the built-in webserver thing :(
regards,
Derick
wasn't the alpha1 packaged in the last second?
it was packaged on Jun 19, and it was planned to be released on Jun 20.
and it did include obvious bugs.No, it was not. It was checked, ensured it builds on all systems I
have access too, etc, and it was done in advance of the release. And
I'm sure it has bugs - as every alpha in the world does. That's why it
is alpha and not final release. The point of alpha is not to provide a
stable platform but initial point for the release and flush out bugs
by expanding the user base. It's not a production release.But it missed the built-in webserver thing :(
regards,
Derick
AFAIK that got into it, but the fixes for the related crashes did not.
Tyrael
AFAIK that got into it, but the fixes for the related crashes did not.
Nope, not until alpha2... but it's something to look forward to, and it's another reason for people to continue testing future alpha releases. :)
Regards,
Philip