You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Bryan Duxbury <br...@rapleaf.com> on 2010/08/18 21:56:12 UTC

bootstrap.sh in tarballs

What do you guys think of omitting bootstrap.sh from release tarballs?
People seem super eager to run it, and it breaks things. If we didn't
include it, then at least they'd *know* they can't run it.

Re: bootstrap.sh in tarballs

Posted by Rajesh Malepati <ch...@gmail.com>.
+1 It's very tempting

On Thu, Aug 19, 2010 at 1:26 AM, Bryan Duxbury <br...@rapleaf.com> wrote:
> What do you guys think of omitting bootstrap.sh from release tarballs?
> People seem super eager to run it, and it breaks things. If we didn't
> include it, then at least they'd *know* they can't run it.
>

Re: bootstrap.sh in tarballs

Posted by Greg Stein <gs...@gmail.com>.
+1

We omit similar scripts in our Subversion release.

On Wed, Aug 18, 2010 at 16:19, Bruce Lowekamp <br...@skype.net> wrote:
> +1
>
> On Aug 18, 2010, at 12:56 PM, Bryan Duxbury wrote:
>
>> What do you guys think of omitting bootstrap.sh from release tarballs?
>> People seem super eager to run it, and it breaks things. If we didn't
>> include it, then at least they'd *know* they can't run it.
>
>

Re: bootstrap.sh in tarballs

Posted by ro...@bufferoverflow.ch.
+1 sounds good


Quoting Bruce Lowekamp <br...@skype.net>:

> +1
>
> On Aug 18, 2010, at 12:56 PM, Bryan Duxbury wrote:
>
>> What do you guys think of omitting bootstrap.sh from release tarballs?
>> People seem super eager to run it, and it breaks things. If we didn't
>> include it, then at least they'd *know* they can't run it.
>
>
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


Re: bootstrap.sh in tarballs

Posted by Bruce Lowekamp <br...@skype.net>.
+1

On Aug 18, 2010, at 12:56 PM, Bryan Duxbury wrote:

> What do you guys think of omitting bootstrap.sh from release tarballs?
> People seem super eager to run it, and it breaks things. If we didn't
> include it, then at least they'd *know* they can't run it.


Re: bootstrap.sh in tarballs

Posted by Bryan Duxbury <br...@rapleaf.com>.
I think it's pretty clearly non-source. It's a build helper that is
unnecessary in release tarballs.

On Wed, Aug 18, 2010 at 3:30 PM, Doug Cutting <cu...@apache.org> wrote:

> On 08/18/2010 12:56 PM, Bryan Duxbury wrote:
>
>> What do you guys think of omitting bootstrap.sh from release tarballs?
>>
>
> The full source code of a project should be the primary release artifact.
>  Is bootstrap.sh not project source code?
>
> I wonder if Thrift might instead be better of releasing multiple tarballs.
>  You could release a source tarball that's just a dump of subversion, and
> then also release other artifacts that are more directly useful to end
> users, e.g., pre-built tarballs for some languages, or easy-to-build
> tarballs for others.
>
> Doug
>

Re: bootstrap.sh in tarballs

Posted by Doug Cutting <cu...@apache.org>.
On 08/18/2010 03:54 PM, Joe Schaefer wrote:
> But my main attitude is let's not sweat the small stuff. If there's
> good reason not to release the script, and there seems to be, then
> let's not release it.  It's causing more confusion than it's worth.

+1

I hope you didn't feel I was sweating small stuff.  I wasn't trying to 
obstruct a release or otherwise create a roadblock.  But I have seen 
lots of projects get confused about source versus non-source in 
releases; at the extreme, leaving out sources and releasing binaries. 
So I think it's worth explaining ASF principles, in this case, that 
releases should include all the the source code.

I think if you hadn't said "nononono, Doug", but rather what Bryan said, 
"I think it's pretty clearly non-source." then our discussion would have 
been much shorter.  I wanted Bryan to think about whether it was source, 
and he did.  I didn't want to make that judgement for him.

Doug

Re: bootstrap.sh in tarballs

Posted by Bryan Duxbury <br...@rapleaf.com>.
I've made this change in TRUNK. Thanks all for the lively discussion.

On Wed, Aug 18, 2010 at 4:10 PM, Greg Stein <gs...@gmail.com> wrote:

> Agreed on all parts. This kind of script is very common practice to
> omit from an end-user release tarball.
>
> On Wed, Aug 18, 2010 at 18:54, Joe Schaefer <jo...@yahoo.com>
> wrote:
> > ----- Original Message ----
> >
> >> From: Doug Cutting <cu...@apache.org>
> >> To: thrift-dev@incubator.apache.org
> >> Sent: Wed, August 18, 2010 6:44:03 PM
> >> Subject: Re: bootstrap.sh in tarballs
> >>
> >> On 08/18/2010 03:33 PM, Joe Schaefer wrote:
> >> > Nononono Doug.  What  they're discussing is perfectly ok and is done
> >> > in other projects.  bootstrap.sh is a  pre-configuration script not
> >> > actual thrift source.
> >>
> >> That's why I  asked whether it was source code.
> >
> > You should probably take a look at the contents of bootstrap.sh for
> > yourself.  It's a trivial little convenience script that creates the
> > configure-based build scripts and Makefiles.
> >
> >> If it's not considered such, then it  shouldn't be included.  We're
> proposing
> >>to declare it "non-source"  primarily because it causes problems when
> included
> >>in releases.  Otherwise  we'd be happy to declare it part of the
> project's
> >>source, no?  I understand  there's precedent for this, and I'm fine
> excluding
> >>it, but, if there's another  way that permits us to release more
> source-like
> >>stuff and still not confuse  users, I think that'd be preferable.  It's
> not
> >>black-and-white,  source-or-non-source.
> >
> > Firstly what a project releases is up to them.  How they manufacture
> > a tarball for release out of the pristine sources in svn is also
> > their call.  All we ask is for a repeatable process.
> >
> > But my main attitude is let's not sweat the small stuff. If there's
> > good reason not to release the script, and there seems to be, then
> > let's not release it.  It's causing more confusion than it's worth.
> >
> >
> >
> >
>

Re: bootstrap.sh in tarballs

Posted by Greg Stein <gs...@gmail.com>.
Agreed on all parts. This kind of script is very common practice to
omit from an end-user release tarball.

On Wed, Aug 18, 2010 at 18:54, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: Doug Cutting <cu...@apache.org>
>> To: thrift-dev@incubator.apache.org
>> Sent: Wed, August 18, 2010 6:44:03 PM
>> Subject: Re: bootstrap.sh in tarballs
>>
>> On 08/18/2010 03:33 PM, Joe Schaefer wrote:
>> > Nononono Doug.  What  they're discussing is perfectly ok and is done
>> > in other projects.  bootstrap.sh is a  pre-configuration script not
>> > actual thrift source.
>>
>> That's why I  asked whether it was source code.
>
> You should probably take a look at the contents of bootstrap.sh for
> yourself.  It's a trivial little convenience script that creates the
> configure-based build scripts and Makefiles.
>
>> If it's not considered such, then it  shouldn't be included.  We're proposing
>>to declare it "non-source"  primarily because it causes problems when included
>>in releases.  Otherwise  we'd be happy to declare it part of the project's
>>source, no?  I understand  there's precedent for this, and I'm fine excluding
>>it, but, if there's another  way that permits us to release more source-like
>>stuff and still not confuse  users, I think that'd be preferable.  It's not
>>black-and-white,  source-or-non-source.
>
> Firstly what a project releases is up to them.  How they manufacture
> a tarball for release out of the pristine sources in svn is also
> their call.  All we ask is for a repeatable process.
>
> But my main attitude is let's not sweat the small stuff. If there's
> good reason not to release the script, and there seems to be, then
> let's not release it.  It's causing more confusion than it's worth.
>
>
>
>

Re: bootstrap.sh in tarballs

Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----

> From: Doug Cutting <cu...@apache.org>
> To: thrift-dev@incubator.apache.org
> Sent: Wed, August 18, 2010 6:44:03 PM
> Subject: Re: bootstrap.sh in tarballs
> 
> On 08/18/2010 03:33 PM, Joe Schaefer wrote:
> > Nononono Doug.  What  they're discussing is perfectly ok and is done
> > in other projects.  bootstrap.sh is a  pre-configuration script not
> > actual thrift source.
> 
> That's why I  asked whether it was source code.

You should probably take a look at the contents of bootstrap.sh for
yourself.  It's a trivial little convenience script that creates the
configure-based build scripts and Makefiles.

> If it's not considered such, then it  shouldn't be included.  We're proposing 
>to declare it "non-source"  primarily because it causes problems when included 
>in releases.  Otherwise  we'd be happy to declare it part of the project's 
>source, no?  I understand  there's precedent for this, and I'm fine excluding 
>it, but, if there's another  way that permits us to release more source-like 
>stuff and still not confuse  users, I think that'd be preferable.  It's not 
>black-and-white,  source-or-non-source.

Firstly what a project releases is up to them.  How they manufacture
a tarball for release out of the pristine sources in svn is also
their call.  All we ask is for a repeatable process.

But my main attitude is let's not sweat the small stuff. If there's
good reason not to release the script, and there seems to be, then
let's not release it.  It's causing more confusion than it's worth.


      

Re: bootstrap.sh in tarballs

Posted by Doug Cutting <cu...@apache.org>.
On 08/18/2010 03:33 PM, Joe Schaefer wrote:
> Nononono Doug.  What they're discussing is perfectly ok and is done
> in other projects.  bootstrap.sh is a pre-configuration script not
> actual thrift source.

That's why I asked whether it was source code.  If it's not considered 
such, then it shouldn't be included.  We're proposing to declare it 
"non-source" primarily because it causes problems when included in 
releases.  Otherwise we'd be happy to declare it part of the project's 
source, no?  I understand there's precedent for this, and I'm fine 
excluding it, but, if there's another way that permits us to release 
more source-like stuff and still not confuse users, I think that'd be 
preferable.  It's not black-and-white, source-or-non-source.

Doug

Re: bootstrap.sh in tarballs

Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----

> From: Doug Cutting <cu...@apache.org>
> To: thrift-dev@incubator.apache.org
> Sent: Wed, August 18, 2010 6:30:56 PM
> Subject: Re: bootstrap.sh in tarballs
> 
> On 08/18/2010 12:56 PM, Bryan Duxbury wrote:
> > What do you guys think of  omitting bootstrap.sh from  release tarballs?
> 
> The full source code of a project should be the primary  release artifact.
>  Is bootstrap.sh not project source code?

Nononono Doug.  What they're discussing is perfectly ok and is done
in other projects.  bootstrap.sh is a pre-configuration script not
actual thrift source.


      

Re: bootstrap.sh in tarballs

Posted by Doug Cutting <cu...@apache.org>.
On 08/18/2010 12:56 PM, Bryan Duxbury wrote:
> What do you guys think of omitting bootstrap.sh from release tarballs?

The full source code of a project should be the primary release 
artifact.  Is bootstrap.sh not project source code?

I wonder if Thrift might instead be better of releasing multiple 
tarballs.  You could release a source tarball that's just a dump of 
subversion, and then also release other artifacts that are more directly 
useful to end users, e.g., pre-built tarballs for some languages, or 
easy-to-build tarballs for others.

Doug

Re: bootstrap.sh in tarballs

Posted by Bryan Duxbury <br...@rapleaf.com>.
Would you mind opening a ticket with this suggestion?

On Wed, Aug 18, 2010 at 3:53 PM, Michael Lum <mi...@openx.org> wrote:

> +1, but I would also suggest adding something like this at the top of
> bootstrap.sh:
>
> have_ac_version=`autoconf --version | head -1 | cut -d' ' -f4`
> desired_ac_version=2.65
> if [ `expr $have_ac_version \>= $desired_ac_version` -eq "0" ]; then
>  echo "Must have autoconf $desired_ac_version of higher."
>  exit 1
> fi
>
> It can be confusing when autoconf silently runs successfully, but the build
> fails because an old autoconf is there.  e.g. see THRIFT-646.
>
>
> On 8/18/2010 1:59 PM, David Reiss wrote:
>
>> +1. This should be a 1-line change to Makefile.am.
>> ________________________________________
>> From: Mark Slee [mslee@facebook.com]
>> Sent: Wednesday, August 18, 2010 1:44 PM
>> To: thrift-dev@incubator.apache.org
>> Subject: RE: bootstrap.sh in tarballs
>>
>> Ack, I misread your original proposal. I thought you meant omitting the
>> *run* of bootstrap.sh, so that people would run it themselves (since they
>> seemed eager to do so).
>>
>> Totally agreed, just don't include bootstrap.sh in the release at all.
>>
>> +1
>>
>> -----Original Message-----
>> From: Bryan Duxbury [mailto:bryan@rapleaf.com]
>> Sent: Wednesday, August 18, 2010 1:42 PM
>> To: thrift-dev@incubator.apache.org
>> Subject: Re: bootstrap.sh in tarballs
>>
>> I guess I'm not really sure what the advantage of packaging it at all is.
>> When would a user *ever* use it when downloading a tarball?
>>
>> On Wed, Aug 18, 2010 at 1:36 PM, Mark Slee<ms...@facebook.com>  wrote:
>>
>>  How about making bootstrap.sh idempotent, so that it doesn't break things
>>> if someone runs it, but the release is already in a state where configure
>>> +
>>> make would compile just fine.
>>>
>>> Could be as simple as having boostrap.sh invoke cleanup.sh?
>>>
>>> I agree it's highly annoying that things go wrong when people run
>>> bootstrap.sh, and that definitely warrants fixing. But seems nice not to
>>> require it.
>>>
>>> -----Original Message-----
>>> From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu]
>>> Sent: Wednesday, August 18, 2010 1:33 PM
>>> To: thrift-dev@incubator.apache.org
>>> Subject: Re: bootstrap.sh in tarballs
>>>
>>> +1, you'll also want to get rid of cleanup.sh as that is also misleading
>>> and if you run it, you'd have to bootstrap to get back to a buildable
>>> thrift.
>>>
>>> On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
>>>
>>>> What do you guys think of omitting bootstrap.sh from release tarballs?
>>>> People seem super eager to run it, and it breaks things. If we didn't
>>>> include it, then at least they'd *know* they can't run it.
>>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>> Anthony Molinaro<an...@alumni.caltech.edu>
>>>
>>>

Re: bootstrap.sh in tarballs

Posted by Michael Lum <mi...@openx.org>.
+1, but I would also suggest adding something like this at the top of 
bootstrap.sh:

have_ac_version=`autoconf --version | head -1 | cut -d' ' -f4`
desired_ac_version=2.65
if [ `expr $have_ac_version \>= $desired_ac_version` -eq "0" ]; then
   echo "Must have autoconf $desired_ac_version of higher."
   exit 1
fi

It can be confusing when autoconf silently runs successfully, but the 
build fails because an old autoconf is there.  e.g. see THRIFT-646.

On 8/18/2010 1:59 PM, David Reiss wrote:
> +1. This should be a 1-line change to Makefile.am.
> ________________________________________
> From: Mark Slee [mslee@facebook.com]
> Sent: Wednesday, August 18, 2010 1:44 PM
> To: thrift-dev@incubator.apache.org
> Subject: RE: bootstrap.sh in tarballs
>
> Ack, I misread your original proposal. I thought you meant omitting the *run* of bootstrap.sh, so that people would run it themselves (since they seemed eager to do so).
>
> Totally agreed, just don't include bootstrap.sh in the release at all.
>
> +1
>
> -----Original Message-----
> From: Bryan Duxbury [mailto:bryan@rapleaf.com]
> Sent: Wednesday, August 18, 2010 1:42 PM
> To: thrift-dev@incubator.apache.org
> Subject: Re: bootstrap.sh in tarballs
>
> I guess I'm not really sure what the advantage of packaging it at all is.
> When would a user *ever* use it when downloading a tarball?
>
> On Wed, Aug 18, 2010 at 1:36 PM, Mark Slee<ms...@facebook.com>  wrote:
>
>> How about making bootstrap.sh idempotent, so that it doesn't break things
>> if someone runs it, but the release is already in a state where configure +
>> make would compile just fine.
>>
>> Could be as simple as having boostrap.sh invoke cleanup.sh?
>>
>> I agree it's highly annoying that things go wrong when people run
>> bootstrap.sh, and that definitely warrants fixing. But seems nice not to
>> require it.
>>
>> -----Original Message-----
>> From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu]
>> Sent: Wednesday, August 18, 2010 1:33 PM
>> To: thrift-dev@incubator.apache.org
>> Subject: Re: bootstrap.sh in tarballs
>>
>> +1, you'll also want to get rid of cleanup.sh as that is also misleading
>> and if you run it, you'd have to bootstrap to get back to a buildable
>> thrift.
>>
>> On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
>>> What do you guys think of omitting bootstrap.sh from release tarballs?
>>> People seem super eager to run it, and it breaks things. If we didn't
>>> include it, then at least they'd *know* they can't run it.
>>
>> --
>> ------------------------------------------------------------------------
>> Anthony Molinaro<an...@alumni.caltech.edu>
>>

RE: bootstrap.sh in tarballs

Posted by David Reiss <dr...@facebook.com>.
+1. This should be a 1-line change to Makefile.am.
________________________________________
From: Mark Slee [mslee@facebook.com]
Sent: Wednesday, August 18, 2010 1:44 PM
To: thrift-dev@incubator.apache.org
Subject: RE: bootstrap.sh in tarballs

Ack, I misread your original proposal. I thought you meant omitting the *run* of bootstrap.sh, so that people would run it themselves (since they seemed eager to do so).

Totally agreed, just don't include bootstrap.sh in the release at all.

+1

-----Original Message-----
From: Bryan Duxbury [mailto:bryan@rapleaf.com]
Sent: Wednesday, August 18, 2010 1:42 PM
To: thrift-dev@incubator.apache.org
Subject: Re: bootstrap.sh in tarballs

I guess I'm not really sure what the advantage of packaging it at all is.
When would a user *ever* use it when downloading a tarball?

On Wed, Aug 18, 2010 at 1:36 PM, Mark Slee <ms...@facebook.com> wrote:

> How about making bootstrap.sh idempotent, so that it doesn't break things
> if someone runs it, but the release is already in a state where configure +
> make would compile just fine.
>
> Could be as simple as having boostrap.sh invoke cleanup.sh?
>
> I agree it's highly annoying that things go wrong when people run
> bootstrap.sh, and that definitely warrants fixing. But seems nice not to
> require it.
>
> -----Original Message-----
> From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu]
> Sent: Wednesday, August 18, 2010 1:33 PM
> To: thrift-dev@incubator.apache.org
> Subject: Re: bootstrap.sh in tarballs
>
> +1, you'll also want to get rid of cleanup.sh as that is also misleading
> and if you run it, you'd have to bootstrap to get back to a buildable
> thrift.
>
> On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
> > What do you guys think of omitting bootstrap.sh from release tarballs?
> > People seem super eager to run it, and it breaks things. If we didn't
> > include it, then at least they'd *know* they can't run it.
>
> --
> ------------------------------------------------------------------------
> Anthony Molinaro                           <an...@alumni.caltech.edu>
>

RE: bootstrap.sh in tarballs

Posted by Mark Slee <ms...@facebook.com>.
Ack, I misread your original proposal. I thought you meant omitting the *run* of bootstrap.sh, so that people would run it themselves (since they seemed eager to do so).

Totally agreed, just don't include bootstrap.sh in the release at all.

+1

-----Original Message-----
From: Bryan Duxbury [mailto:bryan@rapleaf.com] 
Sent: Wednesday, August 18, 2010 1:42 PM
To: thrift-dev@incubator.apache.org
Subject: Re: bootstrap.sh in tarballs

I guess I'm not really sure what the advantage of packaging it at all is.
When would a user *ever* use it when downloading a tarball?

On Wed, Aug 18, 2010 at 1:36 PM, Mark Slee <ms...@facebook.com> wrote:

> How about making bootstrap.sh idempotent, so that it doesn't break things
> if someone runs it, but the release is already in a state where configure +
> make would compile just fine.
>
> Could be as simple as having boostrap.sh invoke cleanup.sh?
>
> I agree it's highly annoying that things go wrong when people run
> bootstrap.sh, and that definitely warrants fixing. But seems nice not to
> require it.
>
> -----Original Message-----
> From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu]
> Sent: Wednesday, August 18, 2010 1:33 PM
> To: thrift-dev@incubator.apache.org
> Subject: Re: bootstrap.sh in tarballs
>
> +1, you'll also want to get rid of cleanup.sh as that is also misleading
> and if you run it, you'd have to bootstrap to get back to a buildable
> thrift.
>
> On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
> > What do you guys think of omitting bootstrap.sh from release tarballs?
> > People seem super eager to run it, and it breaks things. If we didn't
> > include it, then at least they'd *know* they can't run it.
>
> --
> ------------------------------------------------------------------------
> Anthony Molinaro                           <an...@alumni.caltech.edu>
>

Re: bootstrap.sh in tarballs

Posted by Bryan Duxbury <br...@rapleaf.com>.
I guess I'm not really sure what the advantage of packaging it at all is.
When would a user *ever* use it when downloading a tarball?

On Wed, Aug 18, 2010 at 1:36 PM, Mark Slee <ms...@facebook.com> wrote:

> How about making bootstrap.sh idempotent, so that it doesn't break things
> if someone runs it, but the release is already in a state where configure +
> make would compile just fine.
>
> Could be as simple as having boostrap.sh invoke cleanup.sh?
>
> I agree it's highly annoying that things go wrong when people run
> bootstrap.sh, and that definitely warrants fixing. But seems nice not to
> require it.
>
> -----Original Message-----
> From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu]
> Sent: Wednesday, August 18, 2010 1:33 PM
> To: thrift-dev@incubator.apache.org
> Subject: Re: bootstrap.sh in tarballs
>
> +1, you'll also want to get rid of cleanup.sh as that is also misleading
> and if you run it, you'd have to bootstrap to get back to a buildable
> thrift.
>
> On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
> > What do you guys think of omitting bootstrap.sh from release tarballs?
> > People seem super eager to run it, and it breaks things. If we didn't
> > include it, then at least they'd *know* they can't run it.
>
> --
> ------------------------------------------------------------------------
> Anthony Molinaro                           <an...@alumni.caltech.edu>
>

RE: bootstrap.sh in tarballs

Posted by Mark Slee <ms...@facebook.com>.
How about making bootstrap.sh idempotent, so that it doesn't break things if someone runs it, but the release is already in a state where configure + make would compile just fine.

Could be as simple as having boostrap.sh invoke cleanup.sh?

I agree it's highly annoying that things go wrong when people run bootstrap.sh, and that definitely warrants fixing. But seems nice not to require it.

-----Original Message-----
From: Anthony Molinaro [mailto:anthonym@alumni.caltech.edu] 
Sent: Wednesday, August 18, 2010 1:33 PM
To: thrift-dev@incubator.apache.org
Subject: Re: bootstrap.sh in tarballs

+1, you'll also want to get rid of cleanup.sh as that is also misleading
and if you run it, you'd have to bootstrap to get back to a buildable
thrift.

On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
> What do you guys think of omitting bootstrap.sh from release tarballs?
> People seem super eager to run it, and it breaks things. If we didn't
> include it, then at least they'd *know* they can't run it.

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <an...@alumni.caltech.edu>

Re: bootstrap.sh in tarballs

Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
+1, you'll also want to get rid of cleanup.sh as that is also misleading
and if you run it, you'd have to bootstrap to get back to a buildable
thrift.

On Wed, Aug 18, 2010 at 12:56:12PM -0700, Bryan Duxbury wrote:
> What do you guys think of omitting bootstrap.sh from release tarballs?
> People seem super eager to run it, and it breaks things. If we didn't
> include it, then at least they'd *know* they can't run it.

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <an...@alumni.caltech.edu>