On Tue, April 17, 2012 3:34 am, Martin Jansen wrote:
> On 17.04.12 10:24, Bas van Beek wrote:
>> Sounds like facilitating wrong security protocols to me. In this
>> 365/24/7 environment, sysadmins should be willing and able to patch,
>> fix
>> and secure systems at any time. Weekend should be no ex
On 17.04.12 10:24, Bas van Beek wrote:
> Sounds like facilitating wrong security protocols to me. In this
> 365/24/7 environment, sysadmins should be willing and able to patch, fix
> and secure systems at any time. Weekend should be no excuse.
There are a lot of (very serious) shops out there with
Op 17-4-2012 9:47, Hannes Magnusson schreef:
On Mon, Apr 9, 2012 at 08:54, Stas Malyshev wrote:
Hi!
5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predi
On Mon, Apr 9, 2012 at 08:54, Stas Malyshev wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
> schedule and faster re
On 04/16/2012 01:12 PM, Stas Malyshev wrote:
Hi!
I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
become 5.4.2-dev.
You're right.
As an exercise, I submitted a pull request fixing this.
Chris
--
christopher.jo...@oracle.com
http://twitter.com/#!/ghrd
--
PHP Internals
Hi!
> I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
> become 5.4.2-dev.
You're right.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
On 04/10/2012 03:46 PM, Stas Malyshev wrote:
Hi!
I think my main point still stands: if the git emails are too obscure to
follow, let us know what goes in via email to internals.
Do you want to bring the NEWS updating process into this discussion?
Sure, though that would be another discuss
Pierre,
On Tue, Apr 10, 2012 at 10:42 PM, Pierre Joye wrote:
> Kris,
>
> On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig wrote:
>
> > Given the number of RCs we've seen in the past, I remain skeptical that
> > your approach will prove sustainable. But I'd say let's just try it and
> > see how it g
Kris,
On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig wrote:
> Given the number of RCs we've seen in the past, I remain skeptical that
> your approach will prove sustainable. But I'd say let's just try it and
> see how it goes.
Saying that is totally ignoring the main point in the new way: Very
li
On Tue, Apr 10, 2012 at 3:46 PM, Stas Malyshev wrote:
> Hi!
>
> > I think my main point still stands: if the git emails are too obscure to
> > follow, let us know what goes in via email to internals.
> >
> > Do you want to bring the NEWS updating process into this discussion?
>
> Sure, though that
Hi!
> I think my main point still stands: if the git emails are too obscure to
> follow, let us know what goes in via email to internals.
>
> Do you want to bring the NEWS updating process into this discussion?
Sure, though that would be another discussion IMHO. In this discussion,
I just wanted
hi,
2012/4/10 Johannes Schlüter :
> 0f180a6 - Fixed bug in new stream_get_line() when using NUL as a delimiter.
> (This is a regression from 5.3.10)
> 9bf8cd4 - Fixed bug #61650 (ini parser crashes when using ${} ini
> variables (without apache2))
> (Crash fix)
> ca58cd0 - Cherry-pi
On Sun, 2012-04-08 at 23:54 -0700, Stas Malyshev wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
As will 5.3.11.
> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
>
On 4/9/12 3:21 PM, Stas Malyshev wrote:
Hi!
I would like to see clarity on when fixes have been merged to the RC
branch (git emails are still a bit hard to grok). It would help to
have early communication about fixes you have decided against so we
can argue their merits and so we don't assum
Hi!
> I would like to see clarity on when fixes have been merged to the RC
> branch (git emails are still a bit hard to grok). It would help to
> have early communication about fixes you have decided against so we
> can argue their merits and so we don't assume you are planning to pick
> them up.
Hi!
> My concern is that merge conflicts can occur when cherry-picking in this
> manner. It's just generally not a "best practices" approach when using
Which merge conflicts? Diff between 5.4 and 5.4.X will never be big
enough to have any conflicts. It's just 2 weeks of stable version code.
> c
On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev wrote:
> Hi!
>
> > release candidates. I mean, we're still planning on having multiple
> > release candidates before an actual release, right? If so, then
>
> Not if we can avoid it. If we don't have critical bugs in RC1, we
> release it.
>
> > obvio
Hi!
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then
Not if we can avoid it. If we don't have critical bugs in RC1, we
release it.
> obviously we'll need a way to commit those changes. If they're not made
>
On Mon, Apr 9, 2012 at 2:33 PM, Kiall Mac Innes wrote:
> On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig wrote:
>>
>> What I'm referring to is the same kind of bugfixes/etc that go into new
>> release candidates. I mean, we're still planning on having multiple
>> release candidates before an actual
On 04/08/2012 11:54 PM, Stas Malyshev wrote:
Hi!
5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predictable release
schedule and faster releases.
What I
On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig wrote:
>
> What I'm referring to is the same kind of bugfixes/etc that go into new
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then obviously
> we'll need a way to c
Stas,
On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev wrote:
> Hi!
>
> > version of a "Release-x.xx" branch. I would suggest allowing commits on
> > that branch, but *only* if they're bugfixes or minor housekeeping. Each
>
> I don't want to do this, because this would very quickly lead us back to
Hi!
> version of a "Release-x.xx" branch. I would suggest allowing commits on
> that branch, but *only* if they're bugfixes or minor housekeeping. Each
I don't want to do this, because this would very quickly lead us back to
old chaotic situation where people commit stuff at the last moment and
On Mon, Apr 9, 2012 at 3:26 AM, Kiall Mac Innes wrote:
> This is a very similar process to what OpenStack uses, it seems to work
> well for them.
>
> They have a few guys on freenode in #openstack-infra that have shown
> themselves more than willing to go into detail about their setup and its
> p
This is a very similar process to what OpenStack uses, it seems to work
well for them.
They have a few guys on freenode in #openstack-infra that have shown
themselves more than willing to go into detail about their setup and its
pro/con's..
It would be worth asking them for their experience...
T
Hi!
5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predictable release
schedule and faster releases.
What I am proposing is the following:
1. At the start o
26 matches
Mail list logo
