Thanks Chris, so I will cut the release this evening. Cheers,
Vincent 2009/4/22 Chris Chabot <[email protected]>: > I've done my final test rounds for the php release, and everything checks > out perfectly. > > Release are go! > > On Tue, Apr 21, 2009 at 7:02 PM, Ian Boston <[email protected]> wrote: > >> The 1.0 release will come from the branch at >> http://svn.apache.org/repos/asf/incubator/shindig/branches/1.0.x-incubating/ >> >> When its cut, there will be a tag, the final details are being sorted out. >> Ian >> >> >> On 21 Apr 2009, at 01:49, Carmen Sarlo wrote: >> >> How can I check out the 1.0 release? Is there a new branch cut? Do I have >>> to >>> check out up to a certin rev? >>> >>> >>> >>> Carmen >>> >>> >>> On Sat, Apr 18, 2009 at 6:53 AM, Santiago Gala <[email protected] >>> >wrote: >>> >>> El mié, 15-04-2009 a las 15:57 +0200, Chris Chabot escribió: >>>> >>>>> On Wed, Apr 15, 2009 at 3:28 PM, Vincent Siveton >>>>> <[email protected]>wrote: >>>>> >>>>> 2009/4/15 Chris Chabot <[email protected]>: >>>>>> >>>>>>> I spoke yesterday with Chris about the make-release.sh: this script >>>>>>>> won't work on my ubuntu box :( >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Vincent I thought the fix was simple enough: >>>>>>> >>>>>> >>>>>> Yes yes the fix was working perfectly :) >>>>>> >>>>>> Saying that "it won't work on ubuntu" is a slight over-exaggeration >>>>>>> >>>>>> in my >>>> >>>>> opinion :) >>>>>>> >>>>>> >>>>>> Sorry if I offend you, my point was that the out-of-box script needs >>>>>> to be changed depending the platform used for the compilation. >>>>>> >>>>>> >>>>> No worries, no offense of any kind is involved! I'm merely trying to say >>>>> that a sh shell is by far more pervasive then a java & maven combo, >>>>> >>>> perhaps >>>> >>>>> I should've framed that differently :) >>>>> >>>>> The problem is that 'bash' isn't defined by the FHS (Filesystem >>>>> Hierarchy >>>>> Standard) on linux, the solution is to, instead of depending on a fixed >>>>> >>>> path >>>> >>>>> (#!/bin/bash), I should either a) change it to #!`which bash`, which >>>>> will >>>>> expand to the location of bash, or b) change the script to use >>>>> #!/bin/sh, >>>>> which is present on pretty much any *nix platform we care about (*bsd, >>>>> linux, mac, solaris, etc); So I'm likely to pick option b here. >>>>> >>>>> >>>> In my ubuntu boxes bash is in /bin/bash, as it should. :) I'm not sure >>>> what the problem was. If it was the ubuntu-server flavor, it is quite >>>> minimalistic as it installs (not even python, for instance), so it might >>>> have been missing bash, and having other shell. >>>> >>>> However sh will be installed on pretty much anywhere (except for win, >>>>> >>>> who'd >>>> >>>>> have to install cygwin) and the same can't be said for java and maven, >>>>> >>>> which >>>> >>>>> won't be present on most of the boxes that will be running >>>>> >>>> php-shindig.... >>>> >>>>> after all, if they had a complete java stack and maven installed that >>>>> >>>> would >>>> >>>>> imply their likely a java shop and they would thus more likely be using >>>>> java-shindig :) >>>>> >>>>> >>>> ubuntu needs frequently wiping of the java packages and install of the >>>> sun jdk for some applications to run correctly, in my experience. I lost >>>> some time fighting against openjdk and icedtea recently to be forced to >>>> install sun-java6-jdk finally to run some legacy java apps. >>>> >>>> Regards >>>> Santiago >>>> >>>> >>>>> (i did make a mental note I should probably use /bin/sh though since >>>>>>> according to the FHS that should always be available, but i'll have >>>>>>> >>>>>> to >>>> >>>>> validate that the script works the same on sh first before i can >>>>>>> >>>>>> switch >>>> >>>>> that >>>>>> >>>>>>> over) >>>>>>> >>>>>>> Using Maven will be more platform independent, but Chris underlines >>>>>>> >>>>>> me >>>> >>>>> that the Maven assembly generates a different layout than the >>>>>>>> make-release.sh. >>>>>>>> So I modified the Maven files in r765148 to be align with this >>>>>>>> >>>>>>> script. >>>> >>>>> >>>>>>>> @Chris, could you review the generated and confirm that it is the >>>>>>>> >>>>>>> wanted >>>> >>>>> layout? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I also commented that I think this is a "When you have a hammer, >>>>>>> >>>>>> everything >>>>>> >>>>>>> looks like a nail" type of solution. >>>>>>> >>>>>>> Most people who use PHP probably won't have a lot of java and maven >>>>>>> knowledge, and are even likely not to even have a working java binary >>>>>>> installed, let alone feeling like installing maven and downloading >>>>>>> >>>>>> many >>>> >>>>> Mb's >>>>>> >>>>>>> of dependencies and we really shouldn't force that down people's >>>>>>> >>>>>> throats, >>>> >>>>> not if those tens of megabytes, and different-environment >>>>>>> >>>>>> dependencies >>>> >>>>> are >>>>>> >>>>>>> just to solve something that can also be done with 20 lines of shell >>>>>>> >>>>>> script. >>>>>> >>>>>>> That just sounds like a solution looking for a problem :) >>>>>>> >>>>>>> Keep in mind that this script could be used to create a >>>>>>> >>>>>> release-type-layout >>>>>> >>>>>>> of the directory structure and configuration files by anyone who uses >>>>>>> php-shindig, so the usage of it is far wider then just once to >>>>>>> >>>>>> generate a >>>> >>>>> release tarbal, as such the whole java / mvn dep could only be worth >>>>>>> >>>>>> it >>>> >>>>> from >>>>>> >>>>>>> a php perspective if it offered significant benefits over shell >>>>>>> >>>>>> script >>>> >>>>> (or >>>>>> >>>>>>> even php based) one.. >>>>>>> >>>>>> >>>>>> I guess only Shindig devs could use this script to make a release and >>>>>> (I hope) everybody here has a minimum knowledge of java/maven :) >>>>>> If someone want to make a fork of PHP Shindig, he will probably create >>>>>> its own script to make its release. >>>>>> >>>>>> The script file works perfectly but it is platform dependent which is >>>>>> IMHO bad. >>>>>> >>>>> >>>>> >>>>> I can't agree with that argumentation. the sh shell is part of *every* >>>>> >>>> unix >>>> >>>>> like instalation, where as maven is something people will have to >>>>> >>>> download >>>> >>>>> the correct latest version of and install by hand; The statement that a >>>>> shell script using sh is platform dependent goes against decades of >>>>> >>>> history >>>> >>>>> (sh has been a standard part and default shell of most unix systems >>>>> since >>>>> it's inception in 1977) >>>>> >>>>> The only thing that somehow gave you that impression is that ubuntu (and >>>>> probably debian too by extend) have their bash shell in the /usr/bin >>>>> dir, >>>>> and not in /bin... thats the *only* thing, and that can very easily be >>>>> >>>> fixed >>>> >>>>> by using either `which bash` or using sh instead of bash. >>>>> >>>>> The nice thing of having a standard script is that if some OSS project >>>>> includes php-shindig (which quite a few do already), they can use that >>>>> standard script to wrangle the svn checkout to a standard layout that >>>>> >>>> they >>>> >>>>> can include (and without the whole java tree). Depending on java + maven >>>>> >>>> is >>>> >>>>> as un-natural to them as using a PHP tool for java packaging would be :) >>>>> >>>>> >>>>> >>>>> We need 2 release managers to create artifacts, and I dont >>>>>> think it is the way to go. >>>>>> If Maven is too bigger, WDYT to use ant? It will be easy to integrate >>>>>> it in the release process. >>>>>> >>>>> >>>>> >>>>> I think the whole premise of using a java packaging tool for php is akin >>>>> >>>> to >>>> >>>>> the hammer -> nail analogy... I see no problems with a release manager >>>>> running one shell script to create the php-shindig tar&zip archives, and >>>>> >>>> I >>>> >>>>> think most everybody here would be comfortable with that, right? >>>>> >>>>> >>>>> Do we want to centralize build under Maven, for all languages >>>>>> supported and for making release? >>>>>> >>>>>> >>>>> Pros: >>>>> 1) Unified release procedure for both languages >>>>> (I'm not including 'platform independence here, since to me introducing >>>>> java+maven deps into the php world is a much bigger restriction then >>>>> depending on the sh shell) >>>>> >>>>> Cons: >>>>> 1) Unmaintainable by the php dev's >>>>> 2) Un-usable for 3rd party projects who don't have java/maven/etc but >>>>> >>>> want >>>> >>>>> to do svn snapshots >>>>> 3) Using an overly complex solution for something that has a simple >>>>> >>>> solution >>>> >>>>> available already >>>>> >>>>> So far based on the above +/- list my preference so far is to use the >>>>> >>>> shell >>>> >>>>> script >>>>> >>>> >>>> >>>> >> >
