Hi. I'm first time poster. I'm working for Opera Software and I'm developing Opera Mini server, which involves quite a lot of Pike. I've added handling of jemalloc to Pike build and I'd like to upstream it to Pike repository. What's the procedure (a "pull request") to proceed with the change?
Hi Tomasz,
Glad you have joined the Pike developers!
To contribute something to Pike you need to first read and comply with http://pike.lysator.liu.se/development/git/policies/. The part that probably requires most thought from your side is the "Pike copyrights" point. You have to have the legal right to relinquish your or Operas copyright claims over the copy of the code you want to contribute and give Linköping University/IDA the full right to do whatever with it. This includes changing the license in the future without consulting you. That is not just a theoretical possibility, the code used to be GPL2 only at one point, but it was changed to GPL2/LGPL/MPL.
You retain full rights to your copy of the code and can do whatever you want with it without consulting IDA.
When I was an employee with Opera Linköping we had blanket OK to do this, but you might want to double check with your manager or talk to Tobias tobij@opera.com at the Linköping office who might be better updated.
No signing is needed, just make sure that you don't get yelled at internally and then reply to this say "I've read and will comply with the contribution policies".
When the formal stuff is out of the way, make a pull request against https://github.com/pikelang/Pike and send another mail to this list pointing to the PR URL. We so seldom use Github PRs that not many people are monitoring them. Normal development is on feature branches on the main repo and then you merge them yourself when the general consensus is that it's a good change. Lets discuss setting up that access for you (if you want) after handling this as a PR.
Regards,
On Mon, 05 Feb 2018 15:57:07 +0100, Peter Bortas bortas@gmail.com wrote:
Hi Tomasz,
Hi.
Glad you have joined the Pike developers!
To contribute something to Pike you need to first read and comply with http://pike.lysator.liu.se/development/git/policies/. The part that probably requires most thought from your side is the "Pike copyrights" point. You have to have the legal right to relinquish your or Operas copyright claims over the copy of the code you want to contribute and give Linköping University/IDA the full right to do whatever with it. This includes changing the license in the future without consulting you. That is not just a theoretical possibility, the code used to be GPL2 only at one point, but it was changed to GPL2/LGPL/MPL.
You retain full rights to your copy of the code and can do whatever you want with it without consulting IDA.
When I was an employee with Opera Linköping we had blanket OK to do this, but you might want to double check with your manager or talk to Tobias tobij@opera.com at the Linköping office who might be better updated.
No signing is needed, just make sure that you don't get yelled at internally and then reply to this say "I've read and will comply with the contribution policies".
I've got official permission to contribute and I've read and will comply with the contribution policies.
When the formal stuff is out of the way, make a pull request against https://github.com/pikelang/Pike and send another mail to this list pointing to the PR URL. We so seldom use Github PRs that not many people are monitoring them. Normal development is on feature branches on the main repo and then you merge them yourself when the general consensus is that it's a good change. Lets discuss setting up that access for you (if you want) after handling this as a PR.
It's in https://github.com/pikelang/Pike/pull/6.
The variable name changes in requestobject.c seem unrelated. Did you mean to include those in the pull request?
The changes in builtin.cmod also looks like a macro style change unrelated to the jemalloc stuff?
No, it's not unrelated. When global.h includes <jemalloc/jemalloc.h>, that header in turn includes <stdbool.h>, which contains
#define true 1
The change in builtin.cmod ensures that GET_VAL(true) actually expands to get_val_true instead of get_val_1 (as discussed here starting 2018-01-23, subject "The GET_VAL macro and C99").
Right, then I have no general complaints left (if the USE_JEMALLOC thing Nilsson pointed out is cleared up). This looks localized enough that it shouldn't break anything.
I'm curious what benchmarks have been run with this. Do you have any before and after comparisons for this Tomasz?
Perhaps I'm missing something, but you are testing for jemalloc/jemalloc.h in configure, but then include it regardless of the result.
(We should move feature specific tests to feature specific blocks to reduce the number of tests unconditionally run. Not that I would hold up this PR for that)
pike-devel@lists.lysator.liu.se
-
ceder (-) Per Cederqvist ＠ Pike (-) developers forum -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum
-
Peter Bortas -
Peter Bortas ＠ Pike developers forum
-
Tomasz Jamroszczak