On Mon, 2014-06-16 at 20:31 +0200, Ferenc Kovacs wrote: > 2014.06.16. 19:00, "Pierre Joye" <[email protected]> ezt írta: > > > > On Mon, Jun 16, 2014 at 6:51 PM, Matt Ficken <[email protected]> > 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 -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
