Hi
I been commenting on some bugs and putting some fixes also, dose anyone
know how to get edit access on bugs?
+1
On Thu, Jan 15, 2015 at 8:16 PM, Pasindu De Silva
wrote:
> Hi Guys
>
> What do you think about a folder "bugtests" with tests of all verified
> bugs.
> This can allows developers d
Hi Guys
What do you think about a folder "bugtests" with tests of all verified
bugs.
This can allows developers dive into the bug and test quickly I think and
also
devs fixing others bug might inadvertently fix other bugs.
I am currently trying to put together set of bug tests here
https://github.
On Tue, 2014-12-30 at 12:57 +, Craig Duncan (PHP) wrote:
> I'd be willing to spend some time on this. Presumably I'd need some
> authorised access to the bug tracker?
You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them
> De : christopher jones [mailto:christopher.jo...@oracle.com]
>
>> To summarize, I started with a rather simple feature request and was
>> then pushed by external wishes.
>
> See #13 at
> https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
> "Take advice on board but make sure your
> De : François Laupretre [mailto:franc...@tekwire.net]
> > De : Andrey Andreev [mailto:n...@devilix.net]
> > I have to agree here. Nested arrays are too much ... it should be
> > limited to single-dimension arrays.
>
> It makes the C code simpler to understand. But I am OK not to document the
> f
On 1/10/15 9:03 AM, François Laupretre wrote:
To summarize, I started with a rather simple feature request and was
then pushed by external wishes.
See #13 at
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
"Take advice on board but make sure your feature doesn't end up bei
Hi Andrey,
> De : Andrey Andreev [mailto:n...@devilix.net]
>
> I have to agree here. Nested arrays are too much ... it should be
> limited to single-dimension arrays.
It makes the C code simpler to understand. But I am OK not to document the
feature for search and replace. I'd like to keep it fo
De : Nikita Popov [mailto:nikita@gmail.com]
>
> str_replace is a simple function for string replacement. It has some (imho
> also unnecessary)
> extra gimmicks to implicitly do a foreach() loop during the replacement. This
> is still relatively
> simple API-wise. But if I see this (taken fro
Hi,
On Sat, Jan 10, 2015 at 1:53 PM, Nikita Popov wrote:
> But if I see this (taken from the tests) as the search & replacement values...
>
> $search=array('[?]',array('(?)','d','e'),'a','R');
> $repl=array(
> array('ap(?)z[?]',"b[?](?)v",null,37,"[?]n[?]"),
> array('a',array('b',null)),
On Fri, Jan 9, 2015 at 1:08 AM, François Laupretre
wrote:
> Hi,
>
> I just created the RFC :
>
> https://wiki.php.net/rfc/cyclic-replace
>
> I tried to include everything we agreed upon. Tell me if I missed
> something.
>
> Please note that the current PR does not implement the whole RFC. You may
On Jan 10, 2015 8:35 AM, "François Laupretre" wrote:
>
> > De : François Laupretre [mailto:franc...@tekwire.net]
> >
> > > I just created the RFC :
> > >
> > > https://wiki.php.net/rfc/cyclic-replace
> >
> > Just added full array multi-level recursion support to the RFC.
>
> Final (?) patch pushed
> De : François Laupretre [mailto:franc...@tekwire.net]
>
> > I just created the RFC :
> >
> > https://wiki.php.net/rfc/cyclic-replace
>
> Just added full array multi-level recursion support to the RFC.
Final (?) patch pushed to PR. In sync with RFC.
> > Please also give me your opinion about i
> De : François Laupretre [mailto:franc...@tekwire.net]
>
> I just created the RFC :
>
> https://wiki.php.net/rfc/cyclic-replace
Just added full array multi-level recursion support to the RFC.
Still debugging the code and adding new tests.
> Please also give me your opinion about implementing a
Hi,
Just wanted to say: +1 on this and thank you for proposing a patch.
I myself created a feature request for it on bugs.php.net some time
ago, now closed as duplicate: https://bugs.php.net/bug.php?id=62315
Cheers,
Andrey.
On Fri, Jan 9, 2015 at 2:08 AM, François Laupretre wrote:
> Hi,
>
> I
Hi,
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
I tried to include everything we agreed upon. Tell me if I missed something.
Please note that the current PR does not implement the whole RFC. You may
review the RFC while I update the code.
Please also give me your opinion a
On Mon, Jan 5, 2015 at 9:30 PM, Andrea Faulds wrote:
>
> > On 5 Jan 2015, at 20:28, Stanislav Malyshev wrote:
> >
> > Hi!
> >
> >> usually each BC break would warrant an RFC and a vote, but I'm not sure
> >> many people would use str_replace("foo", array("bar"), $subject); and
> >> expect the im
On Mon, Jan 5, 2015 at 9:28 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > usually each BC break would warrant an RFC and a vote, but I'm not sure
> > many people would use str_replace("foo", array("bar"), $subject); and
> > expect the implicit array to string conversion of array("bar") => "Array"
> >
> On 5 Jan 2015, at 20:28, Stanislav Malyshev wrote:
>
> Hi!
>
>> usually each BC break would warrant an RFC and a vote, but I'm not sure
>> many people would use str_replace("foo", array("bar"), $subject); and
>> expect the implicit array to string conversion of array("bar") => "Array"
>> whic
Hi!
> usually each BC break would warrant an RFC and a vote, but I'm not sure
> many people would use str_replace("foo", array("bar"), $subject); and
> expect the implicit array to string conversion of array("bar") => "Array"
> which also emits a notice.
> let's see what others think.
I wouldn't
On Mon, Jan 5, 2015 at 6:20 PM, Andrea Faulds wrote:
> Hey François,
>
> > On 5 Jan 2015, at 17:15, F & N Laupretre wrote:
> >
> > I just created a PR for a feature request lying around since 2006 :
> >
> > https://github.com/php/php-src/pull/980
> >
> > It adds support in str_replace() and str_
Hey François,
> On 5 Jan 2015, at 17:15, F & N Laupretre wrote:
>
> I just created a PR for a feature request lying around since 2006 :
>
> https://github.com/php/php-src/pull/980
>
> It adds support in str_replace() and str_ireplace() for the combination of
> (string needle, array replace). I
Hi!
> Would it be appropriate to close issues that are clear, but can easily
> be done in userland e.g. https://bugs.php.net/bug.php?id=64639
>
> Leaving an issue like that open seems to pretty pointless, even though
> it is clear what is being asked.
Yes, this one is pretty clearly not going to
On Sun, Jan 4, 2015 at 8:50 PM, Dan Ackroyd wrote:
> Levi wrote:
> >> ...and what to do with feature requests?
>
> Stanislav Malyshev wrote:
> > if it's clear what is being asked than just leave them alone,
>
> Would it be appropriate to close issues that are clear, but can easily
> be done in u
Levi wrote:
>> ...and what to do with feature requests?
Stanislav Malyshev wrote:
> if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639
Leaving an issu
On 29 December 2014 at 07:59, Stanislav Malyshev
wrote:
>
>
> We definitely need somebody triaging old bugs. The problem is it
> requires a real lot of time, and is mind-numbingly boring, so not many
> people do it. Many bugs are low quality - missing data, not having good
> descriptions, etc. - o
On Sun, Dec 28, 2014 at 7:45 AM, Remi Collet wrote:
> Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
> > Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
> >> bugs going as far back as to PHP4.
> >
> > Bug reports for PHP version that are not supported anymore [1]
> > should IMHO be bulk-c
My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.
There appears to be a trend emerging where frameworks are making this more
of a feature on their sites and there's nothing people enjoy more than
getting recognition for their effort - even if
I'm pretty sure that just trying to reproduce a problem and posting
results in the comment, would be *very* helpful.
W dniu 2014-12-29 o 19:19, Rafael Kassner pisze:
Any chance to people without Karma helping here? Maybe trying to reproduce
the bug in 5.4+ and asking for feedback? Any workflow
Any chance to people without Karma helping here? Maybe trying to reproduce
the bug in 5.4+ and asking for feedback? Any workflow suggested?
On Dec 29, 2014 4:03 PM, "Stanislav Malyshev" wrote:
> Hi!
>
> > ...and what to do with feature requests?
>
> I would say - if it looks big (i.e. BC-breaking
I will have some time the next few days, I have little C knowledge and never
committed something to PHP core, but I could take a look and do some cleanup.
Sent from my iPhone 7 Beta [Confidential use only]
> On 29 dec. 2014, at 19:02, Stanislav Malyshev wrote:
>
> Hi!
>
>> ...and what to do
Hi!
> ...and what to do with feature requests?
I would say - if it looks big (i.e. BC-breaking change, language change,
completely new functionality that may influence other parts of the
language, etc.), recommend submitting the RFC, otherwise if it's clear
what is being asked than just leave the
>> For a while I have been just stalking the bugs database[1], and I
>> would love if we could some more focus on closing bugs. I'm not saying
>> the job we do (my self included) is not being done well enough, but
>> currently we have over 4.1k and a lot of those are old feature
>> requests, or bug
Hi!
> For a while I have been just stalking the bugs database[1], and I
> would love if we could some more focus on closing bugs. I'm not saying
> the job we do (my self included) is not being done well enough, but
> currently we have over 4.1k and a lot of those are old feature
> requests, or bug
Hi Kelle Thanks will dig in
On Mon, Dec 29, 2014 at 4:28 AM, Kalle Sommer Nielsen wrote:
> Hi Pasindu
>
> 2014-12-28 23:43 GMT+01:00 Pasindu De Silva :
> > Hi
> > I would like join and fix some I have been trying to fix some bugs in
> > DateTIme thought it was a good place to start, is there may
Hi Pasindu
2014-12-28 23:43 GMT+01:00 Pasindu De Silva :
> Hi
> I would like join and fix some I have been trying to fix some bugs in
> DateTIme thought it was a good place to start, is there maybe a way to add a
> label called
> novice or starter bugs for people with little experience to get into
Come up with a way to incentivise people to fix bugs.
My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.
I'd be happy to work on this with someone.
On 28 Dec 2014 19:16, "Levi Morrison" wrote:
> I have committed a fix for one bug and closed anothe
I have committed a fix for one bug and closed another bug report
because of this thread. I will continue to look at bugs but I wanted
to spread some encouragement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
> Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
>> bugs going as far back as to PHP4.
>
> Bug reports for PHP version that are not supported anymore [1]
> should IMHO be bulk-closed. The message should ask to reopen if
> the bug is reproduc
Hi again,
> On 28 Dec 2014, at 03:11, Andrea Faulds wrote:
>
>> On 28 Dec 2014, at 03:09, Jacob Bednarz wrote:
>>
>>> What do you mean by this? What’s a priority? You can sort by votes, you can
>>> filter by status, I’m not sure what you mean with “on a label”.
>>>
>>> Could you please elabo
Well, there isn’t such a label because labels have to be created by
people going through and adding that label to bugs. So someone has to look
through 4000 bugs.
This definitely could be an issue for existing bugs but if it's available
when someone creates a bug they could fill it out at tha
Hey Jacob,
> On 28 Dec 2014, at 03:09, Jacob Bednarz wrote:
>
>> What do you mean by this? What’s a priority? You can sort by votes, you can
>> filter by status, I’m not sure what you mean with “on a label”.
>>
>> Could you please elaborate? Thanks.
>
> Sure - A label can be anything that is
What do you mean by this? What’s a priority? You can sort by votes, you
can filter by status, I’m not sure what you mean with “on a label”.
Could you please elaborate? Thanks.
Sure - A label can be anything that is used to allow finer searching of
issues. For example, I don't have a specific
Hey Jacob,
> On 28 Dec 2014, at 01:48, Jacob Bednarz wrote:
>
> One of the biggest issues I have found with the PHP bug tracker is the
> inability to filter on tickets and find the low hanging fruit based on a
> label or a priority.
What do you mean by this? What’s a priority? You can sort by
One of the biggest issues I have found with the PHP bug tracker is the
inability to filter on tickets and find the low hanging fruit based on a
label or a priority. I realise the advanced search allows you to find
based on package however this still is not enough. I am quite new to the
developm
> I for one are against just closing old bugs without at least a review
> too. If we can have 5-10 developers (from any part of the community
> with a @php.net account) to look over a few bugs a day, then we can
> quickly bring that number down.
I'll gladly enlist here. I've gone through bugs in t
Hi Andrea
2014-12-27 20:08 GMT+01:00 Andrea Faulds :
> As Rowan says, this would be a problem. Rather than just closing all bugs
> that are of a certain age, we should just go through all the open bugs one by
> one. 4000 open bugs is a lot, sure, but with a few people working at it I
> think we
Hey all,
> On 27 Dec 2014, at 18:34, Rowan Collins wrote:
>
> On 27 December 2014 15:06:42 GMT, Sebastian Bergmann
> wrote:
>> Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
>>> bugs going as far back as to PHP4.
>>
>> Bug reports for PHP version that are not supported anymore [1]
>> s
On 27 December 2014 15:06:42 GMT, Sebastian Bergmann wrote:
>Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
>> bugs going as far back as to PHP4.
>
> Bug reports for PHP version that are not supported anymore [1]
> should IMHO be bulk-closed. The message should ask to reopen if
> the bug is
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
> bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
the bug is reproducible with a supported version of PHP. IMHO :)
--
[1] htt
49 matches
Mail list logo
