Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Hey,

We're just voting on our first release, and I spotted this file in the root
of the source:

https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD

It seems to be a sort of hybrid source/binary file. Very strange.

Can we ship this?

Thanks,

-- 
NS

Re: Shipping binary file in CloudStack release

[Bertrand Delacretaz <bd...@apache.org>]

On Sun, Oct 28, 2012 at 7:01 PM, Noah Slater <ns...@apache.org> wrote:
> ...We're just voting on our first release, and I spotted this file in the root
> of the source:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
>
> It seems to be a sort of hybrid source/binary file. Very strange.
>
> Can we ship this?...

I wouldn't define that file as source code, so IMO you cannot release
it as such.
Sounds like something for a separate -deps package.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Thanks for the clarification Roy.

On 31 October 2012 05:29, Roy T. Fielding <fi...@gbiv.com> wrote:

> [generic incubator comments -- nothing specific to CloudStack] ...
>
> On Oct 29, 2012, at 8:01 AM, Noah Slater wrote:
> > On 29 October 2012 14:48, Chip Childers <ch...@sungard.com>
> wrote:
> >> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <ns...@apache.org>
> wrote:
> >>> But regardless, you couldn't. A single -1 vote would be
> >>> enough to block the release. Binding or not binding. It doesn't
> matter. If
> >>> somebody expresses a real, and justified, concern about the artefact,
> then
> >>> you don't release until you've addressed that concern.
> >>
> >> If that's true, then should the release policy [1] be updated?
> >>
> >> [1] http://www.apache.org/dev/release.html#approving-a-release
> >
> >
> > Perhaps.
> >
> > I know I started out RMing with the idea that I just needed to collect
> more
> > +1 votes than -1 votes. But I think that's broken in practice. I think if
> > you have a valid, justified, -1 vote, and you release without addressing
> > it, then there is something SERIOUSLY wrong.
>
> It entirely depends on why the -1 is cast.
>
> Release votes are lazy majority decisions.  They are not at all like
> design decisions or adding a new committer.  A person could -1 a release
> simply because they are working on a new feature and want the group
> to wait until it can be included.  These are matters of opinion.
>
> If someone casts a -1 because something is seriously wrong, then
> we expect the rest of the PMC to wake up and say -1 as well.
> If they don't, then it isn't seriously wrong even if one or a
> few people think so.  IOW, if it is a serious issue then we can
> expect the majority to agree that it is a serious issue.  There
> is no need to change the rules to accomplish that.
>
> An RM can choose to stop working on a release at any time.
> We are all volunteers. However, the release decision is made
> by the PMC; if a vote has completed on an artifact, then
> that artifact can be copied to dist by anyone in the PMC.
> If something really bad is found in a voted-on-but-not-yet-announced
> release, then we expect the PMC to work together to ditch the old
> artifacts, fix the problem(s), and start again with a new
> version number.  If they don't, the project has a much larger
> problem than anything we might find in a release.
>
> Note that there has never been a case where a real problem is
> found and the rest of the group hasn't immediately shut down
> the release.  However, there have been cases where individuals
> have poisoned an entire project simply by dragging their feet on
> the release process for the sake of their own work or world-view.
>
> A release vote is required to be a majority decision, rather than
> a consensus decision, because Apache understands group dynamics.
> That cork is meant to be popped.  It is better for the group
> that it be popped on a regular basis, where regular is
> defined by the majority of the group.  The more, the merrier.
> Adding glue around the cork to make sure it doesn't pop, unless
> we really really mean it, is not a good plan.  We are far more
> likely to be hurt by a project that can't release than a project
> that occasionally releases too soon.  Folks often lose sight of
> that when focused on fixing a specific issue.
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
NS

Re: Shipping binary file in CloudStack release

["Roy T. Fielding" <fi...@gbiv.com>]

[generic incubator comments -- nothing specific to CloudStack] ...

On Oct 29, 2012, at 8:01 AM, Noah Slater wrote:
> On 29 October 2012 14:48, Chip Childers <ch...@sungard.com> wrote:
>> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <ns...@apache.org> wrote:
>>> But regardless, you couldn't. A single -1 vote would be
>>> enough to block the release. Binding or not binding. It doesn't matter. If
>>> somebody expresses a real, and justified, concern about the artefact, then
>>> you don't release until you've addressed that concern.
>> 
>> If that's true, then should the release policy [1] be updated?
>> 
>> [1] http://www.apache.org/dev/release.html#approving-a-release
> 
> 
> Perhaps.
> 
> I know I started out RMing with the idea that I just needed to collect more
> +1 votes than -1 votes. But I think that's broken in practice. I think if
> you have a valid, justified, -1 vote, and you release without addressing
> it, then there is something SERIOUSLY wrong.

It entirely depends on why the -1 is cast.

Release votes are lazy majority decisions.  They are not at all like
design decisions or adding a new committer.  A person could -1 a release
simply because they are working on a new feature and want the group
to wait until it can be included.  These are matters of opinion.

If someone casts a -1 because something is seriously wrong, then
we expect the rest of the PMC to wake up and say -1 as well.
If they don't, then it isn't seriously wrong even if one or a
few people think so.  IOW, if it is a serious issue then we can
expect the majority to agree that it is a serious issue.  There
is no need to change the rules to accomplish that.

An RM can choose to stop working on a release at any time.
We are all volunteers. However, the release decision is made
by the PMC; if a vote has completed on an artifact, then
that artifact can be copied to dist by anyone in the PMC.
If something really bad is found in a voted-on-but-not-yet-announced
release, then we expect the PMC to work together to ditch the old
artifacts, fix the problem(s), and start again with a new
version number.  If they don't, the project has a much larger
problem than anything we might find in a release.

Note that there has never been a case where a real problem is
found and the rest of the group hasn't immediately shut down
the release.  However, there have been cases where individuals
have poisoned an entire project simply by dragging their feet on
the release process for the sake of their own work or world-view.

A release vote is required to be a majority decision, rather than
a consensus decision, because Apache understands group dynamics.
That cork is meant to be popped.  It is better for the group
that it be popped on a regular basis, where regular is
defined by the majority of the group.  The more, the merrier.
Adding glue around the cork to make sure it doesn't pop, unless
we really really mean it, is not a good plan.  We are far more
likely to be hurt by a project that can't release than a project
that occasionally releases too soon.  Folks often lose sight of
that when focused on fixing a specific issue.

....Roy


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

On 29 October 2012 15:13, Chip Childers <ch...@sungard.com> wrote:

>
> I'll try to be more clear next time.  I'm holding the vote open
> specifically because of this outstanding question, *regardless* of the
> current tally.  That's what I was expressing.


Understood. I suspected we were on the same page, but I wanted to make sure.


> No disagreement.  Again, that's why I'm holding the vote open until we
> get enough clarity on the topic being discussed here.
>

Yep, and thank you. Especially considering the considerable delay in me
being able to find time to test.


> IMO, fixing this in the policy would include a statement about the RM
> having the right (but not the obligation) to abort the vote based on
> any individual issue raised by a voter.  But perhaps this is a topic
> for another list...
>
> Using this thread a specific example, I'll abort if the advice here is
> that waf needs to be removed in it's current form.
>

This may be an area for project bylaws.

On CouchDB, as the release manager, I added this to our release process:

"The release manager has the power to abort a vote at any point and for any
reason."

I advise we do the same for CloudStack.

Basically, as RM, as long as you're operating within the Apache framework
and principals, and there is a documented release policy that the community
(even tacitly) agrees with, then you are empowered to do whatever you want
within the limits of that.


-- 
NS

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 11:01 AM, Noah Slater <ns...@apache.org> wrote:
> On 29 October 2012 14:48, Chip Childers <ch...@sungard.com> wrote:
>
>> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <ns...@apache.org> wrote:
>> > Thanks for following up Chip. Though I do just want to clarify one
>> > misconception.
>> >
>> > On 29 October 2012 13:21, Chip Childers <ch...@sungard.com>
>> wrote:
>> >
>> >>
>> >> I actually have more than enough votes right now to close the thread
>> >> out on the project's dev list, and open up a vote for the IPMC.
>> >
>> >
>> > No you don't.
>> >
>> > To me, this sounds like you're saying "to be honest, I could just close
>> the
>> > vote and ship this right now if I wanted to." I'm not sure if that was
>> the
>> > intended message.
>>
>> Nope, that's not what I was saying.  That's taking a single comment
>> out of the context of the larger email.
>
>
> Well, in fairness, that is how I understood it *within* the context of your
> entire email. I hope you don't think I was just looking for something to
> take out of context to disagree with you on? I think we know each other
> better than that by now! ;)
>

I'll try to be more clear next time.  I'm holding the vote open
specifically because of this outstanding question, *regardless* of the
current tally.  That's what I was expressing.

>
>> > But regardless, you couldn't. A single -1 vote would be
>> > enough to block the release. Binding or not binding. It doesn't matter.
>> If
>> > somebody expresses a real, and justified, concern about the artefact,
>> then
>> > you don't release until you've addressed that concern.
>>
>> If that's true, then should the release policy [1] be updated?
>>
>> [1] http://www.apache.org/dev/release.html#approving-a-release
>
>
> Perhaps.
>
> I know I started out RMing with the idea that I just needed to collect more
> +1 votes than -1 votes. But I think that's broken in practice. I think if
> you have a valid, justified, -1 vote, and you release without addressing
> it, then there is something SERIOUSLY wrong.
>
> --
> NS

No disagreement.  Again, that's why I'm holding the vote open until we
get enough clarity on the topic being discussed here.

IMO, fixing this in the policy would include a statement about the RM
having the right (but not the obligation) to abort the vote based on
any individual issue raised by a voter.  But perhaps this is a topic
for another list...

Using this thread a specific example, I'll abort if the advice here is
that waf needs to be removed in it's current form.

-chip

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

On 29 October 2012 14:48, Chip Childers <ch...@sungard.com> wrote:

> On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <ns...@apache.org> wrote:
> > Thanks for following up Chip. Though I do just want to clarify one
> > misconception.
> >
> > On 29 October 2012 13:21, Chip Childers <ch...@sungard.com>
> wrote:
> >
> >>
> >> I actually have more than enough votes right now to close the thread
> >> out on the project's dev list, and open up a vote for the IPMC.
> >
> >
> > No you don't.
> >
> > To me, this sounds like you're saying "to be honest, I could just close
> the
> > vote and ship this right now if I wanted to." I'm not sure if that was
> the
> > intended message.
>
> Nope, that's not what I was saying.  That's taking a single comment
> out of the context of the larger email.


Well, in fairness, that is how I understood it *within* the context of your
entire email. I hope you don't think I was just looking for something to
take out of context to disagree with you on? I think we know each other
better than that by now! ;)



> > But regardless, you couldn't. A single -1 vote would be
> > enough to block the release. Binding or not binding. It doesn't matter.
> If
> > somebody expresses a real, and justified, concern about the artefact,
> then
> > you don't release until you've addressed that concern.
>
> If that's true, then should the release policy [1] be updated?
>
> [1] http://www.apache.org/dev/release.html#approving-a-release


Perhaps.

I know I started out RMing with the idea that I just needed to collect more
+1 votes than -1 votes. But I think that's broken in practice. I think if
you have a valid, justified, -1 vote, and you release without addressing
it, then there is something SERIOUSLY wrong.

-- 
NS

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater <ns...@apache.org> wrote:
> Thanks for following up Chip. Though I do just want to clarify one
> misconception.
>
> On 29 October 2012 13:21, Chip Childers <ch...@sungard.com> wrote:
>
>>
>> I actually have more than enough votes right now to close the thread
>> out on the project's dev list, and open up a vote for the IPMC.
>
>
> No you don't.
>
> To me, this sounds like you're saying "to be honest, I could just close the
> vote and ship this right now if I wanted to." I'm not sure if that was the
> intended message.

Nope, that's not what I was saying.  That's taking a single comment
out of the context of the larger email.

> But regardless, you couldn't. A single -1 vote would be
> enough to block the release. Binding or not binding. It doesn't matter. If
> somebody expresses a real, and justified, concern about the artefact, then
> you don't release until you've addressed that concern.

If that's true, then should the release policy [1] be updated?

[1] http://www.apache.org/dev/release.html#approving-a-release

> I have not given a -1, because I do not personally vote until I am
> confident enough that I am not going to change my mind. (Ironic given that
> I gave the release a +1 and then later changed my mind and retracted it.)
> But I have signalled a clear concern, and that is enough to halt the vote.
>
> AS IT HAPPENS, I am hoping that someone more experienced than me can assure
> us both that this is a minor issue and that we can proceed with the
> release, and get this fixed afterwards. I just don't
> feel comfortable making that judgement call myself.
>
> But I did want to make it clear that the technicalities of not having a -1
> are unimportant.
>
> --
> NS

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Veto or none veto, binding or non-binding, a -1 vote is an indication of a
problem. Process for process sake is pointless and unproductive, so I don't
care about the technicalities. A good RM should be looking for excuses to
halt the release. (Even though he may strongly want the release to be
successful.) This sort of approach is the only way we can maintain quality
in our releases. And releasing even though one or more people have raised
valid objections might be okay according to protocol, but it is indicative
of much more serious problems within the project or its community.

On 29 October 2012 15:09, Emmanuel Lécharny <el...@gmail.com> wrote:

> Le 10/29/12 3:39 PM, Noah Slater a écrit :
>
>  Thanks for following up Chip. Though I do just want to clarify one
>> misconception.
>>
>> On 29 October 2012 13:21, Chip Childers <ch...@sungard.com>
>> wrote:
>>
>>  I actually have more than enough votes right now to close the thread
>>> out on the project's dev list, and open up a vote for the IPMC.
>>>
>>
>> No you don't.
>>
>> To me, this sounds like you're saying "to be honest, I could just close
>> the
>> vote and ship this right now if I wanted to." I'm not sure if that was the
>> intended message. But regardless, you couldn't. A single -1 vote would be
>> enough to block the release.
>>
>
>  Binding or not binding. It doesn't matter. If
>> somebody expresses a real, and justified, concern about the artefact, then
>> you don't release until you've addressed that concern.
>>
> Technically speaking, for releases, a -1 is not a veto :
>
> http://www.apache.org/**foundation/voting.html<http://www.apache.org/foundation/voting.html>
> " Votes on Package Releases
>
> Votes on whether a package is ready to be released use majority approval <
> http://www.apache.org/**foundation/glossary.html#**MajorityApproval<http://www.apache.org/foundation/glossary.html#MajorityApproval>>
> -- i.e. at least three PMC members must vote affirmatively for release, and
> there must be more positive than negative votes. *Releases may not be
> vetoed.* Generally the community will cancel the release vote if anyone
> identifies serious problems, but in most cases the ultimate decision, lies
> with the individual serving as release manager. The specifics of the
> process may vary from project to project, but the 'minimum quorum of three
> +1 votes' rule is universal."
>
> However, having -1 would be a sign that something goes wrong. Either on
> the community side, or on the voter side ;) Better try to see why a -1 (or
> many) have been casted before going for the release in such a case.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<ge...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>
>


-- 
NS

Re: Shipping binary file in CloudStack release

[Emmanuel Lécharny <el...@gmail.com>]

Le 10/29/12 3:39 PM, Noah Slater a écrit :
> Thanks for following up Chip. Though I do just want to clarify one
> misconception.
>
> On 29 October 2012 13:21, Chip Childers <ch...@sungard.com> wrote:
>
>> I actually have more than enough votes right now to close the thread
>> out on the project's dev list, and open up a vote for the IPMC.
>
> No you don't.
>
> To me, this sounds like you're saying "to be honest, I could just close the
> vote and ship this right now if I wanted to." I'm not sure if that was the
> intended message. But regardless, you couldn't. A single -1 vote would be
> enough to block the release.

> Binding or not binding. It doesn't matter. If
> somebody expresses a real, and justified, concern about the artefact, then
> you don't release until you've addressed that concern.
Technically speaking, for releases, a -1 is not a veto :

http://www.apache.org/foundation/voting.html
" Votes on Package Releases

Votes on whether a package is ready to be released use majority approval 
<http://www.apache.org/foundation/glossary.html#MajorityApproval> -- 
i.e. at least three PMC members must vote affirmatively for release, and 
there must be more positive than negative votes. *Releases may not be 
vetoed.* Generally the community will cancel the release vote if anyone 
identifies serious problems, but in most cases the ultimate decision, 
lies with the individual serving as release manager. The specifics of 
the process may vary from project to project, but the 'minimum quorum of 
three +1 votes' rule is universal."

However, having -1 would be a sign that something goes wrong. Either on 
the community side, or on the voter side ;) Better try to see why a -1 
(or many) have been casted before going for the release in such a case.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Thanks for following up Chip. Though I do just want to clarify one
misconception.

On 29 October 2012 13:21, Chip Childers <ch...@sungard.com> wrote:

>
> I actually have more than enough votes right now to close the thread
> out on the project's dev list, and open up a vote for the IPMC.


No you don't.

To me, this sounds like you're saying "to be honest, I could just close the
vote and ship this right now if I wanted to." I'm not sure if that was the
intended message. But regardless, you couldn't. A single -1 vote would be
enough to block the release. Binding or not binding. It doesn't matter. If
somebody expresses a real, and justified, concern about the artefact, then
you don't release until you've addressed that concern.

I have not given a -1, because I do not personally vote until I am
confident enough that I am not going to change my mind. (Ironic given that
I gave the release a +1 and then later changed my mind and retracted it.)
But I have signalled a clear concern, and that is enough to halt the vote.

AS IT HAPPENS, I am hoping that someone more experienced than me can assure
us both that this is a minor issue and that we can proceed with the
release, and get this fixed afterwards. I just don't
feel comfortable making that judgement call myself.

But I did want to make it clear that the technicalities of not having a -1
are unimportant.

-- 
NS

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Thanks for investigating this, Chip.

I am happy with us proceeding, but would caution us to think about
addressing or documenting this in a later release.

I'd say wait until tomorrow to see if anyone else objects then wrap up the
vote.

Let's ship this thing!

On 29 October 2012 16:21, Chip Childers <ch...@sungard.com> wrote:

> On Mon, Oct 29, 2012 at 11:37 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Mon, Oct 29, 2012 at 4:32 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> >> Bertrand, is a compressed archive of source a source or a binary?
> >
> > hehe...right, you said earlier in this thread that the file in
> > question is actually just compressed source code, is that correct?
>
> That's correct.  We ( the project ) were actually concerned that it
> was compiled python code.  Benson is right.  In reality, it's just
> compressed source.  I have extracted it and reviewed the contents.
> It's the waf source.
>
> > If yes, it's just weird to include it in that form but I agree that
> > the "no binaries" problem is not that important then, if one can
> > decompress and verify the actual source code. The reason we don't
> > release binaries is that it's usually impossible to verify them as
> > being harmless.
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
NS

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 11:37 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Mon, Oct 29, 2012 at 4:32 PM, Benson Margulies <bi...@gmail.com> wrote:
>> Bertrand, is a compressed archive of source a source or a binary?
>
> hehe...right, you said earlier in this thread that the file in
> question is actually just compressed source code, is that correct?

That's correct.  We ( the project ) were actually concerned that it
was compiled python code.  Benson is right.  In reality, it's just
compressed source.  I have extracted it and reviewed the contents.
It's the waf source.

> If yes, it's just weird to include it in that form but I agree that
> the "no binaries" problem is not that important then, if one can
> decompress and verify the actual source code. The reason we don't
> release binaries is that it's usually impossible to verify them as
> being harmless.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Oct 29, 2012 at 4:32 PM, Benson Margulies <bi...@gmail.com> wrote:
> Bertrand, is a compressed archive of source a source or a binary?

hehe...right, you said earlier in this thread that the file in
question is actually just compressed source code, is that correct?

If yes, it's just weird to include it in that form but I agree that
the "no binaries" problem is not that important then, if one can
decompress and verify the actual source code. The reason we don't
release binaries is that it's usually impossible to verify them as
being harmless.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Benson Margulies <bi...@gmail.com>]

Bertrand, is a compressed archive of source a source or a binary?

On Oct 29, 2012, at 11:28 AM, Noah Slater <ns...@apache.org> wrote:

> Nice summary Bertrand.
>
>
> On 29 October 2012 15:22, Bertrand Delacretaz <bd...@apache.org>wrote:
>
>> Hi,
>>
>> On Mon, Oct 29, 2012 at 2:21 PM, Chip Childers
>> <ch...@sungard.com> wrote:
>>> ...Waf is a packaging utility, used to create RPMs and DEBs.  Work is
>>> currently ongoing to remove it (and it's use) from the project
>>> entirely...
>>> ...That will be several weeks of work (not days),
>>> which is significantly longer than the community's desire to get a
>>> first podling release out the door...
>>
>> I don't think any Incubator PMC member is asking you to remove that
>> dependency, as I see it the only issue is that you are currently
>> aiming to release in in binary form.
>>
>>> ...It's one line of bytecode within a file that is not core to the
>>> project itself ...
>>
>> I don't think the issue is how big or how small that thing is: we do
>> not release binaries, see http://www.apache.org/dev/release.html
>>
>> So IMO your options now are:
>>
>> a) Fix the problem and recut your release without that binary. Make it
>> a separate -deps convenience package.
> I concur with Chip that this would come with a non-negligible cost to
> community spirit at this point. We've already been through a few rounds. I
> would +0 this is the community wanted to do it, but I would also
> be disappointed that we had to stop the release for something so minor.
>
>
>> b) Come up with a documented plan (issue in your tracker for example)
>> for how you're going to remove it from future releases, and still try
>> to get this release through.
>
> Given the relative unimportance, and size, of the file in question, I would
> be willing to cast a binding +1 vote (as mentor and very new member of the
> Incubator PMC) on this, if we would say for definite that we remove this
> problem for the next release. But I was looking for some confirmation from
> this list that this is OK.
>
>
>> c) Try to convince us that such things are not really important, which
>> does not seem successful so far.
>
> Yes, I don't think that's going to happen.
>
>
>> IMO, doing a) will get you immediate +1s. It's not uncommon for
>> podling releases to go through a few iterations before being accepted,
>> so I'm not sure what the problem with creating a separate -deps
>> package is.
>>
>> Choosing b) or c) lowers your chances for mentors and Incubator PMC to
>> give their +1s to the release.
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> --
> NS

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Noah Slater <ns...@apache.org>]

Nice summary Bertrand.


On 29 October 2012 15:22, Bertrand Delacretaz <bd...@apache.org>wrote:

> Hi,
>
> On Mon, Oct 29, 2012 at 2:21 PM, Chip Childers
> <ch...@sungard.com> wrote:
> > ...Waf is a packaging utility, used to create RPMs and DEBs.  Work is
> > currently ongoing to remove it (and it's use) from the project
> > entirely...
> > ...That will be several weeks of work (not days),
> > which is significantly longer than the community's desire to get a
> > first podling release out the door...
>
> I don't think any Incubator PMC member is asking you to remove that
> dependency, as I see it the only issue is that you are currently
> aiming to release in in binary form.
>
> > ...It's one line of bytecode within a file that is not core to the
> > project itself ...
>
> I don't think the issue is how big or how small that thing is: we do
> not release binaries, see http://www.apache.org/dev/release.html
>
> So IMO your options now are:
>
> a) Fix the problem and recut your release without that binary. Make it
> a separate -deps convenience package.
>
>
I concur with Chip that this would come with a non-negligible cost to
community spirit at this point. We've already been through a few rounds. I
would +0 this is the community wanted to do it, but I would also
be disappointed that we had to stop the release for something so minor.


> b) Come up with a documented plan (issue in your tracker for example)
> for how you're going to remove it from future releases, and still try
> to get this release through.
>

Given the relative unimportance, and size, of the file in question, I would
be willing to cast a binding +1 vote (as mentor and very new member of the
Incubator PMC) on this, if we would say for definite that we remove this
problem for the next release. But I was looking for some confirmation from
this list that this is OK.


> c) Try to convince us that such things are not really important, which
> does not seem successful so far.
>

Yes, I don't think that's going to happen.


> IMO, doing a) will get you immediate +1s. It's not uncommon for
> podling releases to go through a few iterations before being accepted,
> so I'm not sure what the problem with creating a separate -deps
> package is.
>
> Choosing b) or c) lowers your chances for mentors and Incubator PMC to
> give their +1s to the release.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
NS

Re: Shipping binary file in CloudStack release

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Oct 29, 2012 at 2:21 PM, Chip Childers
<ch...@sungard.com> wrote:
> ...Waf is a packaging utility, used to create RPMs and DEBs.  Work is
> currently ongoing to remove it (and it's use) from the project
> entirely...
> ...That will be several weeks of work (not days),
> which is significantly longer than the community's desire to get a
> first podling release out the door...

I don't think any Incubator PMC member is asking you to remove that
dependency, as I see it the only issue is that you are currently
aiming to release in in binary form.

> ...It's one line of bytecode within a file that is not core to the
> project itself ...

I don't think the issue is how big or how small that thing is: we do
not release binaries, see http://www.apache.org/dev/release.html

So IMO your options now are:

a) Fix the problem and recut your release without that binary. Make it
a separate -deps convenience package.

b) Come up with a documented plan (issue in your tracker for example)
for how you're going to remove it from future releases, and still try
to get this release through.

c) Try to convince us that such things are not really important, which
does not seem successful so far.

IMO, doing a) will get you immediate +1s. It's not uncommon for
podling releases to go through a few iterations before being accepted,
so I'm not sure what the problem with creating a separate -deps
package is.

Choosing b) or c) lowers your chances for mentors and Incubator PMC to
give their +1s to the release.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

Hi all,

I'm the RM for the release, so I wanted to provide some context to
Noah's question.  Some of this has already been mentioned on the
project's vote thread, but I'll bring it up again here to see if there
are any thoughts to help us decide if this is a blocker or not.  At
this point, I'm holding the vote thread open after 7 days of voting
(with a current +1 count of 5 PPMC votes, 4 mentors, and another 16
community votes - with no -1's or 0's), until I get a better feel for
the level of concern on this issue.

Here's the background:

Waf is a packaging utility, used to create RPMs and DEBs.  Work is
currently ongoing to remove it (and it's use) from the project
entirely, so we're not doing something that isn't already targeted for
being undone as fast as possible.   The challenge we have as a
community is that the removal of Waf will require a pretty heavy
amount of development time and another full round of functional /
regression testing.  That will be several weeks of work (not days),
which is significantly longer than the community's desire to get a
first podling release out the door (our original goal was for the end
of the summer).

And here's my current thinking:

It's one line of bytecode within a file that is not core to the
project itself (it's only a build utility), that has a clearly marked
license for file itself (so distribution is OK from a licensing
standpoint), that is only used as a quick way to create packages for
Linux distros (not to do the actual project builds), and that will be
ignored by any distro packagers that want to create proper RPMs / DEBs
anyway.

IMO, this does not represent a serious enough issue to block a
release.  As far as I understand the point of the incubation process,
this is the place where minor issues can be addressed over time.  (I'm
new to ASF,  so please do correct me if I'm wrong about that.)

I actually have more than enough votes right now to close the thread
out on the project's dev list, and open up a vote for the IPMC.  That
being said, I'm new to ASF and want us to get things right.  I
certainly don't want to use formalities like the voting rules process
to push past something that actually is a major problem, but I really
don't want to abort the vote due to what I personally view as a minor
issue.  It will potentially cause harm to the community, which has
been developing very nicely over the last several months.

Anyway, that's what we're struggling with.  Looking forward to your opinions...

-chip

On Sun, Oct 28, 2012 at 2:01 PM, Noah Slater <ns...@apache.org> wrote:
> Hey,
>
> We're just voting on our first release, and I spotted this file in the root
> of the source:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
>
> It seems to be a sort of hybrid source/binary file. Very strange.
>
> Can we ship this?
>
> Thanks,
>
> --
> NS

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 11:41 AM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> On Mon, Oct 29, 2012 at 5:57 AM, Benson Margulies <bi...@gmail.com> wrote:
>
>> So, it's no more good (or bad) than shipping a .tar.bz2 of
>> some category A open source code (given the license).
>
> +1
>
> From your description, this is different from a compiled object file, it's
> compressed source.  No information is lost, it's just obfuscated and can be
> restored.  It's a little annoying as would be releasing source transformed via
> rot-13, but it's still source IMO.
>
>> It would be more better, I suppose, to grab the corresponding source
>> tree and run their build script as part of your build script, but I'm
>> a bit puzzled as to whether this, as is, is actually a problem.
>
> Doesn't seem like a blocker to me, so long as people have expanded the archive
> and are happy with what's inside.

Thanks all.

I've just expanded the archive, and reviewed the contents.  It indeed
appears to be the source code for version 1.5.18 of waf.  I can't find
any issues with including this source code (excluding the obvious
weirdness about how it's included in our release package).

Any other concerns?

> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Marvin Humphrey <ma...@rectangular.com>]

On Mon, Oct 29, 2012 at 5:57 AM, Benson Margulies <bi...@gmail.com> wrote:

> So, it's no more good (or bad) than shipping a .tar.bz2 of
> some category A open source code (given the license).

+1

>From your description, this is different from a compiled object file, it's
compressed source.  No information is lost, it's just obfuscated and can be
restored.  It's a little annoying as would be releasing source transformed via
rot-13, but it's still source IMO.

> It would be more better, I suppose, to grab the corresponding source
> tree and run their build script as part of your build script, but I'm
> a bit puzzled as to whether this, as is, is actually a problem.

Doesn't seem like a blocker to me, so long as people have expanded the archive
and are happy with what's inside.

Marvin Humphrey

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 9:38 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Mon, Oct 29, 2012 at 8:57 AM, Benson Margulies <bi...@gmail.com> wrote:
>> On Mon, Oct 29, 2012 at 4:26 AM, Florian Holeczek <fl...@holeczek.de> wrote:
>>> Hi Noah,
>>>
>>>> We're just voting on our first release, and I spotted this file in the root
>>>> of the source:
>>>>
>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
>>>>
>>>> It seems to be a sort of hybrid source/binary file. Very strange.
>>>>
>>>> Can we ship this?
>>>
>>> it's this one: http://code.google.com/p/waf/
>>> The website says it's licensed under the "New BSD License".
>>
>> This file is a an installer for an entire subsystem of python stuff,
>> encoded with python pickle, built by their build script. If I
>> understand what's going on, running it unpacks a tree of python
>> *source*. So, it's no more good (or bad) than shipping a .tar.bz2 of
>> some category A open source code (given the license).
>>
>> It would be more better, I suppose, to grab the corresponding source
>> tree and run their build script as part of your build script, but I'm
>> a bit puzzled as to whether this, as is, is actually a problem.
>
> Benson,
>
> I absolutely agree that it would be better to pull from the Waf
> project source, and build prior to a user using it.  That being said,
> your point about being puzzled as to whether it's a blocker or not is
> exactly our issue (hence raising it on this list).

Bringing this thread back to the topic at hand, any further opinions
about the severity of this file being include in the release artifact?

Looking forward to your inputs.

>
>>>
>>> Regards
>>>  Florian
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Chip Childers <ch...@sungard.com>]

On Mon, Oct 29, 2012 at 8:57 AM, Benson Margulies <bi...@gmail.com> wrote:
> On Mon, Oct 29, 2012 at 4:26 AM, Florian Holeczek <fl...@holeczek.de> wrote:
>> Hi Noah,
>>
>>> We're just voting on our first release, and I spotted this file in the root
>>> of the source:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
>>>
>>> It seems to be a sort of hybrid source/binary file. Very strange.
>>>
>>> Can we ship this?
>>
>> it's this one: http://code.google.com/p/waf/
>> The website says it's licensed under the "New BSD License".
>
> This file is a an installer for an entire subsystem of python stuff,
> encoded with python pickle, built by their build script. If I
> understand what's going on, running it unpacks a tree of python
> *source*. So, it's no more good (or bad) than shipping a .tar.bz2 of
> some category A open source code (given the license).
>
> It would be more better, I suppose, to grab the corresponding source
> tree and run their build script as part of your build script, but I'm
> a bit puzzled as to whether this, as is, is actually a problem.

Benson,

I absolutely agree that it would be better to pull from the Waf
project source, and build prior to a user using it.  That being said,
your point about being puzzled as to whether it's a blocker or not is
exactly our issue (hence raising it on this list).

>>
>> Regards
>>  Florian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Benson Margulies <bi...@gmail.com>]

On Mon, Oct 29, 2012 at 4:26 AM, Florian Holeczek <fl...@holeczek.de> wrote:
> Hi Noah,
>
>> We're just voting on our first release, and I spotted this file in the root
>> of the source:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
>>
>> It seems to be a sort of hybrid source/binary file. Very strange.
>>
>> Can we ship this?
>
> it's this one: http://code.google.com/p/waf/
> The website says it's licensed under the "New BSD License".

This file is a an installer for an entire subsystem of python stuff,
encoded with python pickle, built by their build script. If I
understand what's going on, running it unpacks a tree of python
*source*. So, it's no more good (or bad) than shipping a .tar.bz2 of
some category A open source code (given the license).

It would be more better, I suppose, to grab the corresponding source
tree and run their build script as part of your build script, but I'm
a bit puzzled as to whether this, as is, is actually a problem.


>
> Regards
>  Florian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Shipping binary file in CloudStack release

[Florian Holeczek <fl...@holeczek.de>]

Hi Noah,

> We're just voting on our first release, and I spotted this file in the root
> of the source:
> 
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob_plain;f=waf;hb=HEAD
> 
> It seems to be a sort of hybrid source/binary file. Very strange.
> 
> Can we ship this?

it's this one: http://code.google.com/p/waf/
The website says it's licensed under the "New BSD License".

Regards
 Florian

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org