You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Vincent Siveton <vs...@apache.org> on 2009/04/13 22:20:54 UTC
What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Hi Ian,
2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> I hate to bring it up again, but is it time to do a release on the 1.0.x
> branch ?
I am agree with you.
According Jira [1], we have 3 issues left and according the board
report, we plan to do a release of 1.0.x in this quarter.
So, could we fix them and make a release soon? Ping me if devs need help.
Cheers,
Vincent
[1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using
Maven snapshot repo
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 15-04-2009 a las 13:18 +0200, Chris Chabot escribió:
> The php's release script doesn't do any signing yet, but if your willing to
> send the instructions of the release signature standards are for apache I'd
> be happy to build that in
http://www.apache.org/dev/release-signing.html describes the generic
instructions, and
http://incubator.apache.org/guides/releasemanagement.html is a incubator
guide.
The first one contains relatively detailed signing instructions. I don't
have much experience in the incubator and how it differs from regular
releases, but the second document should tell.
Regards
Santiago
>
> On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala <sa...@gmail.com>wrote:
>
> > El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
> > > FYi the prefered packaging format for php-shindig is generated by the
> > > shindig/php/make-release.sh file.
> > >
> > > in the 1.0.x branch it's version is currently set on 1.0, so just
> > executing
> > > it will give you the appropriate php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
> > > files.
> > >
> > > I'll do a final test on them once you guys are release ready too, but in
> > > principle the 1.0.x branch & release script have been ready since nov
> > last
> > > year, so I don't expect any surprises on that end
> > >
> >
> > Is there provision for signing the releases? I can sign the keys of
> > whoever is going to do it if we get some out of band, remote way to
> > verify identity WRT keys signature.
> >
> > Regards
> > Santiago
> >
> > > -- Chris
> > >
> > > On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vsiveton@apache.org
> > >wrote:
> > >
> > > > I guess the plan should be:
> > > > * release discussions: done by this thread
> > > > * prepare the release: mvn release:prepare which tags the code
> > > > * make the release: mvn release:perform which pushes (signed)
> > > > artifacts to repository.apache.org
> > > > * stage the generated Maven documentation
> > > > * propose a vote on this list: mail should include the urls and the
> > > > closed/left issues.
> > > > * ask Incubator PMC for the release
> > > > * publish and announce the release
> > > >
> > > > Anything else?
> > > >
> > > > If everybody is agree with this plan, I could try to start the process
> > > > this week.
> > > >
> > > > Cheers,
> > > >
> > > > Vincent
> > > >
> > > > 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > > > > Being a release newbie with a desire to step into the unknown, what
> > needs
> > > > to
> > > > > be done ?
> > > > > presumably, build some artifacts, sign them, put them somewhere,
> > agree
> > > > that
> > > > > they should be the release, and then tell the incubator list we want
> > to
> > > > > release them ?
> > > > >
> > > > > Ian
> > > > >
> > > > > On 13 Apr 2009, at 21:52, Kevin Brown wrote:
> > > > >
> > > > >> None of those 3 issues are actually release blockers. No feature
> > request
> > > > >> is
> > > > >> ever a release blocker unless that feature was explicitly identified
> > as
> > > > >> critical for the release at the beginning.
> > > > >>
> > > > >> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
> > wrote:
> > > > >>
> > > > >>> I don't think we should wait for any of those issues. Release, and
> > > > >>> release again.
> > > > >>>
> > > > >>> -- Adam
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
> > vsiveton@apache.org>
> > > > >>> wrote:
> > > > >>>>
> > > > >>>> Hi Ian,
> > > > >>>>
> > > > >>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > > > >>>>>
> > > > >>>>> I hate to bring it up again, but is it time to do a release on
> > the
> > > > >>>>> 1.0.x
> > > > >>>>> branch ?
> > > > >>>>
> > > > >>>> I am agree with you.
> > > > >>>> According Jira [1], we have 3 issues left and according the board
> > > > >>>> report, we plan to do a release of 1.0.x in this quarter.
> > > > >>>> So, could we fix them and make a release soon? Ping me if devs
> > need
> > > > >>>> help.
> > > > >>>>
> > > > >>>> Cheers,
> > > > >>>>
> > > > >>>> Vincent
> > > > >>>>
> > > > >>>> [1]
> > > > >>>
> > > > >>>
> > > > >>>
> > > >
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
> > > > >>>>
> > > > >>>
> > > > >
> > > > >
> > > >
> >
> >
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using
Maven snapshot repo
Posted by Rodrigo Gallardo <ro...@nul-unu.com>.
On Wed, Apr 15, 2009 at 07:43:46AM -0700, Rodrigo Gallardo wrote:
> On Wed, Apr 15, 2009 at 12:33:22PM +0100, Ian Boston wrote:
> > I am probably too distant to anyone to do the signing, I running the
> > maven release:perform at the moment, but I dont think anything is
> > getting signed, or at least i am not being asked form gpg passphrase.
> >
> > Ian
>
> Probably one of the easiest ways to get nicely tied in into the global
> gpg web of trust is for (some of) the people here to get their keys
> signed by some Debian developer. We could simply make a list of
> everyone's location and send it to the debian-devel list, or I can
> make a request to the -private list if there are concerns about
> publicly posting that.
Or you could just cut the middleman and look for someone near you in
https://nm.debian.org/gpg_offer.php
I'd forgotten about that page :)
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using
Maven snapshot repo
Posted by Rodrigo Gallardo <ro...@nul-unu.com>.
On Wed, Apr 15, 2009 at 12:33:22PM +0100, Ian Boston wrote:
> I am probably too distant to anyone to do the signing, I running the
> maven release:perform at the moment, but I dont think anything is
> getting signed, or at least i am not being asked form gpg passphrase.
>
> Ian
Probably one of the easiest ways to get nicely tied in into the global
gpg web of trust is for (some of) the people here to get their keys
signed by some Debian developer. We could simply make a list of
everyone's location and send it to the debian-devel list, or I can
make a request to the -private list if there are concerns about
publicly posting that.
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
Yes it was at one point but I didn't see the gpg signing happening,
unless it was silent.
Ian
On 15 Apr 2009, at 13:12, Vincent Siveton wrote:
> Hi again,
>
> 2009/4/15 Ian Boston <ie...@tfd.co.uk>:
>> I am probably too distant to anyone to do the signing, I running
>> the maven
>> release:perform at the moment, but I dont think anything is getting
>> signed,
>> or at least i am not being asked form gpg passphrase.
>
> Your gpg.passphrase should be in your settings.xml
>
> BTW I guess that all artifacts (including php zip/tar) will be
> correctly signed now.
>
> Cheers,
>
> Vincent
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vi...@gmail.com>.
Hi again,
2009/4/15 Ian Boston <ie...@tfd.co.uk>:
> I am probably too distant to anyone to do the signing, I running the maven
> release:perform at the moment, but I dont think anything is getting signed,
> or at least i am not being asked form gpg passphrase.
Your gpg.passphrase should be in your settings.xml
BTW I guess that all artifacts (including php zip/tar) will be
correctly signed now.
Cheers,
Vincent
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
The release was 1/2 deployed, but after entering the password for the
101th time, I made a mistake, and deploy failed. Tried 3 times, and
gave up thinking that settings.xml was a better place, but couldn't
get that to work.
Ian
On 15 Apr 2009, at 13:16, Vincent Siveton wrote:
> Weird! I saw the files
> http://people.apache.org/repo/m2-incubating-repository/org/apache/shindig/
>
> Vincent
>
> 2009/4/15 Ian Boston <ie...@tfd.co.uk>:
>> I have tried to the do the mvn release:perform but failed.
>> For some reason I am unable to configure the username and password in
>> settings.xml and so eventually I mistype at the prompt.
>> Any suggestions ?
>> Currently ~/.m2/settings.xml looks like, I have tried both password
>> and
>> private keys without sucess
>>
>> <?xml version="1.0"?>
>> <settings>
>> <servers>
>> <server>
>> <id>apache.incubating</id>
>> <username>ieb</username>
>> <password>xxxxxxxxxxxxxxxxxxxxx</password>
>> </server>
>> </servers>
>> </settings>
>>
>>
>> I have validated the password as correct (obviously xxxx bear no
>> resemblance to my pw :)) on the command line.
>>
>> Unfortunately the deploy is not complete and so information at
>> scp://people.apache.org/www/people.apache.org/repo/m2-incubating-
>> repository/org/apache/shindig
>> and
>> scp://people.apache.org/www/incubator.apache.org/shindig/
>> shindig-1.0.x/
>>
>> is also going to be incomplete.
>>
>> I hope the later one didn't break anything (sorry if it did)
>> Ian
>>
>> On 15 Apr 2009, at 12:33, Ian Boston wrote:
>>
>>> I am probably too distant to anyone to do the signing, I running
>>> the maven
>>> release:perform at the moment, but I dont think anything is
>>> getting signed,
>>> or at least i am not being asked form gpg passphrase.
>>>
>>> Ian
>>>
>>>
>>> On 15 Apr 2009, at 12:18, Chris Chabot wrote:
>>>
>>>> The php's release script doesn't do any signing yet, but if your
>>>> willing
>>>> to
>>>> send the instructions of the release signature standards are for
>>>> apache
>>>> I'd
>>>> be happy to build that in
>>>>
>>>> On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala
>>>> <sa...@gmail.com>wrote:
>>>>
>>>>> El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
>>>>>>
>>>>>> FYi the prefered packaging format for php-shindig is generated
>>>>>> by the
>>>>>> shindig/php/make-release.sh file.
>>>>>>
>>>>>> in the 1.0.x branch it's version is currently set on 1.0, so just
>>>>>
>>>>> executing
>>>>>>
>>>>>> it will give you the appropriate
>>>>>> php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
>>>>>> files.
>>>>>>
>>>>>> I'll do a final test on them once you guys are release ready
>>>>>> too, but
>>>>>> in
>>>>>> principle the 1.0.x branch & release script have been ready
>>>>>> since nov
>>>>>
>>>>> last
>>>>>>
>>>>>> year, so I don't expect any surprises on that end
>>>>>>
>>>>>
>>>>> Is there provision for signing the releases? I can sign the keys
>>>>> of
>>>>> whoever is going to do it if we get some out of band, remote way
>>>>> to
>>>>> verify identity WRT keys signature.
>>>>>
>>>>> Regards
>>>>> Santiago
>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>> On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vsiveton@apache.org
>>>>>> wrote:
>>>>>>
>>>>>>> I guess the plan should be:
>>>>>>> * release discussions: done by this thread
>>>>>>> * prepare the release: mvn release:prepare which tags the code
>>>>>>> * make the release: mvn release:perform which pushes (signed)
>>>>>>> artifacts to repository.apache.org
>>>>>>> * stage the generated Maven documentation
>>>>>>> * propose a vote on this list: mail should include the urls
>>>>>>> and the
>>>>>>> closed/left issues.
>>>>>>> * ask Incubator PMC for the release
>>>>>>> * publish and announce the release
>>>>>>>
>>>>>>> Anything else?
>>>>>>>
>>>>>>> If everybody is agree with this plan, I could try to start the
>>>>>>> process
>>>>>>> this week.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Vincent
>>>>>>>
>>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>>
>>>>>>>> Being a release newbie with a desire to step into the
>>>>>>>> unknown, what
>>>>>
>>>>> needs
>>>>>>>
>>>>>>> to
>>>>>>>>
>>>>>>>> be done ?
>>>>>>>> presumably, build some artifacts, sign them, put them
>>>>>>>> somewhere,
>>>>>
>>>>> agree
>>>>>>>
>>>>>>> that
>>>>>>>>
>>>>>>>> they should be the release, and then tell the incubator list
>>>>>>>> we want
>>>>>
>>>>> to
>>>>>>>>
>>>>>>>> release them ?
>>>>>>>>
>>>>>>>> Ian
>>>>>>>>
>>>>>>>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>>>>>>>
>>>>>>>>> None of those 3 issues are actually release blockers. No
>>>>>>>>> feature
>>>>>
>>>>> request
>>>>>>>>>
>>>>>>>>> is
>>>>>>>>> ever a release blocker unless that feature was explicitly
>>>>>>>>> identified
>>>>>
>>>>> as
>>>>>>>>>
>>>>>>>>> critical for the release at the beginning.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer
>>>>>>>>> <aw...@google.com>
>>>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I don't think we should wait for any of those issues.
>>>>>>>>>> Release, and
>>>>>>>>>> release again.
>>>>>>>>>>
>>>>>>>>>> -- Adam
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
>>>>>
>>>>> vsiveton@apache.org>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Ian,
>>>>>>>>>>>
>>>>>>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>>>>>>
>>>>>>>>>>>> I hate to bring it up again, but is it time to do a
>>>>>>>>>>>> release on
>>>>>
>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> 1.0.x
>>>>>>>>>>>> branch ?
>>>>>>>>>>>
>>>>>>>>>>> I am agree with you.
>>>>>>>>>>> According Jira [1], we have 3 issues left and according
>>>>>>>>>>> the board
>>>>>>>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>>>>>>>> So, could we fix them and make a release soon? Ping me if
>>>>>>>>>>> devs
>>>>>
>>>>> need
>>>>>>>>>>>
>>>>>>>>>>> help.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Vincent
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
>>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vi...@gmail.com>.
Weird! I saw the files
http://people.apache.org/repo/m2-incubating-repository/org/apache/shindig/
Vincent
2009/4/15 Ian Boston <ie...@tfd.co.uk>:
> I have tried to the do the mvn release:perform but failed.
> For some reason I am unable to configure the username and password in
> settings.xml and so eventually I mistype at the prompt.
> Any suggestions ?
> Currently ~/.m2/settings.xml looks like, I have tried both password and
> private keys without sucess
>
> <?xml version="1.0"?>
> <settings>
> <servers>
> <server>
> <id>apache.incubating</id>
> <username>ieb</username>
> <password>xxxxxxxxxxxxxxxxxxxxx</password>
> </server>
> </servers>
> </settings>
>
>
> I have validated the password as correct (obviously xxxx bear no
> resemblance to my pw :)) on the command line.
>
> Unfortunately the deploy is not complete and so information at
> scp://people.apache.org/www/people.apache.org/repo/m2-incubating-repository/org/apache/shindig
> and
> scp://people.apache.org/www/incubator.apache.org/shindig/shindig-1.0.x/
>
> is also going to be incomplete.
>
> I hope the later one didn't break anything (sorry if it did)
> Ian
>
> On 15 Apr 2009, at 12:33, Ian Boston wrote:
>
>> I am probably too distant to anyone to do the signing, I running the maven
>> release:perform at the moment, but I dont think anything is getting signed,
>> or at least i am not being asked form gpg passphrase.
>>
>> Ian
>>
>>
>> On 15 Apr 2009, at 12:18, Chris Chabot wrote:
>>
>>> The php's release script doesn't do any signing yet, but if your willing
>>> to
>>> send the instructions of the release signature standards are for apache
>>> I'd
>>> be happy to build that in
>>>
>>> On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala
>>> <sa...@gmail.com>wrote:
>>>
>>>> El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
>>>>>
>>>>> FYi the prefered packaging format for php-shindig is generated by the
>>>>> shindig/php/make-release.sh file.
>>>>>
>>>>> in the 1.0.x branch it's version is currently set on 1.0, so just
>>>>
>>>> executing
>>>>>
>>>>> it will give you the appropriate
>>>>> php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
>>>>> files.
>>>>>
>>>>> I'll do a final test on them once you guys are release ready too, but
>>>>> in
>>>>> principle the 1.0.x branch & release script have been ready since nov
>>>>
>>>> last
>>>>>
>>>>> year, so I don't expect any surprises on that end
>>>>>
>>>>
>>>> Is there provision for signing the releases? I can sign the keys of
>>>> whoever is going to do it if we get some out of band, remote way to
>>>> verify identity WRT keys signature.
>>>>
>>>> Regards
>>>> Santiago
>>>>
>>>>> -- Chris
>>>>>
>>>>> On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vsiveton@apache.org
>>>>> wrote:
>>>>>
>>>>>> I guess the plan should be:
>>>>>> * release discussions: done by this thread
>>>>>> * prepare the release: mvn release:prepare which tags the code
>>>>>> * make the release: mvn release:perform which pushes (signed)
>>>>>> artifacts to repository.apache.org
>>>>>> * stage the generated Maven documentation
>>>>>> * propose a vote on this list: mail should include the urls and the
>>>>>> closed/left issues.
>>>>>> * ask Incubator PMC for the release
>>>>>> * publish and announce the release
>>>>>>
>>>>>> Anything else?
>>>>>>
>>>>>> If everybody is agree with this plan, I could try to start the process
>>>>>> this week.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Vincent
>>>>>>
>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>
>>>>>>> Being a release newbie with a desire to step into the unknown, what
>>>>
>>>> needs
>>>>>>
>>>>>> to
>>>>>>>
>>>>>>> be done ?
>>>>>>> presumably, build some artifacts, sign them, put them somewhere,
>>>>
>>>> agree
>>>>>>
>>>>>> that
>>>>>>>
>>>>>>> they should be the release, and then tell the incubator list we want
>>>>
>>>> to
>>>>>>>
>>>>>>> release them ?
>>>>>>>
>>>>>>> Ian
>>>>>>>
>>>>>>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>>>>>>
>>>>>>>> None of those 3 issues are actually release blockers. No feature
>>>>
>>>> request
>>>>>>>>
>>>>>>>> is
>>>>>>>> ever a release blocker unless that feature was explicitly identified
>>>>
>>>> as
>>>>>>>>
>>>>>>>> critical for the release at the beginning.
>>>>>>>>
>>>>>>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
>>>>
>>>> wrote:
>>>>>>>>
>>>>>>>>> I don't think we should wait for any of those issues. Release, and
>>>>>>>>> release again.
>>>>>>>>>
>>>>>>>>> -- Adam
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
>>>>
>>>> vsiveton@apache.org>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Ian,
>>>>>>>>>>
>>>>>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>>>>>
>>>>>>>>>>> I hate to bring it up again, but is it time to do a release on
>>>>
>>>> the
>>>>>>>>>>>
>>>>>>>>>>> 1.0.x
>>>>>>>>>>> branch ?
>>>>>>>>>>
>>>>>>>>>> I am agree with you.
>>>>>>>>>> According Jira [1], we have 3 issues left and according the board
>>>>>>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>>>>>>> So, could we fix them and make a release soon? Ping me if devs
>>>>
>>>> need
>>>>>>>>>>
>>>>>>>>>> help.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Vincent
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
I have tried to the do the mvn release:perform but failed.
For some reason I am unable to configure the username and password in
settings.xml and so eventually I mistype at the prompt.
Any suggestions ?
Currently ~/.m2/settings.xml looks like, I have tried both password
and private keys without sucess
<?xml version="1.0"?>
<settings>
<servers>
<server>
<id>apache.incubating</id>
<username>ieb</username>
<password>xxxxxxxxxxxxxxxxxxxxx</password>
</server>
</servers>
</settings>
I have validated the password as correct (obviously xxxx bear no
resemblance to my pw :)) on the command line.
Unfortunately the deploy is not complete and so information at
scp://people.apache.org/www/people.apache.org/repo/m2-incubating-
repository/org/apache/shindig
and
scp://people.apache.org/www/incubator.apache.org/shindig/shindig-1.0.x/
is also going to be incomplete.
I hope the later one didn't break anything (sorry if it did)
Ian
On 15 Apr 2009, at 12:33, Ian Boston wrote:
> I am probably too distant to anyone to do the signing, I running the
> maven release:perform at the moment, but I dont think anything is
> getting signed, or at least i am not being asked form gpg passphrase.
>
> Ian
>
>
> On 15 Apr 2009, at 12:18, Chris Chabot wrote:
>
>> The php's release script doesn't do any signing yet, but if your
>> willing to
>> send the instructions of the release signature standards are for
>> apache I'd
>> be happy to build that in
>>
>> On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala <santiago.gala@gmail.com
>> >wrote:
>>
>>> El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
>>>> FYi the prefered packaging format for php-shindig is generated by
>>>> the
>>>> shindig/php/make-release.sh file.
>>>>
>>>> in the 1.0.x branch it's version is currently set on 1.0, so just
>>> executing
>>>> it will give you the appropriate php-shindig-1.0.0.
>>>> {tar.bz2,.tar.gz,zip}
>>>> files.
>>>>
>>>> I'll do a final test on them once you guys are release ready too,
>>>> but in
>>>> principle the 1.0.x branch & release script have been ready since
>>>> nov
>>> last
>>>> year, so I don't expect any surprises on that end
>>>>
>>>
>>> Is there provision for signing the releases? I can sign the keys of
>>> whoever is going to do it if we get some out of band, remote way to
>>> verify identity WRT keys signature.
>>>
>>> Regards
>>> Santiago
>>>
>>>> -- Chris
>>>>
>>>> On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vsiveton@apache.org
>>>> wrote:
>>>>
>>>>> I guess the plan should be:
>>>>> * release discussions: done by this thread
>>>>> * prepare the release: mvn release:prepare which tags the code
>>>>> * make the release: mvn release:perform which pushes (signed)
>>>>> artifacts to repository.apache.org
>>>>> * stage the generated Maven documentation
>>>>> * propose a vote on this list: mail should include the urls and
>>>>> the
>>>>> closed/left issues.
>>>>> * ask Incubator PMC for the release
>>>>> * publish and announce the release
>>>>>
>>>>> Anything else?
>>>>>
>>>>> If everybody is agree with this plan, I could try to start the
>>>>> process
>>>>> this week.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Vincent
>>>>>
>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>> Being a release newbie with a desire to step into the unknown,
>>>>>> what
>>> needs
>>>>> to
>>>>>> be done ?
>>>>>> presumably, build some artifacts, sign them, put them somewhere,
>>> agree
>>>>> that
>>>>>> they should be the release, and then tell the incubator list we
>>>>>> want
>>> to
>>>>>> release them ?
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>>>>>
>>>>>>> None of those 3 issues are actually release blockers. No feature
>>> request
>>>>>>> is
>>>>>>> ever a release blocker unless that feature was explicitly
>>>>>>> identified
>>> as
>>>>>>> critical for the release at the beginning.
>>>>>>>
>>>>>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
>>> wrote:
>>>>>>>
>>>>>>>> I don't think we should wait for any of those issues.
>>>>>>>> Release, and
>>>>>>>> release again.
>>>>>>>>
>>>>>>>> -- Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
>>> vsiveton@apache.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Ian,
>>>>>>>>>
>>>>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>>>>
>>>>>>>>>> I hate to bring it up again, but is it time to do a release
>>>>>>>>>> on
>>> the
>>>>>>>>>> 1.0.x
>>>>>>>>>> branch ?
>>>>>>>>>
>>>>>>>>> I am agree with you.
>>>>>>>>> According Jira [1], we have 3 issues left and according the
>>>>>>>>> board
>>>>>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>>>>>> So, could we fix them and make a release soon? Ping me if devs
>>> need
>>>>>>>>> help.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Vincent
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
I am probably too distant to anyone to do the signing, I running the
maven release:perform at the moment, but I dont think anything is
getting signed, or at least i am not being asked form gpg passphrase.
Ian
On 15 Apr 2009, at 12:18, Chris Chabot wrote:
> The php's release script doesn't do any signing yet, but if your
> willing to
> send the instructions of the release signature standards are for
> apache I'd
> be happy to build that in
>
> On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala <santiago.gala@gmail.com
> >wrote:
>
>> El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
>>> FYi the prefered packaging format for php-shindig is generated by
>>> the
>>> shindig/php/make-release.sh file.
>>>
>>> in the 1.0.x branch it's version is currently set on 1.0, so just
>> executing
>>> it will give you the appropriate php-shindig-1.0.0.
>>> {tar.bz2,.tar.gz,zip}
>>> files.
>>>
>>> I'll do a final test on them once you guys are release ready too,
>>> but in
>>> principle the 1.0.x branch & release script have been ready since
>>> nov
>> last
>>> year, so I don't expect any surprises on that end
>>>
>>
>> Is there provision for signing the releases? I can sign the keys of
>> whoever is going to do it if we get some out of band, remote way to
>> verify identity WRT keys signature.
>>
>> Regards
>> Santiago
>>
>>> -- Chris
>>>
>>> On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton
>>> <vsiveton@apache.org
>>> wrote:
>>>
>>>> I guess the plan should be:
>>>> * release discussions: done by this thread
>>>> * prepare the release: mvn release:prepare which tags the code
>>>> * make the release: mvn release:perform which pushes (signed)
>>>> artifacts to repository.apache.org
>>>> * stage the generated Maven documentation
>>>> * propose a vote on this list: mail should include the urls and the
>>>> closed/left issues.
>>>> * ask Incubator PMC for the release
>>>> * publish and announce the release
>>>>
>>>> Anything else?
>>>>
>>>> If everybody is agree with this plan, I could try to start the
>>>> process
>>>> this week.
>>>>
>>>> Cheers,
>>>>
>>>> Vincent
>>>>
>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>> Being a release newbie with a desire to step into the unknown,
>>>>> what
>> needs
>>>> to
>>>>> be done ?
>>>>> presumably, build some artifacts, sign them, put them somewhere,
>> agree
>>>> that
>>>>> they should be the release, and then tell the incubator list we
>>>>> want
>> to
>>>>> release them ?
>>>>>
>>>>> Ian
>>>>>
>>>>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>>>>
>>>>>> None of those 3 issues are actually release blockers. No feature
>> request
>>>>>> is
>>>>>> ever a release blocker unless that feature was explicitly
>>>>>> identified
>> as
>>>>>> critical for the release at the beginning.
>>>>>>
>>>>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
>> wrote:
>>>>>>
>>>>>>> I don't think we should wait for any of those issues.
>>>>>>> Release, and
>>>>>>> release again.
>>>>>>>
>>>>>>> -- Adam
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
>> vsiveton@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Ian,
>>>>>>>>
>>>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>>>
>>>>>>>>> I hate to bring it up again, but is it time to do a release on
>> the
>>>>>>>>> 1.0.x
>>>>>>>>> branch ?
>>>>>>>>
>>>>>>>> I am agree with you.
>>>>>>>> According Jira [1], we have 3 issues left and according the
>>>>>>>> board
>>>>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>>>>> So, could we fix them and make a release soon? Ping me if devs
>> need
>>>>>>>> help.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Vincent
>>>>>>>>
>>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
The php's release script doesn't do any signing yet, but if your willing to
send the instructions of the release signature standards are for apache I'd
be happy to build that in
On Wed, Apr 15, 2009 at 1:11 PM, Santiago Gala <sa...@gmail.com>wrote:
> El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
> > FYi the prefered packaging format for php-shindig is generated by the
> > shindig/php/make-release.sh file.
> >
> > in the 1.0.x branch it's version is currently set on 1.0, so just
> executing
> > it will give you the appropriate php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
> > files.
> >
> > I'll do a final test on them once you guys are release ready too, but in
> > principle the 1.0.x branch & release script have been ready since nov
> last
> > year, so I don't expect any surprises on that end
> >
>
> Is there provision for signing the releases? I can sign the keys of
> whoever is going to do it if we get some out of band, remote way to
> verify identity WRT keys signature.
>
> Regards
> Santiago
>
> > -- Chris
> >
> > On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vsiveton@apache.org
> >wrote:
> >
> > > I guess the plan should be:
> > > * release discussions: done by this thread
> > > * prepare the release: mvn release:prepare which tags the code
> > > * make the release: mvn release:perform which pushes (signed)
> > > artifacts to repository.apache.org
> > > * stage the generated Maven documentation
> > > * propose a vote on this list: mail should include the urls and the
> > > closed/left issues.
> > > * ask Incubator PMC for the release
> > > * publish and announce the release
> > >
> > > Anything else?
> > >
> > > If everybody is agree with this plan, I could try to start the process
> > > this week.
> > >
> > > Cheers,
> > >
> > > Vincent
> > >
> > > 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > > > Being a release newbie with a desire to step into the unknown, what
> needs
> > > to
> > > > be done ?
> > > > presumably, build some artifacts, sign them, put them somewhere,
> agree
> > > that
> > > > they should be the release, and then tell the incubator list we want
> to
> > > > release them ?
> > > >
> > > > Ian
> > > >
> > > > On 13 Apr 2009, at 21:52, Kevin Brown wrote:
> > > >
> > > >> None of those 3 issues are actually release blockers. No feature
> request
> > > >> is
> > > >> ever a release blocker unless that feature was explicitly identified
> as
> > > >> critical for the release at the beginning.
> > > >>
> > > >> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
> wrote:
> > > >>
> > > >>> I don't think we should wait for any of those issues. Release, and
> > > >>> release again.
> > > >>>
> > > >>> -- Adam
> > > >>>
> > > >>>
> > > >>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <
> vsiveton@apache.org>
> > > >>> wrote:
> > > >>>>
> > > >>>> Hi Ian,
> > > >>>>
> > > >>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > > >>>>>
> > > >>>>> I hate to bring it up again, but is it time to do a release on
> the
> > > >>>>> 1.0.x
> > > >>>>> branch ?
> > > >>>>
> > > >>>> I am agree with you.
> > > >>>> According Jira [1], we have 3 issues left and according the board
> > > >>>> report, we plan to do a release of 1.0.x in this quarter.
> > > >>>> So, could we fix them and make a release soon? Ping me if devs
> need
> > > >>>> help.
> > > >>>>
> > > >>>> Cheers,
> > > >>>>
> > > >>>> Vincent
> > > >>>>
> > > >>>> [1]
> > > >>>
> > > >>>
> > > >>>
> > >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
> > > >>>>
> > > >>>
> > > >
> > > >
> > >
>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using
Maven snapshot repo
Posted by Santiago Gala <sa...@gmail.com>.
El mar, 14-04-2009 a las 15:37 +0200, Chris Chabot escribió:
> FYi the prefered packaging format for php-shindig is generated by the
> shindig/php/make-release.sh file.
>
> in the 1.0.x branch it's version is currently set on 1.0, so just executing
> it will give you the appropriate php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
> files.
>
> I'll do a final test on them once you guys are release ready too, but in
> principle the 1.0.x branch & release script have been ready since nov last
> year, so I don't expect any surprises on that end
>
Is there provision for signing the releases? I can sign the keys of
whoever is going to do it if we get some out of band, remote way to
verify identity WRT keys signature.
Regards
Santiago
> -- Chris
>
> On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vs...@apache.org>wrote:
>
> > I guess the plan should be:
> > * release discussions: done by this thread
> > * prepare the release: mvn release:prepare which tags the code
> > * make the release: mvn release:perform which pushes (signed)
> > artifacts to repository.apache.org
> > * stage the generated Maven documentation
> > * propose a vote on this list: mail should include the urls and the
> > closed/left issues.
> > * ask Incubator PMC for the release
> > * publish and announce the release
> >
> > Anything else?
> >
> > If everybody is agree with this plan, I could try to start the process
> > this week.
> >
> > Cheers,
> >
> > Vincent
> >
> > 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > > Being a release newbie with a desire to step into the unknown, what needs
> > to
> > > be done ?
> > > presumably, build some artifacts, sign them, put them somewhere, agree
> > that
> > > they should be the release, and then tell the incubator list we want to
> > > release them ?
> > >
> > > Ian
> > >
> > > On 13 Apr 2009, at 21:52, Kevin Brown wrote:
> > >
> > >> None of those 3 issues are actually release blockers. No feature request
> > >> is
> > >> ever a release blocker unless that feature was explicitly identified as
> > >> critical for the release at the beginning.
> > >>
> > >> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com> wrote:
> > >>
> > >>> I don't think we should wait for any of those issues. Release, and
> > >>> release again.
> > >>>
> > >>> -- Adam
> > >>>
> > >>>
> > >>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vs...@apache.org>
> > >>> wrote:
> > >>>>
> > >>>> Hi Ian,
> > >>>>
> > >>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > >>>>>
> > >>>>> I hate to bring it up again, but is it time to do a release on the
> > >>>>> 1.0.x
> > >>>>> branch ?
> > >>>>
> > >>>> I am agree with you.
> > >>>> According Jira [1], we have 3 issues left and according the board
> > >>>> report, we plan to do a release of 1.0.x in this quarter.
> > >>>> So, could we fix them and make a release soon? Ping me if devs need
> > >>>> help.
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Vincent
> > >>>>
> > >>>> [1]
> > >>>
> > >>>
> > >>>
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
> > >>>>
> > >>>
> > >
> > >
> >
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
FYi the prefered packaging format for php-shindig is generated by the
shindig/php/make-release.sh file.
in the 1.0.x branch it's version is currently set on 1.0, so just executing
it will give you the appropriate php-shindig-1.0.0.{tar.bz2,.tar.gz,zip}
files.
I'll do a final test on them once you guys are release ready too, but in
principle the 1.0.x branch & release script have been ready since nov last
year, so I don't expect any surprises on that end
-- Chris
On Tue, Apr 14, 2009 at 2:19 PM, Vincent Siveton <vs...@apache.org>wrote:
> I guess the plan should be:
> * release discussions: done by this thread
> * prepare the release: mvn release:prepare which tags the code
> * make the release: mvn release:perform which pushes (signed)
> artifacts to repository.apache.org
> * stage the generated Maven documentation
> * propose a vote on this list: mail should include the urls and the
> closed/left issues.
> * ask Incubator PMC for the release
> * publish and announce the release
>
> Anything else?
>
> If everybody is agree with this plan, I could try to start the process
> this week.
>
> Cheers,
>
> Vincent
>
> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> > Being a release newbie with a desire to step into the unknown, what needs
> to
> > be done ?
> > presumably, build some artifacts, sign them, put them somewhere, agree
> that
> > they should be the release, and then tell the incubator list we want to
> > release them ?
> >
> > Ian
> >
> > On 13 Apr 2009, at 21:52, Kevin Brown wrote:
> >
> >> None of those 3 issues are actually release blockers. No feature request
> >> is
> >> ever a release blocker unless that feature was explicitly identified as
> >> critical for the release at the beginning.
> >>
> >> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com> wrote:
> >>
> >>> I don't think we should wait for any of those issues. Release, and
> >>> release again.
> >>>
> >>> -- Adam
> >>>
> >>>
> >>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vs...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi Ian,
> >>>>
> >>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> >>>>>
> >>>>> I hate to bring it up again, but is it time to do a release on the
> >>>>> 1.0.x
> >>>>> branch ?
> >>>>
> >>>> I am agree with you.
> >>>> According Jira [1], we have 3 issues left and according the board
> >>>> report, we plan to do a release of 1.0.x in this quarter.
> >>>> So, could we fix them and make a release soon? Ping me if devs need
> >>>> help.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Vincent
> >>>>
> >>>> [1]
> >>>
> >>>
> >>>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
> >>>>
> >>>
> >
> >
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
Progress,
Branch and tags done,
Tag at https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0.0-incubating/
However the replication of svn between the US and EU means that you
have to restart the prepare process several times to avoid the
following errors.
INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: The specified baseline is not the latest baseline, so it may not
be checked out.
I guess fixing the svn co to a specific server eg https://svn.eu.apache.org
would remove all lag and eliminate the problem.
I will try the perform next.
Ian
On 15 Apr 2009, at 11:09, Ian Boston wrote:
> I will try and get to the published artifacts stage,
> Where should the generated Maven documentation go ?
> Ian
>
> On 14 Apr 2009, at 13:19, Vincent Siveton wrote:
>
>> I guess the plan should be:
>> * release discussions: done by this thread
>> * prepare the release: mvn release:prepare which tags the code
>> * make the release: mvn release:perform which pushes (signed)
>> artifacts to repository.apache.org
>> * stage the generated Maven documentation
>> * propose a vote on this list: mail should include the urls and the
>> closed/left issues.
>> * ask Incubator PMC for the release
>> * publish and announce the release
>>
>> Anything else?
>>
>> If everybody is agree with this plan, I could try to start the
>> process
>> this week.
>>
>> Cheers,
>>
>> Vincent
>>
>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>> Being a release newbie with a desire to step into the unknown,
>>> what needs to
>>> be done ?
>>> presumably, build some artifacts, sign them, put them somewhere,
>>> agree that
>>> they should be the release, and then tell the incubator list we
>>> want to
>>> release them ?
>>>
>>> Ian
>>>
>>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>>
>>>> None of those 3 issues are actually release blockers. No feature
>>>> request
>>>> is
>>>> ever a release blocker unless that feature was explicitly
>>>> identified as
>>>> critical for the release at the beginning.
>>>>
>>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
>>>> wrote:
>>>>
>>>>> I don't think we should wait for any of those issues. Release,
>>>>> and
>>>>> release again.
>>>>>
>>>>> -- Adam
>>>>>
>>>>>
>>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vsiveton@apache.org
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> Hi Ian,
>>>>>>
>>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>>
>>>>>>> I hate to bring it up again, but is it time to do a release on
>>>>>>> the
>>>>>>> 1.0.x
>>>>>>> branch ?
>>>>>>
>>>>>> I am agree with you.
>>>>>> According Jira [1], we have 3 issues left and according the board
>>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>>> So, could we fix them and make a release soon? Ping me if devs
>>>>>> need
>>>>>> help.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Vincent
>>>>>>
>>>>>> [1]
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>>
>>>>>
>>>
>>>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Lane LiaBraaten <ll...@google.com>.
On Wed, Apr 15, 2009 at 11:19 AM, Kevin Brown <et...@google.com> wrote:
> On Wed, Apr 15, 2009 at 5:33 AM, Chris Chabot <ch...@google.com> wrote:
> > On Wed, Apr 15, 2009 at 2:09 PM, Vincent Siveton
> > <vi...@gmail.com>wrote:
> >
> >>
> >> Using Maven will be more platform independent,
> >>
> >
> >
> > Ps, any claims that 'get root access', 'install java', 'make java work',
> > 'install maven', 'learn how to use maven commands' is more platform
> > independent then /bin/sh, should probably re-evaluate his position and
> hop
> > on the *nix bandwagon as many generations before us have done :)
>
> I agree. Honestly, I don't even like using maven for java work, and
> expecting PHP developers and users to understand maven is a bad idea.
+1
>
>
> 'Platform independence' is a myth. Maven relies on java and as such it
> is inherently stuck with java's own lack of platform independence. I
> can run chris's script just fine on an old FreeBSD 4 system, and there
> isn't a JVM new enough to run maven available for it. I have a shared
> host (RHEL) that can run the same shell script but can't even install
> java. Just because something happens to work on a handful of popular
> operating systems does not make it 'platform independent',
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 15, 2009 at 5:33 AM, Chris Chabot <ch...@google.com> wrote:
> On Wed, Apr 15, 2009 at 2:09 PM, Vincent Siveton
> <vi...@gmail.com>wrote:
>
>>
>> Using Maven will be more platform independent,
>>
>
>
> Ps, any claims that 'get root access', 'install java', 'make java work',
> 'install maven', 'learn how to use maven commands' is more platform
> independent then /bin/sh, should probably re-evaluate his position and hop
> on the *nix bandwagon as many generations before us have done :)
I agree. Honestly, I don't even like using maven for java work, and
expecting PHP developers and users to understand maven is a bad idea.
'Platform independence' is a myth. Maven relies on java and as such it
is inherently stuck with java's own lack of platform independence. I
can run chris's script just fine on an old FreeBSD 4 system, and there
isn't a JVM new enough to run maven available for it. I have a shared
host (RHEL) that can run the same shell script but can't even install
java. Just because something happens to work on a handful of popular
operating systems does not make it 'platform independent',
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
On Wed, Apr 15, 2009 at 2:09 PM, Vincent Siveton
<vi...@gmail.com>wrote:
>
> Using Maven will be more platform independent,
>
Ps, any claims that 'get root access', 'install java', 'make java work',
'install maven', 'learn how to use maven commands' is more platform
independent then /bin/sh, should probably re-evaluate his position and hop
on the *nix bandwagon as many generations before us have done :)
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vs...@apache.org>.
Thanks Chris, so I will cut the release this evening.
Cheers,
Vincent
2009/4/22 Chris Chabot <ch...@google.com>:
> 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 <ie...@tfd.co.uk> 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 <santiago.gala@gmail.com
>>> >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
>>>>> <vi...@gmail.com>wrote:
>>>>>
>>>>> 2009/4/15 Chris Chabot <ch...@google.com>:
>>>>>>
>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
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 <ie...@tfd.co.uk> 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 <santiago.gala@gmail.com
>> >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
>>>> <vi...@gmail.com>wrote:
>>>>
>>>> 2009/4/15 Chris Chabot <ch...@google.com>:
>>>>>
>>>>>> 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
>>>>
>>>
>>>
>>>
>
RE: Blank pages
Posted by Jordan Zimmerman <jo...@shop.com>.
>Any update on this one? I think i am also having something similar.
>
>Thanks and Regards,
>Hafiz
FYI - it hasn't been happening to us recently. We fixed some other bugs
that may have been related. Here are some things to think about:
* At SHOP, we've turned off all Shindig caching that we can find
* The default timeout for HTTP fetches in Shindig is 5 seconds. If any
gadget requests a resource that takes more than 5 seconds, it will fail.
* The default HTTP fetch in Shindig does not follow redirects (for
security I assume). If a gadget requests a resource that responds with a
301/302, it will fail.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: Blank pages
Posted by Hafiz A Haq <ha...@gmail.com>.
Any update on this one? I think i am also having something similar.
Thanks and Regards,
Hafiz
2009/4/22 Mark D Weitzel <we...@us.ibm.com>
> Thanks. This seems straight forward enough. I'll code it up as you've
> suggested and see what happens.
> -Mark W.
>
>
>
> From:
> "Jordan Zimmerman" <jo...@shop.com>
> To:
> <sh...@incubator.apache.org>
> Date:
> 04/21/2009 03:21 PM
> Subject:
> RE: Blank pages
>
>
>
> > Would you post the steps you did to turn off ALL caching in shindig
>
> 1. I have a Servlet Filter registered that turns off browser caching:
> public void doFilter(...)
> {
> ...
> HttpServletResponse httpResponse
> =(HttpServletResponse)response;
> httpResponse.setHeader("Cache-Control",
> "no-cache");
> httpResponse.setDateHeader("Expires", 0);
> httpResponse.setHeader("Pragma",
> "no-cache");
> }
>
> 2. I've substituted my own Rendering servlet for the default
> GadgetRenderingServlet.
>
> 3. Having my own rendering servlet gives me the opportunity to override
> lots of behavior. For caching, I wrap the GadgetContext with a proxy
> that returns true for GadgetContext.getIgnoreCache().
>
> Simple, huh? I maybe missing some other caching somewhere though.
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
>
>
>
--
He who asks is a fool for five minutes, but he who does not ask remains a
fool forever.
RE: Blank pages
Posted by Jordan Zimmerman <jo...@shop.com>.
>I've seen this behavior ... usually due to ...
gadgets.window.adjustHeight.
Hey! This might be it. I temporarily commented out all the
adjustHeight() calls in our gadgets and, so far, the behavior has gone
away. Fingers crossed.
The RPC-relay stuff feels like black magic to me so it's not surprising
that it might have issues.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: Blank pages
Posted by Taylor Singletary <ts...@linkedin.com>.
I've seen this behavior in the past in a couple different circumstances. In
my experience, it was usually due to an intermingling of Browser, DOM ready
state, CSS/DOM style properties, container IFRAME markup/height & width
configuration points, and gadgets.window.adjustHeight.
That might not be the case in your scenario, but it's the first place I'd
look.
Taylor
On 4/21/09 11:30 AM , "Jordan Zimmerman" <jo...@shop.com> wrote:
>> I'm pretty sure we've run across this intermittently as well.
> I've been debugging it for the past few days. I'll report back what I
> find. Here's what I know so far...
>
> * It does NOT appear to be a caching issue. I've hard-coded Shindig and
> my application to do no caching at all. I've even marked all pages as
> non-cacheable.
>
> * I think it has something to do with multiple newDataRequest(). My
> current suspicion is that an internal queue in Shindig is getting
> overwritten.
>
>
> Jordan Zimmerman
> Principal Software Architect
> 831.647.4712
> 831.214.2990 (cell)
> jordanz@shop.com
>
> SHOP*COMTM
> Shop Smart, Save Big(tm)
> www.shop.com
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this
> message
> immediately if this is an electronic communication.
>
> Thank you.
RE: Blank pages
Posted by Mark D Weitzel <we...@us.ibm.com>.
Thanks. This seems straight forward enough. I'll code it up as you've
suggested and see what happens.
-Mark W.
From:
"Jordan Zimmerman" <jo...@shop.com>
To:
<sh...@incubator.apache.org>
Date:
04/21/2009 03:21 PM
Subject:
RE: Blank pages
> Would you post the steps you did to turn off ALL caching in shindig
1. I have a Servlet Filter registered that turns off browser caching:
public void doFilter(...)
{
...
HttpServletResponse httpResponse
=(HttpServletResponse)response;
httpResponse.setHeader("Cache-Control",
"no-cache");
httpResponse.setDateHeader("Expires", 0);
httpResponse.setHeader("Pragma",
"no-cache");
}
2. I've substituted my own Rendering servlet for the default
GadgetRenderingServlet.
3. Having my own rendering servlet gives me the opportunity to override
lots of behavior. For caching, I wrap the GadgetContext with a proxy
that returns true for GadgetContext.getIgnoreCache().
Simple, huh? I maybe missing some other caching somewhere though.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: Blank pages
Posted by Jordan Zimmerman <jo...@shop.com>.
> Would you post the steps you did to turn off ALL caching in shindig
1. I have a Servlet Filter registered that turns off browser caching:
public void doFilter(...)
{
...
HttpServletResponse httpResponse
=(HttpServletResponse)response;
httpResponse.setHeader("Cache-Control", "no-cache");
httpResponse.setDateHeader("Expires", 0);
httpResponse.setHeader("Pragma", "no-cache");
}
2. I've substituted my own Rendering servlet for the default
GadgetRenderingServlet.
3. Having my own rendering servlet gives me the opportunity to override
lots of behavior. For caching, I wrap the GadgetContext with a proxy
that returns true for GadgetContext.getIgnoreCache().
Simple, huh? I maybe missing some other caching somewhere though.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: Blank pages
Posted by Mark D Weitzel <we...@us.ibm.com>.
Would you post the steps you did to turn off ALL caching in shindig to
this list of on the wiki? We've come across a few scenarios where ensuring
nothing gets cached would be very beneficial esp. debugging. I can follow
these steps to see if I can replicate the problem.
-Mark W.
From:
"Jordan Zimmerman" <jo...@shop.com>
To:
<sh...@incubator.apache.org>
Date:
04/21/2009 02:32 PM
Subject:
RE: Blank pages
>I'm pretty sure we've run across this intermittently as well.
I've been debugging it for the past few days. I'll report back what I
find. Here's what I know so far...
* It does NOT appear to be a caching issue. I've hard-coded Shindig and
my application to do no caching at all. I've even marked all pages as
non-cacheable.
* I think it has something to do with multiple newDataRequest(). My
current suspicion is that an internal queue in Shindig is getting
overwritten.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: Blank pages
Posted by Jordan Zimmerman <jo...@shop.com>.
>I'm pretty sure we've run across this intermittently as well.
I've been debugging it for the past few days. I'll report back what I
find. Here's what I know so far...
* It does NOT appear to be a caching issue. I've hard-coded Shindig and
my application to do no caching at all. I've even marked all pages as
non-cacheable.
* I think it has something to do with multiple newDataRequest(). My
current suspicion is that an internal queue in Shindig is getting
overwritten.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: Blank pages
Posted by Mark D Weitzel <we...@us.ibm.com>.
Jordan,
I'm pretty sure we've run across this intermittently as well. It may be a
caching issue b/c we for a browser refresh and we'll get the frame to
load. It's only happened to us once in a while and only started recently.
I didn't give it much thought until I saw your post. I know this isn't
much help.
-Mark W.
From:
"Jordan Zimmerman" <jo...@shop.com>
To:
<sh...@incubator.apache.org>
Date:
04/21/2009 01:45 PM
Subject:
Blank pages
Intermittently, we have gadgets that don't function correctly. The
visual symptom is that the gadget's frame is blank. If I view source
when this happens, I see the full source for the page. The common thing
for all these gadgets is that they make opensocial.newDataRequest()
calls.
I realize this is vague but if it rings any bells for anyone, I'd
appreciate any/all ideas on how to debug it.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Blank pages
Posted by Jordan Zimmerman <jo...@shop.com>.
Intermittently, we have gadgets that don't function correctly. The
visual symptom is that the gadget's frame is blank. If I view source
when this happens, I see the full source for the page. The common thing
for all these gadgets is that they make opensocial.newDataRequest()
calls.
I realize this is vague but if it rings any bells for anyone, I'd
appreciate any/all ideas on how to debug it.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
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 <santiago.gala@gmail.com
> >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
>>> <vi...@gmail.com>wrote:
>>>
>>>> 2009/4/15 Chris Chabot <ch...@google.com>:
>>>>>> 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
>>
>>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Carmen Sarlo <ne...@gmail.com>.
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 <sa...@gmail.com>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
> > <vi...@gmail.com>wrote:
> >
> > > 2009/4/15 Chris Chabot <ch...@google.com>:
> > > >> 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
>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using
Maven snapshot repo
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 15-04-2009 a las 15:57 +0200, Chris Chabot escribió:
> On Wed, Apr 15, 2009 at 3:28 PM, Vincent Siveton
> <vi...@gmail.com>wrote:
>
> > 2009/4/15 Chris Chabot <ch...@google.com>:
> > >> 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
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
On Wed, Apr 15, 2009 at 3:28 PM, Vincent Siveton
<vi...@gmail.com>wrote:
> 2009/4/15 Chris Chabot <ch...@google.com>:
> >> 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.
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 :)
> > (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
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vi...@gmail.com>.
2009/4/15 Chris Chabot <ch...@google.com>:
>> 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.
>
> (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. 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.
Do we want to centralize build under Maven, for all languages
supported and for making release?
Cheers,
Vincent
Note: I am not a PHP dev/user, and I trust your final judgement
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Chris Chabot <ch...@google.com>.
On Wed, Apr 15, 2009 at 2:09 PM, Vincent Siveton
<vi...@gmail.com>wrote:
> Hi Ian,
>
> 2009/4/15 Ian Boston <ie...@tfd.co.uk>:
> > I will try and get to the published artifacts stage,
> > Where should the generated Maven documentation go ?
> > Ian
> >
>
> 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:
replace the top line of the make-release.sh shell script that now reads:
#!/bin/bash
with wherever your bash is located (which you can easily discover by doing
"which bash"), for instance:
#!/usr/bin/bash
Saying that "it won't work on ubuntu" is a slight over-exaggeration in my
opinion :)
(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..
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
Ok by me.... since I dont have a verified gpg key it might make sense
for me to hand over to you at this point.
Ian
On 15 Apr 2009, at 13:09, Vincent Siveton wrote:
> Hi Ian,
>
> 2009/4/15 Ian Boston <ie...@tfd.co.uk>:
>> I will try and get to the published artifacts stage,
>> Where should the generated Maven documentation go ?
>> Ian
>>
>
> I spoke yesterday with Chris about the make-release.sh: this script
> won't work on my ubuntu box :(
> 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?
>
> About the documentation, you could always run mvn site -Preporting and
> mvn site:deploy to deploy to shindig/shindig-1.0.x
> I will merge r761647 to have a similar doc like this one:
> http://incubator.apache.org/shindig/shindig-1.1.x/shindig-features/jsdoc/index.html
>
> So I propose to revert the tag and restart the process.
>
> Cheers,
>
> Vincent
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Ian,
2009/4/15 Ian Boston <ie...@tfd.co.uk>:
> I will try and get to the published artifacts stage,
> Where should the generated Maven documentation go ?
> Ian
>
I spoke yesterday with Chris about the make-release.sh: this script
won't work on my ubuntu box :(
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?
About the documentation, you could always run mvn site -Preporting and
mvn site:deploy to deploy to shindig/shindig-1.0.x
I will merge r761647 to have a similar doc like this one:
http://incubator.apache.org/shindig/shindig-1.1.x/shindig-features/jsdoc/index.html
So I propose to revert the tag and restart the process.
Cheers,
Vincent
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
I will try and get to the published artifacts stage,
Where should the generated Maven documentation go ?
Ian
On 14 Apr 2009, at 13:19, Vincent Siveton wrote:
> I guess the plan should be:
> * release discussions: done by this thread
> * prepare the release: mvn release:prepare which tags the code
> * make the release: mvn release:perform which pushes (signed)
> artifacts to repository.apache.org
> * stage the generated Maven documentation
> * propose a vote on this list: mail should include the urls and the
> closed/left issues.
> * ask Incubator PMC for the release
> * publish and announce the release
>
> Anything else?
>
> If everybody is agree with this plan, I could try to start the process
> this week.
>
> Cheers,
>
> Vincent
>
> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>> Being a release newbie with a desire to step into the unknown, what
>> needs to
>> be done ?
>> presumably, build some artifacts, sign them, put them somewhere,
>> agree that
>> they should be the release, and then tell the incubator list we
>> want to
>> release them ?
>>
>> Ian
>>
>> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>>
>>> None of those 3 issues are actually release blockers. No feature
>>> request
>>> is
>>> ever a release blocker unless that feature was explicitly
>>> identified as
>>> critical for the release at the beginning.
>>>
>>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com>
>>> wrote:
>>>
>>>> I don't think we should wait for any of those issues. Release, and
>>>> release again.
>>>>
>>>> -- Adam
>>>>
>>>>
>>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vsiveton@apache.org
>>>> >
>>>> wrote:
>>>>>
>>>>> Hi Ian,
>>>>>
>>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>>
>>>>>> I hate to bring it up again, but is it time to do a release on
>>>>>> the
>>>>>> 1.0.x
>>>>>> branch ?
>>>>>
>>>>> I am agree with you.
>>>>> According Jira [1], we have 3 issues left and according the board
>>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>>> So, could we fix them and make a release soon? Ping me if devs
>>>>> need
>>>>> help.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Vincent
>>>>>
>>>>> [1]
>>>>
>>>>
>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>>
>>>>
>>
>>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Vincent Siveton <vs...@apache.org>.
I guess the plan should be:
* release discussions: done by this thread
* prepare the release: mvn release:prepare which tags the code
* make the release: mvn release:perform which pushes (signed)
artifacts to repository.apache.org
* stage the generated Maven documentation
* propose a vote on this list: mail should include the urls and the
closed/left issues.
* ask Incubator PMC for the release
* publish and announce the release
Anything else?
If everybody is agree with this plan, I could try to start the process
this week.
Cheers,
Vincent
2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> Being a release newbie with a desire to step into the unknown, what needs to
> be done ?
> presumably, build some artifacts, sign them, put them somewhere, agree that
> they should be the release, and then tell the incubator list we want to
> release them ?
>
> Ian
>
> On 13 Apr 2009, at 21:52, Kevin Brown wrote:
>
>> None of those 3 issues are actually release blockers. No feature request
>> is
>> ever a release blocker unless that feature was explicitly identified as
>> critical for the release at the beginning.
>>
>> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com> wrote:
>>
>>> I don't think we should wait for any of those issues. Release, and
>>> release again.
>>>
>>> -- Adam
>>>
>>>
>>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vs...@apache.org>
>>> wrote:
>>>>
>>>> Hi Ian,
>>>>
>>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>>>
>>>>> I hate to bring it up again, but is it time to do a release on the
>>>>> 1.0.x
>>>>> branch ?
>>>>
>>>> I am agree with you.
>>>> According Jira [1], we have 3 issues left and according the board
>>>> report, we plan to do a release of 1.0.x in this quarter.
>>>> So, could we fix them and make a release soon? Ping me if devs need
>>>> help.
>>>>
>>>> Cheers,
>>>>
>>>> Vincent
>>>>
>>>> [1]
>>>
>>>
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>>
>>>
>
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven snapshot repo
Posted by Ian Boston <ie...@tfd.co.uk>.
Being a release newbie with a desire to step into the unknown, what
needs to be done ?
presumably, build some artifacts, sign them, put them somewhere, agree
that they should be the release, and then tell the incubator list we
want to release them ?
Ian
On 13 Apr 2009, at 21:52, Kevin Brown wrote:
> None of those 3 issues are actually release blockers. No feature
> request is
> ever a release blocker unless that feature was explicitly identified
> as
> critical for the release at the beginning.
>
> On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com> wrote:
>
>> I don't think we should wait for any of those issues. Release, and
>> release again.
>>
>> -- Adam
>>
>>
>> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton
>> <vs...@apache.org>
>> wrote:
>>> Hi Ian,
>>>
>>> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>>>> I hate to bring it up again, but is it time to do a release on
>>>> the 1.0.x
>>>> branch ?
>>>
>>> I am agree with you.
>>> According Jira [1], we have 3 issues left and according the board
>>> report, we plan to do a release of 1.0.x in this quarter.
>>> So, could we fix them and make a release soon? Ping me if devs
>>> need help.
>>>
>>> Cheers,
>>>
>>> Vincent
>>>
>>> [1]
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>>>
>>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Kevin Brown <et...@google.com>.
None of those 3 issues are actually release blockers. No feature request is
ever a release blocker unless that feature was explicitly identified as
critical for the release at the beginning.
On Mon, Apr 13, 2009 at 1:39 PM, Adam Winer <aw...@google.com> wrote:
> I don't think we should wait for any of those issues. Release, and
> release again.
>
> -- Adam
>
>
> On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vs...@apache.org>
> wrote:
> > Hi Ian,
> >
> > 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
> >> I hate to bring it up again, but is it time to do a release on the 1.0.x
> >> branch ?
> >
> > I am agree with you.
> > According Jira [1], we have 3 issues left and according the board
> > report, we plan to do a release of 1.0.x in this quarter.
> > So, could we fix them and make a release soon? Ping me if devs need help.
> >
> > Cheers,
> >
> > Vincent
> >
> > [1]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
> >
>
Re: What missing to do a 1.0.x release? WAS: [Proposal] Using Maven
snapshot repo
Posted by Adam Winer <aw...@google.com>.
I don't think we should wait for any of those issues. Release, and
release again.
-- Adam
On Mon, Apr 13, 2009 at 1:20 PM, Vincent Siveton <vs...@apache.org> wrote:
> Hi Ian,
>
> 2009/4/13 Ian Boston <ie...@tfd.co.uk>:
>> I hate to bring it up again, but is it time to do a release on the 1.0.x
>> branch ?
>
> I am agree with you.
> According Jira [1], we have 3 issues left and according the board
> report, we plan to do a release of 1.0.x in this quarter.
> So, could we fix them and make a release soon? Ping me if devs need help.
>
> Cheers,
>
> Vincent
>
> [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310741&fixfor=12313553
>