On Tue, Jun 10, 2014 at 3:59 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Tue, Jun 10, 2014 at 2:56 PM, Anatol Belski anatol.php@belski.net
wrote:Hi,
On Tue, Jun 3, 2014 at 2:53 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Hi,
I noticed you pushed bunch of changes to the repo just which
seem to actually have been live for a while.. Does the build
host update from some other repo I would need to merge up to?that's the github OSTC repo forked from rmtools somewhen, havent
synced for a while. As that system is a prerunner for what we
gonna have with the travis integration, it doesn't really matter.
As besides
the snapshot builds running tests is also the topic, which is much
finer done with travis. Probably also a good thing to deliberate
before starting to do something.I think we just did that and have a solid plan I can work on.
Since attempting to duplicate the machinery is clearly impossible
task without having access to the current setup I would need to work
blind folded with trial and error here and there - which is why I
asked can I somehow see any logs (and to confirm, it is running the
rmtools repo on git.php.net you pointed me too, right?).
Alternatively, if I can get
access to the infrastructure that would be best.Any updates?
Feel like I am slacklining in a pitch dark cave above a lake full of
piranha :) If this is maintained on a vm or something I can replicate
it would be awesomest...yes, that's a VM but a clone is out of a question as there are too much
things there we can't simply "revert" to anonymize it. Btw. i really
think travis-ci integration were interesting to keep in mind, as that
would probably turn the whole thing upside down.Can I get access to the server then while I attempt to develop these
patches?actually that is out of my competention, but i guess it's the same as with
the vm clone. I'm going OOF for the next three weeks, and probably offline
for some time due to the Internet provider update, so will probably be
able to continue to talk about this topic after that first.Who else has access to it I would be able to talk to?
It doesn't look like there is much of anything I can actually work on
since the infrastructure itself is uncloneable and inaccessible?
ping?
-Hannes
Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]On Tue, Jun 10, 2014 at 3:59 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Tue, Jun 10, 2014 at 3:29 PM, Anatol Belski anatol.php@belski.net
wrote:On Tue, Jun 10, 2014 at 2:56 PM, Anatol Belski
anatol.php@belski.net
wrote:Hi,
On Tue, Jun 3, 2014 at 2:53 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Hi,
I noticed you pushed bunch of changes to the repo just which
seem to actually have been live for a while.. Does the build
host update from some other repo I would need to merge up to?that's the github OSTC repo forked from rmtools somewhen,
havent
synced for a while. As that system is a prerunner for what we
gonna have with the travis integration, it doesn't really matter.
As besides
the snapshot builds running tests is also the topic, which is
much finer done with travis. Probably also a good thing to
deliberate before starting to do something.I think we just did that and have a solid plan I can work on.
Since attempting to duplicate the machinery is clearly impossible
task without having access to the current setup I would need to
work blind folded with trial and error here and there - which is
why I asked can I somehow see any logs (and to confirm, it is
running the rmtools repo on git.php.net you pointed me too, right?).
Alternatively, if I can get
access to the infrastructure that would be best.Any updates?
Feel like I am slacklining in a pitch dark cave above a lake full
of piranha :) If this is maintained on a vm or something I can
replicate it would be awesomest...yes, that's a VM but a clone is out of a question as there are too
much things there we can't simply "revert" to anonymize it. Btw. i
really think travis-ci integration were interesting to keep in
mind, as that would probably turn the whole thing upside down.Can I get access to the server then while I attempt to develop these
patches?actually that is out of my competention, but i guess it's the same as
with the vm clone. I'm going OOF for the next three weeks, and
probably offline for some time due to the Internet provider update,
so will probably be able to continue to talk about this topic after that first.Who else has access to it I would be able to talk to?
It doesn't look like there is much of anything I can actually work on
since the infrastructure itself is uncloneable and inaccessible?ping?
I'm coming in a bit late here. Do you just need a clone of a build host to see how things are set up?
Thanks,
Steve
On Thu, Jun 12, 2014 at 4:21 PM, Stephen Zarkos
Stephen.Zarkos@microsoft.com wrote:
Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]On Tue, Jun 10, 2014 at 3:59 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Tue, Jun 10, 2014 at 3:29 PM, Anatol Belski anatol.php@belski.net
wrote:On Tue, Jun 10, 2014 at 2:56 PM, Anatol Belski
anatol.php@belski.net
wrote:Hi,
On Tue, Jun 3, 2014 at 2:53 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Hi,
I noticed you pushed bunch of changes to the repo just which
seem to actually have been live for a while.. Does the build
host update from some other repo I would need to merge up to?that's the github OSTC repo forked from rmtools somewhen,
havent
synced for a while. As that system is a prerunner for what we
gonna have with the travis integration, it doesn't really matter.
As besides
the snapshot builds running tests is also the topic, which is
much finer done with travis. Probably also a good thing to
deliberate before starting to do something.I think we just did that and have a solid plan I can work on.
Since attempting to duplicate the machinery is clearly impossible
task without having access to the current setup I would need to
work blind folded with trial and error here and there - which is
why I asked can I somehow see any logs (and to confirm, it is
running the rmtools repo on git.php.net you pointed me too, right?).
Alternatively, if I can get
access to the infrastructure that would be best.Any updates?
Feel like I am slacklining in a pitch dark cave above a lake full
of piranha :) If this is maintained on a vm or something I can
replicate it would be awesomest...yes, that's a VM but a clone is out of a question as there are too
much things there we can't simply "revert" to anonymize it. Btw. i
really think travis-ci integration were interesting to keep in
mind, as that would probably turn the whole thing upside down.Can I get access to the server then while I attempt to develop these
patches?actually that is out of my competention, but i guess it's the same as
with the vm clone. I'm going OOF for the next three weeks, and
probably offline for some time due to the Internet provider update,
so will probably be able to continue to talk about this topic after that first.Who else has access to it I would be able to talk to?
It doesn't look like there is much of anything I can actually work on
since the infrastructure itself is uncloneable and inaccessible?ping?
I'm coming in a bit late here. Do you just need a clone of a build host to see how things are set up?
Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.
-Hannes
On Thu, Jun 12, 2014 at 4:52 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Thu, Jun 12, 2014 at 4:21 PM, Stephen Zarkos
Stephen.Zarkos@microsoft.com wrote:Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]On Tue, Jun 10, 2014 at 3:59 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Tue, Jun 10, 2014 at 3:29 PM, Anatol Belski anatol.php@belski.net
wrote:On Tue, Jun 10, 2014 at 2:56 PM, Anatol Belski
anatol.php@belski.net
wrote:Hi,
On Tue, Jun 3, 2014 at 2:53 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Hi,
I noticed you pushed bunch of changes to the repo just which
seem to actually have been live for a while.. Does the build
host update from some other repo I would need to merge up to?that's the github OSTC repo forked from rmtools somewhen,
havent
synced for a while. As that system is a prerunner for what we
gonna have with the travis integration, it doesn't really matter.
As besides
the snapshot builds running tests is also the topic, which is
much finer done with travis. Probably also a good thing to
deliberate before starting to do something.I think we just did that and have a solid plan I can work on.
Since attempting to duplicate the machinery is clearly impossible
task without having access to the current setup I would need to
work blind folded with trial and error here and there - which is
why I asked can I somehow see any logs (and to confirm, it is
running the rmtools repo on git.php.net you pointed me too, right?).
Alternatively, if I can get
access to the infrastructure that would be best.Any updates?
Feel like I am slacklining in a pitch dark cave above a lake full
of piranha :) If this is maintained on a vm or something I can
replicate it would be awesomest...yes, that's a VM but a clone is out of a question as there are too
much things there we can't simply "revert" to anonymize it. Btw. i
really think travis-ci integration were interesting to keep in
mind, as that would probably turn the whole thing upside down.Can I get access to the server then while I attempt to develop these
patches?actually that is out of my competention, but i guess it's the same as
with the vm clone. I'm going OOF for the next three weeks, and
probably offline for some time due to the Internet provider update,
so will probably be able to continue to talk about this topic after that first.Who else has access to it I would be able to talk to?
It doesn't look like there is much of anything I can actually work on
since the infrastructure itself is uncloneable and inaccessible?ping?
I'm coming in a bit late here. Do you just need a clone of a build host to see how things are set up?
Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.
ping?
-Hannes
On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.
We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.
Good news that MongoDB has Windows and MSDN licenses.. Can you
elaborate how that is related to the pecl.php.net windows build
infrastructure?
I am attempting to make sure mine, or anyone elses for that matter,
commits to this 'rmtools' repository don't break stuff.
For that I need one or more of the following two things:
- Access to the logs/servers
- Duplicate the server setup
software as well. If you do not, please let me know so I can provide
you what you need.
I would very much appreciate that.
-Hannes
On Sat, Jun 14, 2014 at 6:31 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.Good news that MongoDB has Windows and MSDN licenses.. Can you
elaborate how that is related to the pecl.php.net windows build
infrastructure?
I was not sure what you referred to here. But now it is. You refer to
the build infrastructure only.
Please let me summarize again what has been said previously:
- semi automatic build using rmtools
- rmtools is pretty easy to understand, it wraps what one has to do
manually in php - most of its code is about generating human friendly reports (build
log or analyzers) - mid term (within a couple of months), travis will be used. I
repeat: Travis-ci will be used for this task.
- rmtools is pretty easy to understand, it wraps what one has to do
I am attempting to make sure mine, or anyone elses for that matter,
commits to this 'rmtools' repository don't break stuff.
For that I need one or more of the following two things:
- Access to the logs/servers
Build logs or something else?
Build logs are sent to the extension developers on error and are part
of the builds archives. You can fetch them on windows.php.net.
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 6:31 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.Good news that MongoDB has Windows and MSDN licenses.. Can you
elaborate how that is related to the pecl.php.net windows build
infrastructure?I was not sure what you referred to here. But now it is. You refer to
the build infrastructure only.Please let me summarize again what has been said previously:
- semi automatic build using rmtools
- rmtools is pretty easy to understand, it wraps what one has to do
manually in php- most of its code is about generating human friendly reports (build
log or analyzers)- mid term (within a couple of months), travis will be used. I
repeat: Travis-ci will be used for this task.
And I forgot to mention the on going work on Pickle, which aims to
replace the pecl installer, to install/compile PHP extensions, on all
supported platforms, from source or binaries. So far we did not get
any feedback from core or extension developers but Johannes on IRC.
This is the future, let focus on that. The sooner we have this tool
done, the easier it will be to have win snapshots builds in place for
anyone willing to do it. Indeed we will use it in travis as well and
provides the snaps on pecl.php.net as well.
I am attempting to make sure mine, or anyone elses for that matter,
commits to this 'rmtools' repository don't break stuff.
For that I need one or more of the following two things:
- Access to the logs/servers
Build logs or something else?
Build logs are sent to the extension developers on error and are part
of the builds archives. You can fetch them on windows.php.net.
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?
--
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 6:31 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.Good news that MongoDB has Windows and MSDN licenses.. Can you
elaborate how that is related to the pecl.php.net windows build
infrastructure?I was not sure what you referred to here. But now it is. You refer to
the build infrastructure only.
Yes, this thread is about the Windows binaries for PECL extensions -
and how I can implement snapshot capabilities into that
infrastructure.
Please let me summarize again what has been said previously:
- semi automatic build using rmtools
- rmtools is pretty easy to understand, it wraps what one has to do
manually in php- most of its code is about generating human friendly reports (build
log or analyzers)- mid term (within a couple of months), travis will be used. I
repeat: Travis-ci will be used for this task.
If you scroll up to the first couple of message of this thread you see
Anatol saying although it is on his todo list he doesn't have the time
for it.
That was in reply to me saying I would like to implement this.
And I forgot to mention the on going work on Pickle, which aims to
replace the pecl installer, to install/compile PHP extensions, on all
supported platforms, from source or binaries. So far we did not get
Thats excellent.
As you know, I've been throwing around ideas for replacement tool too.
Along with replacing just the installer, the "channel" stuff should
probably go away to.
I've also more recently wanting to provide a tool where you only get
PHP when installing PHP. Then you can upgrade things independently -
why should I need to upgrade mysqlnd and all mysql* extension when I
just need that curl fix? Or fix for CVE...? :/ see:
http://bjori.blogspot.com/2014/05/i-have-dream.html
Toying around the idea of having binaries available for the most
popular platforms - for php too - using something like
https://build.opensuse.org/ has been kicked around too.
What it boils down to is - an installer isn't actually difficult to
create. It is dependency management that is complicated - and that has
to be fixed in php-src really.
In anycase - this is not what this thread is about.. All I am trying
to do here is to be able to develop snapshot functionality into the
PECL Windows binary infrastructure - preferably not blind in a cave -
so getting access to deployment logs, php error logs etc etc etc, or
access to the server, or someone describing what exactly the
infrastructure is running so I can replicate it ... That is what I am
asking for.
I would appreciate help getting that up. Doing this blindly in a cave
will inevitably result in breaking something, which I am trying very
very hard to avoid happening.
any feedback from core or extension developers but Johannes on IRC.
This is the future, let focus on that. The sooner we have this tool
done, the easier it will be to have win snapshots builds in place for
anyone willing to do it. Indeed we will use it in travis as well and
provides the snaps on pecl.php.net as well.
Wait.. Are you saying the tool is going to be capable of doing Windows builds?
I am attempting to make sure mine, or anyone elses for that matter,
commits to this 'rmtools' repository don't break stuff.
For that I need one or more of the following two things:
- Access to the logs/servers
Build logs or something else?
Build logs are sent to the extension developers on error and are part
of the builds archives. You can fetch them on windows.php.net.
Those are user logs. Not logs from the system upgrading itself from
git, runetime logs, cronjob logs, php error log, and whatever else the
chain of execution really is.
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?
I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?
-Hannes
On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?
Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?
-Hannes
On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?
Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.
But as I said ealier, it is not good to begin to change that now. It
is used for the core as well and I really do not want to break it
while we will rely on pickle as soon as it is ready.
The only part of rmtools we will use are the log parsers and error
reporting parts.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.
So to clarify: I am not allowed to work on snapshot capabilities for
PECL extensions?
Furthermore you have no intentions of telling us which exact repo is
being used? (from what I can tell, its not actually the repo on
git.php.net - but your corporate repository that we cannot push to?)
I appreciate your help in clarifying my concerns.
I have been trying to get this implemented for an long long time now
but you guys seem to be very much against "external" contributions :(
-Hannes
On Sat, Jun 14, 2014 at 6:04 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.So to clarify: I am not allowed to work on snapshot capabilities for
PECL extensions?
No, that's not what I said. Please re read carefully.
Furthermore you have no intentions of telling us which exact repo is
being used? (from what I can tell, its not actually the repo on
git.php.net - but your corporate repository that we cannot push to?)
We have no private repo. And I have no time to argue about such FUDs.
I appreciate your help in clarifying my concerns.
I have been trying to get this implemented for an long long time now
but you guys seem to be very much against "external" contributions :(
Take it like that if you like to, I told you the roadmap and what is
being done (and not only by my team). You do not want to understand
it, your call.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 6:04 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.So to clarify: I am not allowed to work on snapshot capabilities for
PECL extensions?No, that's not what I said. Please re read carefully.
Furthermore you have no intentions of telling us which exact repo is
being used? (from what I can tell, its not actually the repo on
git.php.net - but your corporate repository that we cannot push to?)We have no private repo. And I have no time to argue about such FUDs.
I appreciate your help in clarifying my concerns.
I have been trying to get this implemented for an long long time now
but you guys seem to be very much against "external" contributions :(Take it like that if you like to, I told you the roadmap and what is
being done (and not only by my team). You do not want to understand
it, your call.
Excellent. So pushes to
http://git.php.net/?p=web/rmtools.git;a=summary are automatically
deployed every hour? Or is it once a day?
Thank you for your transparency, it is a great help to us all.
-Hannes
On Sat, Jun 14, 2014 at 6:56 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
On Sat, Jun 14, 2014 at 6:04 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.So to clarify: I am not allowed to work on snapshot capabilities for
PECL extensions?No, that's not what I said. Please re read carefully.
Furthermore you have no intentions of telling us which exact repo is
being used? (from what I can tell, its not actually the repo on
git.php.net - but your corporate repository that we cannot push to?)We have no private repo. And I have no time to argue about such FUDs.
I appreciate your help in clarifying my concerns.
I have been trying to get this implemented for an long long time now
but you guys seem to be very much against "external" contributions :(Take it like that if you like to, I told you the roadmap and what is
being done (and not only by my team). You do not want to understand
it, your call.Excellent. So pushes to
http://git.php.net/?p=web/rmtools.git;a=summary are automatically
deployed every hour? Or is it once a day?
I have to check.
But again, do PRs pls. This code is used for the core as well and RMs
relies on it to valid releases etc.
And again, this is not what we will use for pecl snapshots, not for
the build part. So can you please understand that and stop pushing
that all of a sudden while we are working on the final solution?
Thanks.
--
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 6:56 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 6:04 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 5:50 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
- Duplicate the server setup
Should not be too hard. Do you have a windows VM with VC + SDK
installed at hand?I imagine the build infrastructure is however sensitive to versions -
so which Windows version do I need, VC, ..?Windows 7+.
VC depends on the PHP version, as usual.
Did you try to build php on windows, manually?
Sure, lets say that works flawlessly.
It does yes.
What else do I need to replicate whatever does the binaries for PECL extensions?
Does the system update automatically daily from the php repo?
When I push my fixes, when will they be rolled out to the server?Please do PRs, if needed. But it has to be a serious blocking issue to
be applied at this point.So to clarify: I am not allowed to work on snapshot capabilities for
PECL extensions?No, that's not what I said. Please re read carefully.
Furthermore you have no intentions of telling us which exact repo is
being used? (from what I can tell, its not actually the repo on
git.php.net - but your corporate repository that we cannot push to?)We have no private repo. And I have no time to argue about such FUDs.
I appreciate your help in clarifying my concerns.
I have been trying to get this implemented for an long long time now
but you guys seem to be very much against "external" contributions :(Take it like that if you like to, I told you the roadmap and what is
being done (and not only by my team). You do not want to understand
it, your call.Excellent. So pushes to
http://git.php.net/?p=web/rmtools.git;a=summary are automatically
deployed every hour? Or is it once a day?I have to check.
Please do. Anatol recently pushed ~50 commits to that repo that had
been live for a long time, so it does not look like it. I have asked
this question frequently in this thread. Your latest answer was "stop
spreading FUD"?!?
If you stop being excessively passive aggressive and stop derailing
every discussion and simply answer the question we would get much
better along - and safe sooooo much time.
But again, do PRs pls. This code is used for the core as well and RMs
relies on it to valid releases etc.
I've no interest in touching that code. All I am trying to work on is
creating a pecl build on-demand to verify it builds before actually
rolling out a release. Upon succeeding doing that, the ideas Anatol
and I came up with earlier in this thread will be worked on.
And again, this is not what we will use for pecl snapshots, not for
the build part. So can you please understand that and stop pushing
that all of a sudden while we are working on the final solution?
Great. So where can I implement this functionality? What will be used?
For the past now 3weeks we have been discussing this subject and not
until you decide to derail the discussion has it ever been brought up
before that anything else will be used.
So please understand that you need to be transparent, even within your
own team, since they clearly have no idea.
-Hannes
On Sat, Jun 14, 2014 at 7:35 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Please do. Anatol recently pushed ~50 commits to that repo that had
been live for a long time, so it does not look like it. I have asked
this question frequently in this thread. Your latest answer was "stop
spreading FUD"?!?
About your corporate BS as usual. Get over it, it only adds noises to
your signal.
If you stop being excessively passive aggressive and stop derailing
every discussion and simply answer the question we would get much
better along - and safe sooooo much time.
I told you what is being done, what is the plan, what we are working
on, my team and other, which has been involved in these tasks, for
very long. You have a sudden need/interest to give snapshot a boost?
Very good, come over and contribute to the right place.
However, insisting/harrasing us about the wrong tool for the right
task is not going to bring us anywhere but in yet another painful
discussion.
But again, do PRs pls. This code is used for the core as well and RMs
relies on it to valid releases etc.I've no interest in touching that code. All I am trying to work on is
creating a pecl build on-demand to verify it builds before actually
rolling out a release. Upon succeeding doing that, the ideas Anatol
and I came up with earlier in this thread will be worked on.
As I told you many times already, this not what will be used for
snapshots, on demand or not.
Our team (which Anatol is part of) has worked on rmtools to ease our
work with pecl's extension, as a temporary solution. The plan remains
what i have described in your very first post.
And again, this is not what we will use for pecl snapshots, not for
the build part. So can you please understand that and stop pushing
that all of a sudden while we are working on the final solution?Great. So where can I implement this functionality? What will be used?
For the past now 3weeks we have been discussing this subject and not
until you decide to derail the discussion has it ever been brought up
before that anything else will be used.
So please understand that you need to be transparent, even within your
own team, since they clearly have no idea.
They clearly have a good idea, and I can discuss that daily, be on the
lists or directly. But you insist on using something that won't be
used for pecl builds. Understand that.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Sat, Jun 14, 2014 at 7:35 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Please do. Anatol recently pushed ~50 commits to that repo that had
been live for a long time, so it does not look like it. I have asked
this question frequently in this thread. Your latest answer was "stop
spreading FUD"?!?About your corporate BS as usual. Get over it, it only adds noises to
your signal.If you stop being excessively passive aggressive and stop derailing
every discussion and simply answer the question we would get much
better along - and safe sooooo much time.I told you what is being done, what is the plan, what we are working
on, my team and other, which has been involved in these tasks, for
very long. You have a sudden need/interest to give snapshot a boost?
Very good, come over and contribute to the right place.
Where is that place?
Let me repeat, in case your english is just that bad: I would like to
develop snapshot capabilities into the Windows PECL build
infrastructure.
It was your people that told me this should be implemented into
rmtools, look a the early start of this thread before you started
making stuff up.
I don't care which tool I need to work on to get it done. If its
better to build it into some other tools then please tell me. I cannot
read your mind.
However, insisting/harrasing us about the wrong tool for the right
It was Anatol:
"rmtools can be adapted which would spare time. That's effectively a"
if that is not correct, it is not my fault and you need to apologize
for how you have been acting in this conversation.
I don't care what tool I need to modify to get this implemented. I
have no existing stake in the matter and honestly don't care for any
political powers that may or may not be involved.
I repeat again for your pleasure: I would like to contribute this
functionality. Which project do you want it in? And where is the
current canonical source for it?
task is not going to bring us anywhere but in yet another painful
discussion.
I don't know what is up your ass, but until you joined this thread it
was going just fine.
It is your endless twisting people words, lies, pretending to do
something and destructive attitude that kills any attempt by
volunteers to join the project - and current contributors to steer
away.
But again, do PRs pls. This code is used for the core as well and RMs
relies on it to valid releases etc.I've no interest in touching that code. All I am trying to work on is
creating a pecl build on-demand to verify it builds before actually
rolling out a release. Upon succeeding doing that, the ideas Anatol
and I came up with earlier in this thread will be worked on.As I told you many times already, this not what will be used for
snapshots, on demand or not.Our team (which Anatol is part of) has worked on rmtools to ease our
work with pecl's extension, as a temporary solution. The plan remains
what i have described in your very first post.
Then if he is misunderstanding something and this shouldn't be
implemented into rmtools, then I ask again: Where should it be
implemented?
Please answer with a link to the repository (and branch if relevant)
to safe us from needing to talk more to eachother.
And again, this is not what we will use for pecl snapshots, not for
the build part. So can you please understand that and stop pushing
that all of a sudden while we are working on the final solution?Great. So where can I implement this functionality? What will be used?
For the past now 3weeks we have been discussing this subject and not
until you decide to derail the discussion has it ever been brought up
before that anything else will be used.
So please understand that you need to be transparent, even within your
own team, since they clearly have no idea.They clearly have a good idea, and I can discuss that daily, be on the
lists or directly. But you insist on using something that won't be
used for pecl builds. Understand that.
I have not insisted on anything other then finding out where the
system is, how I can replicate it so I can develop new functionality
for it.
The only thing I am insisting on is to get answers.
-Hannes
On Sat, Jun 14, 2014 at 4:31 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
any feedback from core or extension developers but Johannes on IRC.
This is the future, let focus on that. The sooner we have this tool
done, the easier it will be to have win snapshots builds in place for
anyone willing to do it. Indeed we will use it in travis as well and
provides the snaps on pecl.php.net as well.Wait.. Are you saying the tool is going to be capable of doing Windows builds?
Indeed, phpize already works (except deps but this tool will fix that)
on Windows.
Also please read this draft RFC.
I am attempting to make sure mine, or anyone elses for that matter,
commits to this 'rmtools' repository don't break stuff.
For that I need one or more of the following two things:
- Access to the logs/servers
Build logs or something else?
Build logs are sent to the extension developers on error and are part
of the builds archives. You can fetch them on windows.php.net.Those are user logs. Not logs from the system upgrading itself from
git, runetime logs, cronjob logs, php error log, and whatever else the
chain of execution really is.
Unless we publish somewhere no, it is not public.
--
Pierre
@pierrejoye | http://www.libgd.org
I can setup a Windows server with RMTools which you can remotely use to
work with PECL extensions.
I'll reply off this list with the login info.
Regards
-M
On Sat, Jun 14, 2014 at 4:36 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Something like that yes. I need something I can test my changes on so
I don't push completely broken code.
A vm clone of the build host would fantastic as I could test the
entire process completely.We can't provide images of a full host. However all dependencies, both
sources and binaries, are available http://windows.php.net/downloads/,
be in pecl's (non core dependencies) or php-sdk deps (everything used
for the core). It is pretty straight forward to use. Mongodb has
windows and msdn licenses, so you should have access to all the
software as well. If you do not, please let me know so I can provide
you what you need.Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I can setup a Windows server with RMTools which you can remotely use to work
with PECL extensions.I'll reply off this list with the login info.
Sorry Matt, but that VM is planed for automated builds not for
development or testing. Just to clarify.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
2014.06.16. 19:00, "Pierre Joye" pierre.php@gmail.com ezt írta:
On Mon, Jun 16, 2014 at 6:51 PM, Matt Ficken themattficken@gmail.com
wrote:I can setup a Windows server with RMTools which you can remotely use to
work
with PECL extensions.I'll reply off this list with the login info.
Sorry Matt, but that VM is planed for automated builds not for
development or testing. Just to clarify.
You lack the time to set up another vm for development, or the hardware?
I'm glad that you have a clear roadmap for the pipelined pecl builds, but I
still think that it would be nice if the development would be more
transparent and there would be an easy way for others to chip in if they
want.
I don't really mind if you decide that the development/maintenance of some
tools/services are off limit for the non Microsoft personels, but then
those tools/services should be hosted outside of the php.net domain.
So could you please
1, make sure that the rmtools is running from a repo hosted on git.php.net
and periodically updated.
2, add that repo to the global_avail using an existing group or defining a
new
3, put together some docs about setting up/replicating a local development
environment.
thank you!
2014.06.16. 19:00, "Pierre Joye" pierre.php@gmail.com ezt írta:
On Mon, Jun 16, 2014 at 6:51 PM, Matt Ficken themattficken@gmail.com
wrote:I can setup a Windows server with RMTools which you can remotely use to
work
with PECL extensions.I'll reply off this list with the login info.
Sorry Matt, but that VM is planed for automated builds not for
development or testing. Just to clarify.You lack the time to set up another vm for development, or the hardware?
I'm glad that you have a clear roadmap for the pipelined pecl builds, but I
still think that it would be nice if the development would be more
transparent and there would be an easy way for others to chip in if they
want.I don't really mind if you decide that the development/maintenance of some
tools/services are off limit for the non Microsoft personels, but then those
tools/services should be hosted outside of the php.net domain.
we do not provide access within our infrastructure. Eventually via
external hosters from time to time but I'd rather provide msdn
licenses to developers for testing/devs instead of providing many VMs.
And that's what we do, easier for everyone, works with linux, mac or
windows hosts (laptop or whatever)
So could you please
1, make sure that the rmtools is running from a repo hosted on git.php.net
and periodically updated.
2, add that repo to the global_avail using an existing group or defining a
new
it does, as stated numerous time in the list. And PRs/Patches will be
reviewed. We only won't use rmtools build parts for pecl snapshot or
release builds in the mid term, especially as it was a hack to help
windows users to get DLLs for releases. See my other replies for the
explanation (and sorry that you will have to go through bad replies to
get that info).
--
Pierre
@pierrejoye | http://www.libgd.org
2014.06.16. 19:00, "Pierre Joye" pierre.php@gmail.com ezt írta:
On Mon, Jun 16, 2014 at 6:51 PM, Matt Ficken themattficken@gmail.com
wrote:I can setup a Windows server with RMTools which you can remotely use
to
work
with PECL extensions.I'll reply off this list with the login info.
Sorry Matt, but that VM is planed for automated builds not for
development or testing. Just to clarify.You lack the time to set up another vm for development, or the hardware?
I'm glad that you have a clear roadmap for the pipelined pecl builds,
but I
still think that it would be nice if the development would be more
transparent and there would be an easy way for others to chip in if they
want.I don't really mind if you decide that the development/maintenance of
some
tools/services are off limit for the non Microsoft personels, but then
those
tools/services should be hosted outside of the php.net domain.we do not provide access within our infrastructure. Eventually via
external hosters from time to time but I'd rather provide msdn
licenses to developers for testing/devs instead of providing many VMs.
And that's what we do, easier for everyone, works with linux, mac or
windows hosts (laptop or whatever)So could you please
1, make sure that the rmtools is running from a repo hosted on
git.php.net
and periodically updated.
2, add that repo to the global_avail using an existing group or defining
a
newit does, as stated numerous time in the list.
I must have missed those mails, but based on the recent bulk of
commits(pushed on jun 3, commits dating back to april) I also assumed that
the production code is not updated through git, but vica versa.
The reply from Anatol didn't really helped to clear that up:
http://news.php.net/php.pecl.dev/11868
So assuming that I commit+push something to the master branch of
http://git.php.net/?p=web/rmtools.git;a=summary would that show up
automatically?
And PRs/Patches will be
reviewed. We only won't use rmtools build parts for pecl snapshot or
release builds in the mid term, especially as it was a hack to help
windows users to get DLLs for releases.
I don't mind if you want to review the changes, I just don't want to block
others who are willing to work.
Worse case Hannes never finds the time to contribute or he does and that
will be a wasted effort when the new pickle based autobuild system is
finished. I don't think that we have anything to lose here, and I'm fairly
sure that Hannes is willing to risk his work being wasted.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Mon, 2014-06-16 at 20:31 +0200, Ferenc Kovacs wrote:
2014.06.16. 19:00, "Pierre Joye" pierre.php@gmail.com ezt írta:
On Mon, Jun 16, 2014 at 6:51 PM, Matt Ficken themattficken@gmail.com
wrote:I can setup a Windows server with RMTools which you can remotely use to
work
with PECL extensions.I'll reply off this list with the login info.
Sorry Matt, but that VM is planed for automated builds not for
development or testing. Just to clarify.You lack the time to set up another vm for development, or the hardware?
I'm glad that you have a clear roadmap for the pipelined pecl builds, but I
still think that it would be nice if the development would be more
transparent and there would be an easy way for others to chip in if they
want.I don't really mind if you decide that the development/maintenance of some
tools/services are off limit for the non Microsoft personels, but then
those tools/services should be hosted outside of the php.net domain.So could you please
1, make sure that the rmtools is running from a repo hosted on git.php.net
and periodically updated.
2, add that repo to the global_avail using an existing group or defining a
new
3, put together some docs about setting up/replicating a local development
environment.thank you!
I agree with Pierre that we should move to the pickle and travis
infrastructure. The advantages I see
- composer support
- no dependency on the whole pecl commando and the libs behind it
- consistency for all platforms
- ability not only to build, but also to run tests
- that keeps step with the todays world
I will not support extending the current with snaps but rather going to
enclose myself to the pickle development from July on. Another way to go
extending the current builds with snaps seems to be a waste of time in
the light of the current tendency.
The system isn't updated from git automatically, but the code is open
and is on github. The repositories are known but even though one didn't
know or could haven't found them and asked - here were the answer. I've
synced it right because Hannes asked for it, but otherwise it's in
github.com/ostc . It was synced from time to time, but rarely because
literally nobody actually was interested in developing it.
The actual VM cannot be cloned and given away neither it can be accessed
because it's on the corporate infrastructure and that's a potential
security risk. The same for the clone, as it would have to be cleaned
up, but still it's too much integrated into the local services. Also,
the same repository is used to do the core builds. Evermore, if you look
into the rmtools code - there's an approach to do that on any platforms
(things like unimplemented classes for that). I don't think there is
something specific to MS here, but to a usual security. I'm not sure why
one could see it bad - there are physical machines somewhere, they
consume juice and traffic, they host dozen VMs for build and tests, the
builds are openly available, sources one way or the other.
The easiest way is to clone from the repo and setup from it. Also, about
the docs - the same is with any other thing I ever touched related to
the php.net sites. Like the code from pecl.php.net - I had to take the
repository and to spend some hours on setting up a dummy worky site.
Because I know it's updated automatically, just to code blindly and push
with hope it's gonna be good were obviously nogo. The same about setting
up a custom pecl site/channel - that was fun once I wanted to do it
years ago. But anyway - that's my experience.
I've also an offtop word before I go, as my connection is a subject of
luck now. I think there is evermore non technical discussion and I
personally feel blocked by that. That snap build functionality for
instance could be already in place and running a while ago if the other
things we've spent a huge amount of time on weren't blocked ... just
because. Heh, really demotivating stuff ...
Best regards
Anatol