You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/12/17 18:46:03 UTC

[DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Please use this thread for discussion.

Thanks,
-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 9:35 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> No, I'm using OSX.  What error did you get?
>Unable to copy the README.pb file. Has that actually been checked in?
Hah!  That might help.  But I think you're trying to running the
release-pixelbender target which I was thinking would be on the
"unsupported" list.  I think build-pixelbender, and maybe a
clean-pixelbender are the only targets I think need to run in this
package.  Oh, and some target that will copy the files to an sdk tree.
Again, I'm just trying to make this as simple as possible, so not having
the package be able to create another package seems optional.

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> No, I'm using OSX.  What error did you get?
Unable to copy the README.pb file. Has that actually been checked in?

Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 5:33 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> The steps to build is in there already (build-pixelbender target).
>Which currently doesn't work (for me anyway). Perhaps it's an OSX issue?
No, I'm using OSX.  What error did you get?

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> The steps to build is in there already (build-pixelbender target).
Which currently doesn't work (for me anyway). Perhaps it's an OSX issue?

> Flex-utilities may have more than one thing coming out of it someday.
Sure but each "sub project" has it's own directory so it far easier to know what went into a release etc etc

>  But maybe I'll pull the PB targets into  their own pixel bender.xml file.
I'd prefer it was more self contained but other people may prefer the current everything in the SDK approach.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 4:36 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> but there is no steps for working from the source kit per-se as you
>>pointed out.
>Which is required for a valid release. Although in this case it's a
>little unusual as it not aimed at users, there not much you can do with a
>pixel bender release on it own.
The steps to build is in there already (build-pixelbender target).  I'm
not sure any further instructions are required.
>
>> I think we can.  The main SDK release is a subset of flex-sdk already
>> (doesn't have all of mustella).
>A user of the SDK doesn't require mustella. It's more have 2 different
>releases from the same tree I was unsure about.
I guess we can ask again, but I recall Bertrand saying it was ok.
Flex-utilities may have more than one thing coming out of it someday.

>
>> No, the SDK uses the latest package as an upstream dependency.  We'd
>>only
>> need to vote on the pixel bender package if its contents were to change.
>Which is unlikely, over time the build file etc will get out of sync with
>the release. You would then have to check out the SDK from a point in
>time (hopefully tagged) to get the pixel bender release code right?
That's the point of tags, no?  But maybe I'll pull the PB targets into
their own pixel bender.xml file.


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> but there is no steps for working from the source kit per-se as you pointed out.
Which is required for a valid release. Although in this case it's a little unusual as it not aimed at users, there not much you can do with a pixel bender release on it own.

> I think we can.  The main SDK release is a subset of flex-sdk already
> (doesn't have all of mustella).
A user of the SDK doesn't require mustella. It's more have 2 different releases from the same tree I was unsure about.

> No, the SDK uses the latest package as an upstream dependency.  We'd only
> need to vote on the pixel bender package if its contents were to change.
Which is unlikely, over time the build file etc will get out of sync with the release. You would then have to check out the SDK from a point in time (hopefully tagged) to get the pixel bender release code right?

>  I'm just trying to do the least amount of work to release this package. 
Fair enough.

> What if I make a clean-pixelbender target.  Would that be sufficient?
Works for me.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 3:19 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> OK.  Good point about the overlay of the notice files.  I'll add an ant
>> target to copy just the pbk/pbj.
>That would be required for the CI anyway wouldn't it?
The downloads.xml does the right thing (downloads the -bin.zip, only
copies out the pbk/pbj), but there is no steps for working from the source
kit per-se as you pointed out.  Maybe it isn't really necessary either and
I'll just note in the README or RELEASE_NOTES that you can just copy a
certain part of the tree.

>
>> The goal was to not move the PBK files out to a different repo and
>> instead, package a subset of the flex-sdk repo.
>Can we actually do that ie does it follow Apache release guidelines? I'm
>not sure. 
I think we can.  The main SDK release is a subset of flex-sdk already
(doesn't have all of mustella).

>Does that mean we also need to vote on a release a version of pixel
>bender when making a new SDK release?
No, the SDK uses the latest package as an upstream dependency.  We'd only
need to vote on the pixel bender package if its contents were to change.

>
>>  Do you think everything on this list is required?
>Not everything, It is expected that someone can take the source release
>and compile it and verify it to what's in version control.
Yeah, I'll make a tag for the next RC.
>
>> 1) can we tell folks in the RELEASE_NOTES not to run release-pixelbender
>> target and say that it is for extracting this package from a full
>>flex-sdk
>> repo?
>We can say what we want in RELEASE_NOTE/README. But it seem odd to me
>that you need the full Flex SDK is required just to make a release of
>pixel bender. What do other people think?
It may not be required, I'm just trying to do the least amount of work to
release this package.  The fewer ant targets we need to make run, the
better.

>
>> 2) can we say that the LICENSE file contains extra licenses that may
>>only
>> apply to the full repo?
>I would assume that LICENSE/NOTICE file needs to refer to the actual
>release (and any upstream projects) they are in not any downstream
>projects. The Apache licence make reference to the NOTICE file so we
>would need to legally comply with that.
>
>> 3) can we say that the build.xml and properties files reference the full
>> flex-sdk build?
>Does this mean we need to make a new PB release every time they change?
No.  We don't need to.
>
>> 4) can we say that the clean target doesn't work?
>I think it would be expected that it should work.
What if I make a clean-pixelbender target.  Would that be sufficient?
>
>Thanks,
>Justin


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
I am sorry Alex, but I am feeling like the more I ask questions, the less I understand, so I give up!

Do whatever you think is good and I will +1 the release.

Sorry for all the hassle.

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : jeudi 19 décembre 2013 15:20
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/19/13 3:24 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>I'm proposing that the pixelbender.xml only contains the "main" target 
>>as the release policy only seems to require instructions on how to 
>>compile the source, not necessarily create a >release.  The 
>>release-pixelbender target will remain in the main build.xml
>OK.
>
>Another question, you said:
>>adding a pixelbender.xml file with a main target that does the 
>>compile, a clean target that deletes the PBJ and a copy target that  
>>copies the PBJs into place in the sdk tree.
>
>I don't understand this step.
>
>I may have understood wrongly, but it seems that you are proposing two 
>ways of having the PBJ into the SDK:
>
>1) directly, by compiling the PBK and storing the PBJ in place in the 
>SDK tree.
> This is how it works now, and this option can be done only if 
>window/gpu are avaible
>
>2) indirectly, by downloading the released pixel-bender package from 
>dist repo.
>This is to be done when window/gpu is not available, eg. when running 
>the build on Jenkins without a service.
>
>Is that correct ?
Not quite, I am proposing a third way.  Justin pointed out there should be an approved method of using the PBJ's if you work from a source package.
If you expand the source package into the flex-sdk tree, or build the source package and copy the entire tree into the flex-sdk tree, the NOTICE, README and RELEASE_NOTES files in the top-level folder would be
overridden.   So, the "copy" target will copy the PBJ files.  We could
instruct folks to use flags to not overwrite files, but that's probably too error prone.  But we could also try to instruct folks to simply point to the compiled source package and not have this third option.

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/19/13 3:24 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>I'm proposing that the pixelbender.xml only contains the "main" target
>>as the release policy only seems to require instructions on how to
>>compile the source, not necessarily create a >release.  The
>>release-pixelbender target will remain in the main build.xml
>OK.
>
>Another question, you said:
>>adding a pixelbender.xml file with a main target that does the compile,
>>a clean target that deletes the PBJ and a copy target that
>> copies the PBJs into place in the sdk tree.
>
>I don't understand this step.
>
>I may have understood wrongly, but it seems that you are proposing two
>ways of having the PBJ into the SDK:
>
>1) directly, by compiling the PBK and storing the PBJ in place in the SDK
>tree. 
> This is how it works now, and this option can be done only if window/gpu
>are avaible
>
>2) indirectly, by downloading the released pixel-bender package from dist
>repo.
>This is to be done when window/gpu is not available, eg. when running the
>build on Jenkins without a service.
>
>Is that correct ?
Not quite, I am proposing a third way.  Justin pointed out there should be
an approved method of using the PBJ's if you work from a source package.
If you expand the source package into the flex-sdk tree, or build the
source package and copy the entire tree into the flex-sdk tree, the
NOTICE, README and RELEASE_NOTES files in the top-level folder would be
overridden.   So, the "copy" target will copy the PBJ files.  We could
instruct folks to use flags to not overwrite files, but that's probably
too error prone.  But we could also try to instruct folks to simply point
to the compiled source package and not have this third option.

-Alex


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
>I'm proposing that the pixelbender.xml only contains the "main" target as the release policy only seems to require instructions on how to compile the source, not necessarily create a >release.  The release-pixelbender target will remain in the main build.xml
OK.

Another question, you said:
>adding a pixelbender.xml file with a main target that does the compile, a clean target that deletes the PBJ and a copy target that 
> copies the PBJs into place in the sdk tree.

I don't understand this step.

I may have understood wrongly, but it seems that you are proposing two ways of having the PBJ into the SDK:

1) directly, by compiling the PBK and storing the PBJ in place in the SDK tree. 
 This is how it works now, and this option can be done only if window/gpu are avaible

2) indirectly, by downloading the released pixel-bender package from dist repo.
This is to be done when window/gpu is not available, eg. when running the build on Jenkins without a service.

Is that correct ?

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : jeudi 19 décembre 2013 07:53
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/18/13 3:08 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>Sorry Alex, I missed you proposition in the last email (this 
>interleaved multithreaded discussions are a real pain...)
> 
>> Right now, I'm thinking of:
>> 1) adding a pixelbender.xml file with a main target that does the 
>> compile, a clean target that deletes the PBJ and a copy target that 
>> copies the PBJs into place in the sdk tree.
>> 2) add more to the release notes that point you to this xml file
>> 3) Separate NOTICE
>> 4) tagging flex-sdk repo
>> 5) Add git location to README (actually describe how this is a subset 
>> of
>> flex-sdk)
>> 
>> You'll still use release-pixelbender from the main build.xml to 
>> create the package.
>
>
>I don't understand the steps.
>You say that the new "pixel-bender.xml" does the compile and copies the 
>PBJ into the SDK trees.
>What's the difference with  the release-pixelbender that will create 
>the package.
>
>Does it mean there are two ways of compiling the PBK? One to make the 
>PB package, and another one directly inside the SDK, like it works 
>currently ?
Our build scripts for flex-sdk, flex-falcon, and flex-asjs have a "main"
target that compiles the sources, and a separate "release" target that creates the artifacts for the release by compressing the source files.

I'm proposing that the pixelbender.xml only contains the "main" target as the release policy only seems to require instructions on how to compile the source, not necessarily create a release.  The release-pixelbender target will remain in the main build.xml

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/18/13 3:08 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>Sorry Alex, I missed you proposition in the last email (this interleaved
>multithreaded discussions are a real pain...)
> 
>> Right now, I'm thinking of:
>> 1) adding a pixelbender.xml file with a main target that does the
>> compile, a clean target that deletes the PBJ and a copy target that
>> copies the PBJs into place in the sdk tree.
>> 2) add more to the release notes that point you to this xml file
>> 3) Separate NOTICE
>> 4) tagging flex-sdk repo
>> 5) Add git location to README (actually describe how this is a subset
>> of
>> flex-sdk)
>> 
>> You'll still use release-pixelbender from the main build.xml to create
>> the package.
>
>
>I don't understand the steps.
>You say that the new "pixel-bender.xml" does the compile and copies the
>PBJ into the SDK trees.
>What's the difference with  the release-pixelbender that will create the
>package.
>
>Does it mean there are two ways of compiling the PBK? One to make the PB
>package, and another one directly inside the SDK, like it works currently
>?
Our build scripts for flex-sdk, flex-falcon, and flex-asjs have a "main"
target that compiles the sources, and a separate "release" target that
creates the artifacts for the release by compressing the source files.

I'm proposing that the pixelbender.xml only contains the "main" target as
the release policy only seems to require instructions on how to compile
the source, not necessarily create a release.  The release-pixelbender
target will remain in the main build.xml

-Alex


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
Sorry Alex, I missed you proposition in the last email (this interleaved multithreaded discussions are a real pain...)
 
> Right now, I'm thinking of:
> 1) adding a pixelbender.xml file with a main target that does the 
> compile, a clean target that deletes the PBJ and a copy target that 
> copies the PBJs into place in the sdk tree.
> 2) add more to the release notes that point you to this xml file
> 3) Separate NOTICE
> 4) tagging flex-sdk repo
> 5) Add git location to README (actually describe how this is a subset 
> of
> flex-sdk)
> 
> You'll still use release-pixelbender from the main build.xml to create 
> the package.


I don't understand the steps.
You say that the new "pixel-bender.xml" does the compile and copies the PBJ into the SDK trees.
What's the difference with  the release-pixelbender that will create the package.

Does it mean there are two ways of compiling the PBK? One to make the PB package, and another one directly inside the SDK, like it works currently ?

Maurice 

-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com] 
Envoyé : mercredi 18 décembre 2013 23:43
À : dev@flex.apache.org
Objet : RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Justin is right,  anyway I didn't have the intention to veto the release ;-)

First of all, thanks Alex for the consideration you give to my position, given that I am a newcomer to the team.

If you think that #1 (leave the files in place) is good solution, then go for it.

I just would look to precise how I understand it would work, and tell me if you agree:

File organization:
- PBK files stay where they are, in the current flex-sdk git repo
- There is a specific target eg. "build-pixel-bender-release" in the build.xml that builds the PBJ release:
	- compiles the PBK => PBJ
	- makes a zip file of the PBJ and maybe other file (LICENCE, README, etc...)
Note: This special target does not need to be called when building flex-sdk)

Process to build the PB release (including manual tasks):
- the "PB release builder" checks out the whole flex-sdk repo on his PC
- calls the target "build-pixel-bender-release" 
- copies/commits the resulting zip to dist/...
- calls for voting of the release.
Note: this is open-source, so anyone who would want re-build the PB release would also call this target,

Manual or Jenkins FLEX-SDK build:
- sdk build.xml includes a new task/target to download/unzip the PB release (including the PBJ) from dist and copy them to the right place.

Is that OK? Did I miss something?

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 décembre 2013 22:37 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/18/13 9:48 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>
>>Well, I am making it a separate package.  The question is whether you 
>>think we should also move this code out of the flex-sdk repo.
>What does  "separate package inside the flex-sdk" mean?
>is that a distinct and autonomous directory inside the flex-sdk repo, 
>much like "mustella" or "modules" ?
>If it's that, then yes, that should be fine, as far as there is no 
>direct dependency on the flex sdk build.
Currently the files are where they have always been.  All I did was modify some build scripts.  Looks like there are at least 3 options:

1) leave the files in place
2) move the files to a new folder in flex-sdk repo
3) move the files to flex-utilities

Doing #1 appears to be the least work, but if you are going to veto the release then I need to find some other configuration that will make you happy.

>
>>Another thing to consider:  What if the PB compiler stops working on 
>>Windows or Mac someday due to an OS incompatibility?  When we don't 
>>own the tools and the tools are not under active development, we run a risk.
>>Who knows when Adobe would respond.  I think PB compiler was last 
>>shipped in Creative Suite 5.5.
>Yes, that's a possibility.
>Maybe another way of looking at it would be to consider not the support 
>for pixel-bender compiler, but rather the support of *PB inside the 
>FlashPlayer*.
>So all the time Adobe supports PB shaders, we will have our 
>"voted/validated" release of pre-compiled PBJ, that will not evolve, 
>and that we can continue shipping and its guaranteed to work.
>Simply consider them as "frozen legacy Adobe stuff", which it is 
>already de-facto.
Remember, we are an open-SOURCE project so everything we do needs compilation or interpretation.  An official Apache release contains source code and instructions to build it and that sort of implies that the tools work.

-Alex


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
Justin is right,  anyway I didn't have the intention to veto the release ;-)

First of all, thanks Alex for the consideration you give to my position, given that I am a newcomer to the team.

If you think that #1 (leave the files in place) is good solution, then go for it.

I just would look to precise how I understand it would work, and tell me if you agree:

File organization:
- PBK files stay where they are, in the current flex-sdk git repo
- There is a specific target eg. "build-pixel-bender-release" in the build.xml that builds the PBJ release:
	- compiles the PBK => PBJ
	- makes a zip file of the PBJ and maybe other file (LICENCE, README, etc...)
Note: This special target does not need to be called when building flex-sdk)

Process to build the PB release (including manual tasks):
- the "PB release builder" checks out the whole flex-sdk repo on his PC
- calls the target "build-pixel-bender-release" 
- copies/commits the resulting zip to dist/...
- calls for voting of the release.
Note: this is open-source, so anyone who would want re-build the PB release would also call this target,

Manual or Jenkins FLEX-SDK build:
- sdk build.xml includes a new task/target to download/unzip the PB release (including the PBJ) from dist and copy them to the right place.

Is that OK? Did I miss something?

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : mercredi 18 décembre 2013 22:37
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/18/13 9:48 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>
>>Well, I am making it a separate package.  The question is whether you 
>>think we should also move this code out of the flex-sdk repo.
>What does  "separate package inside the flex-sdk" mean?
>is that a distinct and autonomous directory inside the flex-sdk repo, 
>much like "mustella" or "modules" ?
>If it's that, then yes, that should be fine, as far as there is no 
>direct dependency on the flex sdk build.
Currently the files are where they have always been.  All I did was modify some build scripts.  Looks like there are at least 3 options:

1) leave the files in place
2) move the files to a new folder in flex-sdk repo
3) move the files to flex-utilities

Doing #1 appears to be the least work, but if you are going to veto the release then I need to find some other configuration that will make you happy.

>
>>Another thing to consider:  What if the PB compiler stops working on 
>>Windows or Mac someday due to an OS incompatibility?  When we don't 
>>own the tools and the tools are not under active development, we run a risk.
>>Who knows when Adobe would respond.  I think PB compiler was last 
>>shipped in Creative Suite 5.5.
>Yes, that's a possibility.
>Maybe another way of looking at it would be to consider not the support 
>for pixel-bender compiler, but rather the support of *PB inside the 
>FlashPlayer*.
>So all the time Adobe supports PB shaders, we will have our 
>"voted/validated" release of pre-compiled PBJ, that will not evolve, 
>and that we can continue shipping and its guaranteed to work.
>Simply consider them as "frozen legacy Adobe stuff", which it is 
>already de-facto.
Remember, we are an open-SOURCE project so everything we do needs compilation or interpretation.  An official Apache release contains source code and instructions to build it and that sort of implies that the tools work.

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Right now, I'm thinking of:
> 1) adding a pixelbender.xml file with a main target that does the compile,
> a clean target that deletes the PBJ and a copy target that copies the PBJs
> into place in the sdk tree.
> 2) add more to the release notes that point you to this xml file
> 3) Separate NOTICE
> 4) tagging flex-sdk repo
> 5) Add git location to README (actually describe how this is a subset of
> flex-sdk)
> 
> You'll still use release-pixelbender from the main build.xml to create the
> package.
> 
> Thoughts?

Seams reasonable to me.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/18/13 2:12 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Doing #1 appears to be the least work, but if you are going to veto the
>> release then I need to find some other configuration that will make you
>> happy.
>
>Releases can't be vetoed. They require 3+1's and more +1 than -1's. But
>the PMC does have a responsibility to the board that the release is
>correct. 
Yes you are right at releases can't be vetoed, but I'm only anticipating
votes from you, Maurice and Om, so a couple of -1's is effectively a veto.



>Perhaps consider if this was an incubating release do you think it be
>passed by the IPMC?
Not RC2 as it is, but I'm trying to collect your thoughts on what we need
to do in RC3.  No sense in me taking a guess only to have you guys
immediately reject it.

Right now, I'm thinking of:
1) adding a pixelbender.xml file with a main target that does the compile,
a clean target that deletes the PBJ and a copy target that copies the PBJs
into place in the sdk tree.
2) add more to the release notes that point you to this xml file
3) Separate NOTICE
4) tagging flex-sdk repo
5) Add git location to README (actually describe how this is a subset of
flex-sdk)

You'll still use release-pixelbender from the main build.xml to create the
package.

Thoughts?

-Alex


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Doing #1 appears to be the least work, but if you are going to veto the
> release then I need to find some other configuration that will make you
> happy.

Releases can't be vetoed. They require 3+1's and more +1 than -1's. But the PMC does have a responsibility to the board that the release is correct. Perhaps consider if this was an incubating release do you think it be passed by the IPMC?

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/18/13 9:48 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>
>>Well, I am making it a separate package.  The question is whether you
>>think we should also move this code out of the flex-sdk repo.
>What does  "separate package inside the flex-sdk" mean?
>is that a distinct and autonomous directory inside the flex-sdk repo,
>much like "mustella" or "modules" ?
>If it's that, then yes, that should be fine, as far as there is no direct
>dependency on the flex sdk build.
Currently the files are where they have always been.  All I did was modify
some build scripts.  Looks like there are at least 3 options:

1) leave the files in place
2) move the files to a new folder in flex-sdk repo
3) move the files to flex-utilities

Doing #1 appears to be the least work, but if you are going to veto the
release then I need to find some other configuration that will make you
happy.

>
>>Another thing to consider:  What if the PB compiler stops working on
>>Windows or Mac someday due to an OS incompatibility?  When we don't own
>>the tools and the tools are not under active development, we run a risk.
>>Who knows when Adobe would respond.  I think PB compiler was last
>>shipped in Creative Suite 5.5.
>Yes, that's a possibility.
>Maybe another way of looking at it would be to consider not the support
>for pixel-bender compiler, but rather the support of *PB inside the
>FlashPlayer*.
>So all the time Adobe supports PB shaders, we will have our
>"voted/validated" release of pre-compiled PBJ, that will not evolve, and
>that we can continue shipping and its guaranteed to work.
>Simply consider them as "frozen legacy Adobe stuff", which it is already
>de-facto.
Remember, we are an open-SOURCE project so everything we do needs
compilation or interpretation.  An official Apache release contains source
code and instructions to build it and that sort of implies that the tools
work.

-Alex


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
>I had a meeting with the engineer who wrote most of the PB compiler.  He says that the PBK to PBJ pipeline shouldn't have dependencies on the gnu, but other PBK to XXX pipelines do, so it should be possible to modify the compiler and get rid of the window dependency.
I believe so,  pbutil is probably doing other things that require a GPU.

>Well, I am making it a separate package.  The question is whether you think we should also move this code out of the flex-sdk repo.
What does  "separate package inside the flex-sdk" mean?
is that a distinct and autonomous directory inside the flex-sdk repo, much like "mustella" or "modules" ?
If it's that, then yes, that should be fine, as far as there is no direct dependency on the flex sdk build.

>Another thing to consider:  What if the PB compiler stops working on Windows or Mac someday due to an OS incompatibility?  When we don't own the tools and the tools are not under active development, we run a risk.
>Who knows when Adobe would respond.  I think PB compiler was last shipped in Creative Suite 5.5.
Yes, that's a possibility.
Maybe another way of looking at it would be to consider not the support for pixel-bender compiler, but rather the support of *PB inside the FlashPlayer*.
So all the time Adobe supports PB shaders, we will have our "voted/validated" release of pre-compiled PBJ, that will not evolve, and that we can continue shipping and its guaranteed to work.
Simply consider them as "frozen legacy Adobe stuff", which it is already de-facto.

Now, if something bad happens ( Adobe discontinues or is about to discontinue PB shaders in the player, and/or does not fix the PB compiler), we will have time to move to something else (eg. Alchemy), even if it breaks the compatibility,
Because we will be forced to, and nobody will complain on us about that move.

>We could also simply move away from PBK as folks eventually move away from FP 10.x.
>I've been told that Alchemy shaders will outperform PB shaders in the more recent players.
>Also, I'm not sure how much work it really is.  The compiler code base is large, but the portion we need is not so large, and we might just try to work from a grammar spec and byte code spec and get Falcon to do it.

I don't have enough knowledge on it to give an relevant opinion.
You know better what to do.
Just consider that we are not dozens working on Apache Flex, and we need to prioritize things...

>We need to think through whether we want to support PB "forever".
Same as above. I would say: we don't stop until Adobe stops.

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : mercredi 18 décembre 2013 17:59
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/18/13 6:59 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>"Another possibility is that we leave the PBK's where they are and 
>>simply add new build targets to flex-sdk build script.  That might be 
>>simpler and gives us the option of reverting back to a single package 
>>if we find that we can someday."
>
>> Yeah.  So what are your thoughts now?
>
>- given that the PBK didn't change for years, and will probably never 
>change,
>- given the "Jenkins running as a service" requirement, and that I 
>don't see how it could be solved, apart from rewriting the compiler so 
>that I does not need access to the gpu.
I had a meeting with the engineer who wrote most of the PB compiler.  He says that the PBK to PBJ pipeline shouldn't have dependencies on the gnu, but other PBK to XXX pipelines do, so it should be possible to modify the compiler and get rid of the window dependency.

>
>I would think that we will never need/have to revert back to the single 
>package.
>
>My impression is that we should consider this PBK/PBJ as a sort of "
>frozen legacy stuff", and handle them in a completely separate package, 
>if that makes the build process simpler and clearer.
Well, I am making it a separate package.  The question is whether you think we should also move this code out of the flex-sdk repo.
>
>This is really just an impression, and some "common sense".
>
>> I've been trying to get a look at the pixel bender compiler source to 
>>determine if it is worth donating to Apache Flex.
>> If we could get enough stuff to have control of the compiler would we 
>>write a Linux version and then go back to a single package?
>
>That is a possibility, but it's a lot of work.
>So given the reasons above, is it worth the effort?
Another thing to consider:  What if the PB compiler stops working on Windows or Mac someday due to an OS incompatibility?  When we don't own the tools and the tools are not under active development, we run a risk.
Who knows when Adobe would respond.  I think PB compiler was last shipped in Creative Suite 5.5.

We could also simply move away from PBK as folks eventually move away from FP 10.x.
I've been told that Alchemy shaders will outperform PB shaders in the more recent players.

Also, I'm not sure how much work it really is.  The compiler code base is large, but the portion we need is not so large, and we might just try to work from a grammar spec and byte code spec and get Falcon to do it.

We need to think through whether we want to support PB "forever".

>
>Regards,
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 décembre 
>2013 15:37 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss 
>Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>
>
>On 12/17/13 11:45 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>Well, re-read the end of that thread and let me know where you stand.
>>
>>Alex wrote:
>>"Another possibility is that we leave the PBK's where they are and 
>>simply add new build targets to flex-sdk build script.  That might be 
>>simpler and gives us the option of reverting back to a single package 
>>if we find that we can someday."
>>
>>is this the point you are talking about ?
>Yeah.  So what are your thoughts now?  I've been trying to get a look 
>at the pixel bender compiler source to determine if it is worth 
>donating to Apache Flex.  If we could get enough stuff to have control 
>of the compiler would we write a Linux version and then go back to a 
>single package?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 
>>décembre
>>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss 
>>Release Apache Flex PixelBender Package 1.0
>>(RC2)
>>
>>
>>
>>On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>> The goal was to not move the PBK files out to a different repo and 
>>>> instead, package a subset of the flex-sdk repo.
>>>
>>>Why can't it be on a different repo ?
>>It can.
>>>From our early discussion on the subject (see email thread 
>>>"PixelBender and Builds.a.o"),  I understood that PBK sources were 
>>>moved to a sub project in flex-utilities.
>>>Which means PBK sources and any reference to pixelbender should be 
>>>completely removed from flex sdk.
>>>Morever, the pixel-bender project in flex-utilities was supposed to 
>>>have its own build.xml.
>>>The result of the new pixel-bender build would be manually committed 
>>>to dist svn repo (and voted for).
>>At the end of that discussion (around December 12), you talked me out 
>>of putting it in a different repo.
>>>
>>>IMO, it would be much simpler to do it that way than "logically 
>>>partitioning" the flex-sdk sources and build files.
>>Well, re-read the end of that thread and let me know where you stand.
>>
>>>
>>>WDYT ?
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : 
>>>mercredi
>>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS] 
>>>Discuss Release Apache Flex PixelBender Package 1.0
>>>(RC2)
>>>
>>>Hi,
>>>
>>>> OK.  Good point about the overlay of the notice files.  I'll add an 
>>>> ant target to copy just the pbk/pbj.
>>>That would be required for the CI anyway wouldn't it?
>>>
>>>> The goal was to not move the PBK files out to a different repo and 
>>>> instead, package a subset of the flex-sdk repo.
>>>Can we actually do that ie does it follow Apache release guidelines?
>>>I'm not sure. Does that mean we also need to vote on a release a 
>>>version of pixel bender when making a new SDK release?
>>>
>>>>  Do you think everything on this list is required?
>>>Not everything, It is expected that someone can take the source 
>>>release and compile it and verify it to what's in version control.
>>>
>>>> 1) can we tell folks in the RELEASE_NOTES not to run 
>>>> release-pixelbender target and say that it is for extracting this 
>>>> package from a full flex-sdk repo?
>>>We can say what we want in RELEASE_NOTE/README. But it seem odd to me 
>>>that you need the full Flex SDK is required just to make a release of 
>>>pixel bender. What do other people think?
>>>
>>>> 2) can we say that the LICENSE file contains extra licenses that 
>>>> may only apply to the full repo?
>>>I would assume that LICENSE/NOTICE file needs to refer to the actual 
>>>release (and any upstream projects) they are in not any downstream 
>>>projects. The Apache licence make reference to the NOTICE file so we 
>>>would need to legally comply with that.
>>>
>>>> 3) can we say that the build.xml and properties files reference the 
>>>> full flex-sdk build?
>>>Does this mean we need to make a new PB release every time they change?
>>>
>>>> 4) can we say that the clean target doesn't work?
>>>I think it would be expected that it should work.
>>>
>>>Thanks,
>>>Justin
>>
>


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
>I think it is too much effort for a few shaders.  IMO, we should compile the pbk files and keep the binaries around till there is a need to change them.  Pretty much what you have been doing for the past few days :-)

That pretty much my position, in more elegant and concise terms ;-)


-----Message d'origine-----
De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash Muppirala
Envoyé : mercredi 18 décembre 2013 18:35
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

On Dec 18, 2013 9:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 12/18/13 6:59 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
> >>"Another possibility is that we leave the PBK's where they are and 
> >>simply add new build targets to flex-sdk build script.  That might 
> >>be simpler and gives us the option of reverting back to a single 
> >>package if we find that we can someday."
> >
> >> Yeah.  So what are your thoughts now?
> >
> >- given that the PBK didn't change for years, and will probably never 
> >change,
> >- given the "Jenkins running as a service" requirement, and that I 
> >don't see how it could be solved, apart from rewriting the compiler 
> >so that I does not need access to the gpu.
> I had a meeting with the engineer who wrote most of the PB compiler.  
> He says that the PBK to PBJ pipeline shouldn't have dependencies on 
> the gnu, but other PBK to XXX pipelines do, so it should be possible 
> to modify the compiler and get rid of the window dependency.
>
> >
> >I would think that we will never need/have to revert back to the 
> >single package.
> >
> >My impression is that we should consider this PBK/PBJ as a sort of "
> >frozen legacy stuff", and handle them in a completely separate 
> >package, if that makes the build process simpler and clearer.
> Well, I am making it a separate package.  The question is whether you 
> think we should also move this code out of the flex-sdk repo.
> >
> >This is really just an impression, and some "common sense".
> >
> >> I've been trying to get a look at the pixel bender compiler source 
> >>to determine if it is worth donating to Apache Flex.
> >> If we could get enough stuff to have control of the compiler would 
> >>we write a Linux version and then go back to a single package?
> >
> >That is a possibility, but it's a lot of work.
> >So given the reasons above, is it worth the effort?
> Another thing to consider:  What if the PB compiler stops working on 
> Windows or Mac someday due to an OS incompatibility?  When we don't 
> own the tools and the tools are not under active development, we run a risk.
> Who knows when Adobe would respond.  I think PB compiler was last 
> shipped in Creative Suite 5.5.
>
> We could also simply move away from PBK as folks eventually move away 
> from FP 10.x.
> I've been told that Alchemy shaders will outperform PB shaders in the 
> more recent players.

At least using the Installer, we can have separate install paths to use or not use PB shaders based on the FP/AIR versions the user selects.

>
> Also, I'm not sure how much work it really is.  The compiler code base 
> is large, but the portion we need is not so large, and we might just 
> try to work from a grammar spec and byte code spec and get Falcon to do it.
>
> We need to think through whether we want to support PB "forever".

I think it is too much effort for a few shaders.  IMO, we should compile the pbk files and keep the binaries around till there is a need to change them.  Pretty much what you have been doing for the past few days :-)

Thanks,
Om

>
> >
> >Regards,
> >
> >Maurice
> >
> >-----Message d'origine-----
> >De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 
> >décembre 2013 15:37 À : dev@flex.apache.org Objet : Re: [DISCUSS] 
> >Discuss Release Apache Flex PixelBender Package 1.0
> >(RC2)
> >
> >
> >
> >On 12/17/13 11:45 PM, "Maurice Amsellem" 
> ><ma...@systar.com>
> >wrote:
> >
> >>>Well, re-read the end of that thread and let me know where you stand.
> >>
> >>Alex wrote:
> >>"Another possibility is that we leave the PBK's where they are and 
> >>simply add new build targets to flex-sdk build script.  That might 
> >>be simpler and gives us the option of reverting back to a single 
> >>package if we find that we can someday."
> >>
> >>is this the point you are talking about ?
> >Yeah.  So what are your thoughts now?  I've been trying to get a look 
> >at the pixel bender compiler source to determine if it is worth 
> >donating to Apache Flex.  If we could get enough stuff to have 
> >control of the compiler would we write a Linux version and then go 
> >back to a single package?
> >>
> >>Maurice
> >>
> >>-----Message d'origine-----
> >>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 
> >>décembre
> >>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss 
> >>Release Apache Flex PixelBender Package 1.0
> >>(RC2)
> >>
> >>
> >>
> >>On 12/17/13 3:35 PM, "Maurice Amsellem" 
> >><ma...@systar.com>
> >>wrote:
> >>
> >>>> The goal was to not move the PBK files out to a different repo 
> >>>> and instead, package a subset of the flex-sdk repo.
> >>>
> >>>Why can't it be on a different repo ?
> >>It can.
> >>>From our early discussion on the subject (see email thread 
> >>>"PixelBender and Builds.a.o"),  I understood that PBK sources were 
> >>>moved to a sub project in flex-utilities.
> >>>Which means PBK sources and any reference to pixelbender should be 
> >>>completely removed from flex sdk.
> >>>Morever, the pixel-bender project in flex-utilities was supposed to 
> >>>have its own build.xml.
> >>>The result of the new pixel-bender build would be manually 
> >>>committed to dist svn repo (and voted for).
> >>At the end of that discussion (around December 12), you talked me 
> >>out of putting it in a different repo.
> >>>
> >>>IMO, it would be much simpler to do it that way than "logically 
> >>>partitioning" the flex-sdk sources and build files.
> >>Well, re-read the end of that thread and let me know where you stand.
> >>
> >>>
> >>>WDYT ?
> >>>
> >>>Maurice
> >>>
> >>>-----Message d'origine-----
> >>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : 
> >>>mercredi
> >>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: 
> >>>[DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0
> >>>(RC2)
> >>>
> >>>Hi,
> >>>
> >>>> OK.  Good point about the overlay of the notice files.  I'll add 
> >>>> an ant target to copy just the pbk/pbj.
> >>>That would be required for the CI anyway wouldn't it?
> >>>
> >>>> The goal was to not move the PBK files out to a different repo 
> >>>> and instead, package a subset of the flex-sdk repo.
> >>>Can we actually do that ie does it follow Apache release guidelines?
> >>>I'm not sure. Does that mean we also need to vote on a release a 
> >>>version of pixel bender when making a new SDK release?
> >>>
> >>>>  Do you think everything on this list is required?
> >>>Not everything, It is expected that someone can take the source 
> >>>release and compile it and verify it to what's in version control.
> >>>
> >>>> 1) can we tell folks in the RELEASE_NOTES not to run 
> >>>> release-pixelbender target and say that it is for extracting this 
> >>>> package from a full flex-sdk repo?
> >>>We can say what we want in RELEASE_NOTE/README. But it seem odd to 
> >>>me that you need the full Flex SDK is required just to make a 
> >>>release of pixel bender. What do other people think?
> >>>
> >>>> 2) can we say that the LICENSE file contains extra licenses that 
> >>>> may only apply to the full repo?
> >>>I would assume that LICENSE/NOTICE file needs to refer to the 
> >>>actual release (and any upstream projects) they are in not any 
> >>>downstream projects. The Apache licence make reference to the 
> >>>NOTICE file so we would need to legally comply with that.
> >>>
> >>>> 3) can we say that the build.xml and properties files reference 
> >>>> the full flex-sdk build?
> >>>Does this mean we need to make a new PB release every time they change?
> >>>
> >>>> 4) can we say that the clean target doesn't work?
> >>>I think it would be expected that it should work.
> >>>
> >>>Thanks,
> >>>Justin
> >>
> >
>

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Dec 18, 2013 9:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 12/18/13 6:59 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
> >>"Another possibility is that we leave the PBK's where they are and
> >>simply add new build targets to flex-sdk build script.  That might be
> >>simpler and gives us the option of reverting back to a single package
> >>if we find that we can someday."
> >
> >> Yeah.  So what are your thoughts now?
> >
> >- given that the PBK didn't change for years, and will probably never
> >change,
> >- given the "Jenkins running as a service" requirement, and that I don't
> >see how it could be solved, apart from rewriting the compiler so that I
> >does not need access to the gpu.
> I had a meeting with the engineer who wrote most of the PB compiler.  He
> says that the PBK to PBJ pipeline shouldn't have dependencies on the gnu,
> but other PBK to XXX pipelines do, so it should be possible to modify the
> compiler and get rid of the window dependency.
>
> >
> >I would think that we will never need/have to revert back to the single
> >package.
> >
> >My impression is that we should consider this PBK/PBJ as a sort of "
> >frozen legacy stuff", and handle them in a completely separate package,
> >if that makes the build process simpler and clearer.
> Well, I am making it a separate package.  The question is whether you
> think we should also move this code out of the flex-sdk repo.
> >
> >This is really just an impression, and some "common sense".
> >
> >> I've been trying to get a look at the pixel bender compiler source to
> >>determine if it is worth donating to Apache Flex.
> >> If we could get enough stuff to have control of the compiler would we
> >>write a Linux version and then go back to a single package?
> >
> >That is a possibility, but it's a lot of work.
> >So given the reasons above, is it worth the effort?
> Another thing to consider:  What if the PB compiler stops working on
> Windows or Mac someday due to an OS incompatibility?  When we don't own
> the tools and the tools are not under active development, we run a risk.
> Who knows when Adobe would respond.  I think PB compiler was last shipped
> in Creative Suite 5.5.
>
> We could also simply move away from PBK as folks eventually move away from
> FP 10.x.
> I've been told that Alchemy shaders will outperform PB shaders in the more
> recent players.

At least using the Installer, we can have separate install paths to use or
not use PB shaders based on the FP/AIR versions the user selects.

>
> Also, I'm not sure how much work it really is.  The compiler code base is
> large, but the portion we need is not so large, and we might just try to
> work from a grammar spec and byte code spec and get Falcon to do it.
>
> We need to think through whether we want to support PB "forever".

I think it is too much effort for a few shaders.  IMO, we should compile
the pbk files and keep the binaries around till there is a need to change
them.  Pretty much what you have been doing for the past few days :-)

Thanks,
Om

>
> >
> >Regards,
> >
> >Maurice
> >
> >-----Message d'origine-----
> >De : Alex Harui [mailto:aharui@adobe.com]
> >Envoyé : mercredi 18 décembre 2013 15:37
> >À : dev@flex.apache.org
> >Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0
> >(RC2)
> >
> >
> >
> >On 12/17/13 11:45 PM, "Maurice Amsellem" <ma...@systar.com>
> >wrote:
> >
> >>>Well, re-read the end of that thread and let me know where you stand.
> >>
> >>Alex wrote:
> >>"Another possibility is that we leave the PBK's where they are and
> >>simply add new build targets to flex-sdk build script.  That might be
> >>simpler and gives us the option of reverting back to a single package
> >>if we find that we can someday."
> >>
> >>is this the point you are talking about ?
> >Yeah.  So what are your thoughts now?  I've been trying to get a look at
> >the pixel bender compiler source to determine if it is worth donating to
> >Apache Flex.  If we could get enough stuff to have control of the
> >compiler would we write a Linux version and then go back to a single
> >package?
> >>
> >>Maurice
> >>
> >>-----Message d'origine-----
> >>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 décembre
> >>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss
> >>Release Apache Flex PixelBender Package 1.0
> >>(RC2)
> >>
> >>
> >>
> >>On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
> >>wrote:
> >>
> >>>> The goal was to not move the PBK files out to a different repo and
> >>>> instead, package a subset of the flex-sdk repo.
> >>>
> >>>Why can't it be on a different repo ?
> >>It can.
> >>>From our early discussion on the subject (see email thread
> >>>"PixelBender and Builds.a.o"),  I understood that PBK sources were
> >>>moved to a sub project in flex-utilities.
> >>>Which means PBK sources and any reference to pixelbender should be
> >>>completely removed from flex sdk.
> >>>Morever, the pixel-bender project in flex-utilities was supposed to
> >>>have its own build.xml.
> >>>The result of the new pixel-bender build would be manually committed
> >>>to dist svn repo (and voted for).
> >>At the end of that discussion (around December 12), you talked me out
> >>of putting it in a different repo.
> >>>
> >>>IMO, it would be much simpler to do it that way than "logically
> >>>partitioning" the flex-sdk sources and build files.
> >>Well, re-read the end of that thread and let me know where you stand.
> >>
> >>>
> >>>WDYT ?
> >>>
> >>>Maurice
> >>>
> >>>-----Message d'origine-----
> >>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
> >>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS]
> >>>Discuss Release Apache Flex PixelBender Package 1.0
> >>>(RC2)
> >>>
> >>>Hi,
> >>>
> >>>> OK.  Good point about the overlay of the notice files.  I'll add an
> >>>> ant target to copy just the pbk/pbj.
> >>>That would be required for the CI anyway wouldn't it?
> >>>
> >>>> The goal was to not move the PBK files out to a different repo and
> >>>> instead, package a subset of the flex-sdk repo.
> >>>Can we actually do that ie does it follow Apache release guidelines?
> >>>I'm not sure. Does that mean we also need to vote on a release a
> >>>version of pixel bender when making a new SDK release?
> >>>
> >>>>  Do you think everything on this list is required?
> >>>Not everything, It is expected that someone can take the source
> >>>release and compile it and verify it to what's in version control.
> >>>
> >>>> 1) can we tell folks in the RELEASE_NOTES not to run
> >>>> release-pixelbender target and say that it is for extracting this
> >>>> package from a full flex-sdk repo?
> >>>We can say what we want in RELEASE_NOTE/README. But it seem odd to me
> >>>that you need the full Flex SDK is required just to make a release of
> >>>pixel bender. What do other people think?
> >>>
> >>>> 2) can we say that the LICENSE file contains extra licenses that may
> >>>> only apply to the full repo?
> >>>I would assume that LICENSE/NOTICE file needs to refer to the actual
> >>>release (and any upstream projects) they are in not any downstream
> >>>projects. The Apache licence make reference to the NOTICE file so we
> >>>would need to legally comply with that.
> >>>
> >>>> 3) can we say that the build.xml and properties files reference the
> >>>> full flex-sdk build?
> >>>Does this mean we need to make a new PB release every time they change?
> >>>
> >>>> 4) can we say that the clean target doesn't work?
> >>>I think it would be expected that it should work.
> >>>
> >>>Thanks,
> >>>Justin
> >>
> >
>

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/18/13 6:59 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>"Another possibility is that we leave the PBK's where they are and
>>simply add new build targets to flex-sdk build script.  That might be
>>simpler and gives us the option of reverting back to a single package
>>if we find that we can someday."
>
>> Yeah.  So what are your thoughts now?
>
>- given that the PBK didn't change for years, and will probably never
>change, 
>- given the "Jenkins running as a service" requirement, and that I don't
>see how it could be solved, apart from rewriting the compiler so that I
>does not need access to the gpu.
I had a meeting with the engineer who wrote most of the PB compiler.  He
says that the PBK to PBJ pipeline shouldn't have dependencies on the gnu,
but other PBK to XXX pipelines do, so it should be possible to modify the
compiler and get rid of the window dependency.

>
>I would think that we will never need/have to revert back to the single
>package.
>
>My impression is that we should consider this PBK/PBJ as a sort of "
>frozen legacy stuff", and handle them in a completely separate package,
>if that makes the build process simpler and clearer.
Well, I am making it a separate package.  The question is whether you
think we should also move this code out of the flex-sdk repo.
>
>This is really just an impression, and some "common sense".
>
>> I've been trying to get a look at the pixel bender compiler source to
>>determine if it is worth donating to Apache Flex.
>> If we could get enough stuff to have control of the compiler would we
>>write a Linux version and then go back to a single package?
>
>That is a possibility, but it's a lot of work.
>So given the reasons above, is it worth the effort?
Another thing to consider:  What if the PB compiler stops working on
Windows or Mac someday due to an OS incompatibility?  When we don't own
the tools and the tools are not under active development, we run a risk.
Who knows when Adobe would respond.  I think PB compiler was last shipped
in Creative Suite 5.5.

We could also simply move away from PBK as folks eventually move away from
FP 10.x.
I've been told that Alchemy shaders will outperform PB shaders in the more
recent players.

Also, I'm not sure how much work it really is.  The compiler code base is
large, but the portion we need is not so large, and we might just try to
work from a grammar spec and byte code spec and get Falcon to do it.

We need to think through whether we want to support PB "forever".

>
>Regards,
>
>Maurice 
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : mercredi 18 décembre 2013 15:37
>À : dev@flex.apache.org
>Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>
>
>On 12/17/13 11:45 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>Well, re-read the end of that thread and let me know where you stand.
>>
>>Alex wrote:
>>"Another possibility is that we leave the PBK's where they are and
>>simply add new build targets to flex-sdk build script.  That might be
>>simpler and gives us the option of reverting back to a single package
>>if we find that we can someday."
>>
>>is this the point you are talking about ?
>Yeah.  So what are your thoughts now?  I've been trying to get a look at
>the pixel bender compiler source to determine if it is worth donating to
>Apache Flex.  If we could get enough stuff to have control of the
>compiler would we write a Linux version and then go back to a single
>package?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 décembre
>>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss
>>Release Apache Flex PixelBender Package 1.0
>>(RC2)
>>
>>
>>
>>On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>> The goal was to not move the PBK files out to a different repo and
>>>> instead, package a subset of the flex-sdk repo.
>>>
>>>Why can't it be on a different repo ?
>>It can.
>>>From our early discussion on the subject (see email thread
>>>"PixelBender and Builds.a.o"),  I understood that PBK sources were
>>>moved to a sub project in flex-utilities.
>>>Which means PBK sources and any reference to pixelbender should be
>>>completely removed from flex sdk.
>>>Morever, the pixel-bender project in flex-utilities was supposed to
>>>have its own build.xml.
>>>The result of the new pixel-bender build would be manually committed
>>>to dist svn repo (and voted for).
>>At the end of that discussion (around December 12), you talked me out
>>of putting it in a different repo.
>>>
>>>IMO, it would be much simpler to do it that way than "logically
>>>partitioning" the flex-sdk sources and build files.
>>Well, re-read the end of that thread and let me know where you stand.
>>
>>>
>>>WDYT ?
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS]
>>>Discuss Release Apache Flex PixelBender Package 1.0
>>>(RC2)
>>>
>>>Hi,
>>>
>>>> OK.  Good point about the overlay of the notice files.  I'll add an
>>>> ant target to copy just the pbk/pbj.
>>>That would be required for the CI anyway wouldn't it?
>>>
>>>> The goal was to not move the PBK files out to a different repo and
>>>> instead, package a subset of the flex-sdk repo.
>>>Can we actually do that ie does it follow Apache release guidelines?
>>>I'm not sure. Does that mean we also need to vote on a release a
>>>version of pixel bender when making a new SDK release?
>>>
>>>>  Do you think everything on this list is required?
>>>Not everything, It is expected that someone can take the source
>>>release and compile it and verify it to what's in version control.
>>>
>>>> 1) can we tell folks in the RELEASE_NOTES not to run
>>>> release-pixelbender target and say that it is for extracting this
>>>> package from a full flex-sdk repo?
>>>We can say what we want in RELEASE_NOTE/README. But it seem odd to me
>>>that you need the full Flex SDK is required just to make a release of
>>>pixel bender. What do other people think?
>>>
>>>> 2) can we say that the LICENSE file contains extra licenses that may
>>>> only apply to the full repo?
>>>I would assume that LICENSE/NOTICE file needs to refer to the actual
>>>release (and any upstream projects) they are in not any downstream
>>>projects. The Apache licence make reference to the NOTICE file so we
>>>would need to legally comply with that.
>>>
>>>> 3) can we say that the build.xml and properties files reference the
>>>> full flex-sdk build?
>>>Does this mean we need to make a new PB release every time they change?
>>>
>>>> 4) can we say that the clean target doesn't work?
>>>I think it would be expected that it should work.
>>>
>>>Thanks,
>>>Justin
>>
>


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
>"Another possibility is that we leave the PBK's where they are and  simply add new build targets to flex-sdk build script.  That might be simpler and gives us the option of reverting back to a single package 
>if we find that we can someday."

> Yeah.  So what are your thoughts now?  

- given that the PBK didn't change for years, and will probably never change, 
- given the "Jenkins running as a service" requirement, and that I don't see how it could be solved, apart from rewriting the compiler so that I does not need access to the gpu.

I would think that we will never need/have to revert back to the single package.

My impression is that we should consider this PBK/PBJ as a sort of " frozen legacy stuff", and handle them in a completely separate package, if that makes the build process simpler and clearer.

This is really just an impression, and some "common sense".  

> I've been trying to get a look at the pixel bender compiler source to determine if it is worth donating to Apache Flex.  
> If we could get enough stuff to have control of the compiler would we write a Linux version and then go back to a single package?

That is a possibility, but it's a lot of work.
So given the reasons above, is it worth the effort?  

Regards,

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : mercredi 18 décembre 2013 15:37
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/17/13 11:45 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>Well, re-read the end of that thread and let me know where you stand.
>
>Alex wrote:
>"Another possibility is that we leave the PBK's where they are and 
>simply add new build targets to flex-sdk build script.  That might be 
>simpler and gives us the option of reverting back to a single package 
>if we find that we can someday."
>
>is this the point you are talking about ?
Yeah.  So what are your thoughts now?  I've been trying to get a look at the pixel bender compiler source to determine if it is worth donating to Apache Flex.  If we could get enough stuff to have control of the compiler would we write a Linux version and then go back to a single package?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 18 décembre 
>2013 00:48 À : dev@flex.apache.org Objet : Re: [DISCUSS] Discuss 
>Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>
>
>On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>> The goal was to not move the PBK files out to a different repo and 
>>> instead, package a subset of the flex-sdk repo.
>>
>>Why can't it be on a different repo ?
>It can.
>>From our early discussion on the subject (see email thread 
>>"PixelBender and Builds.a.o"),  I understood that PBK sources were 
>>moved to a sub project in flex-utilities.
>>Which means PBK sources and any reference to pixelbender should be 
>>completely removed from flex sdk.
>>Morever, the pixel-bender project in flex-utilities was supposed to 
>>have its own build.xml.
>>The result of the new pixel-bender build would be manually committed 
>>to dist svn repo (and voted for).
>At the end of that discussion (around December 12), you talked me out 
>of putting it in a different repo.
>>
>>IMO, it would be much simpler to do it that way than "logically 
>>partitioning" the flex-sdk sources and build files.
>Well, re-read the end of that thread and let me know where you stand.
>
>>
>>WDYT ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS] 
>>Discuss Release Apache Flex PixelBender Package 1.0
>>(RC2)
>>
>>Hi,
>>
>>> OK.  Good point about the overlay of the notice files.  I'll add an 
>>> ant target to copy just the pbk/pbj.
>>That would be required for the CI anyway wouldn't it?
>>
>>> The goal was to not move the PBK files out to a different repo and 
>>> instead, package a subset of the flex-sdk repo.
>>Can we actually do that ie does it follow Apache release guidelines?
>>I'm not sure. Does that mean we also need to vote on a release a 
>>version of pixel bender when making a new SDK release?
>>
>>>  Do you think everything on this list is required?
>>Not everything, It is expected that someone can take the source 
>>release and compile it and verify it to what's in version control.
>>
>>> 1) can we tell folks in the RELEASE_NOTES not to run 
>>> release-pixelbender target and say that it is for extracting this 
>>> package from a full flex-sdk repo?
>>We can say what we want in RELEASE_NOTE/README. But it seem odd to me 
>>that you need the full Flex SDK is required just to make a release of 
>>pixel bender. What do other people think?
>>
>>> 2) can we say that the LICENSE file contains extra licenses that may 
>>> only apply to the full repo?
>>I would assume that LICENSE/NOTICE file needs to refer to the actual 
>>release (and any upstream projects) they are in not any downstream 
>>projects. The Apache licence make reference to the NOTICE file so we 
>>would need to legally comply with that.
>>
>>> 3) can we say that the build.xml and properties files reference the 
>>> full flex-sdk build?
>>Does this mean we need to make a new PB release every time they change?
>>
>>> 4) can we say that the clean target doesn't work?
>>I think it would be expected that it should work.
>>
>>Thanks,
>>Justin
>


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 11:45 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>>Well, re-read the end of that thread and let me know where you stand.
>
>Alex wrote:
>"Another possibility is that we leave the PBK's where they are and simply
>add new build targets to flex-sdk build script.  That might be simpler
>and gives us the option of reverting back to a single package if we find
>that we can someday."
>
>is this the point you are talking about ?
Yeah.  So what are your thoughts now?  I've been trying to get a look at
the pixel bender compiler source to determine if it is worth donating to
Apache Flex.  If we could get enough stuff to have control of the compiler
would we write a Linux version and then go back to a single package?
>
>Maurice 
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : mercredi 18 décembre 2013 00:48
>À : dev@flex.apache.org
>Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>
>
>On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>> The goal was to not move the PBK files out to a different repo and
>>> instead, package a subset of the flex-sdk repo.
>>
>>Why can't it be on a different repo ?
>It can.
>>From our early discussion on the subject (see email thread "PixelBender
>>and Builds.a.o"),  I understood that PBK sources were moved to a sub
>>project in flex-utilities.
>>Which means PBK sources and any reference to pixelbender should be
>>completely removed from flex sdk.
>>Morever, the pixel-bender project in flex-utilities was supposed to
>>have its own build.xml.
>>The result of the new pixel-bender build would be manually committed to
>>dist svn repo (and voted for).
>At the end of that discussion (around December 12), you talked me out of
>putting it in a different repo.
>>
>>IMO, it would be much simpler to do it that way than "logically
>>partitioning" the flex-sdk sources and build files.
>Well, re-read the end of that thread and let me know where you stand.
>
>>
>>WDYT ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS]
>>Discuss Release Apache Flex PixelBender Package 1.0
>>(RC2)
>>
>>Hi,
>>
>>> OK.  Good point about the overlay of the notice files.  I'll add an
>>> ant target to copy just the pbk/pbj.
>>That would be required for the CI anyway wouldn't it?
>>
>>> The goal was to not move the PBK files out to a different repo and
>>> instead, package a subset of the flex-sdk repo.
>>Can we actually do that ie does it follow Apache release guidelines?
>>I'm not sure. Does that mean we also need to vote on a release a
>>version of pixel bender when making a new SDK release?
>>
>>>  Do you think everything on this list is required?
>>Not everything, It is expected that someone can take the source release
>>and compile it and verify it to what's in version control.
>>
>>> 1) can we tell folks in the RELEASE_NOTES not to run
>>> release-pixelbender target and say that it is for extracting this
>>> package from a full flex-sdk repo?
>>We can say what we want in RELEASE_NOTE/README. But it seem odd to me
>>that you need the full Flex SDK is required just to make a release of
>>pixel bender. What do other people think?
>>
>>> 2) can we say that the LICENSE file contains extra licenses that may
>>> only apply to the full repo?
>>I would assume that LICENSE/NOTICE file needs to refer to the actual
>>release (and any upstream projects) they are in not any downstream
>>projects. The Apache licence make reference to the NOTICE file so we
>>would need to legally comply with that.
>>
>>> 3) can we say that the build.xml and properties files reference the
>>> full flex-sdk build?
>>Does this mean we need to make a new PB release every time they change?
>>
>>> 4) can we say that the clean target doesn't work?
>>I think it would be expected that it should work.
>>
>>Thanks,
>>Justin
>


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
>Well, re-read the end of that thread and let me know where you stand.

Alex wrote:
"Another possibility is that we leave the PBK's where they are and simply add new build targets to flex-sdk build script.  That might be simpler and gives us the option of reverting back to a single package if we find that we can someday."

is this the point you are talking about ?

Maurice 

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] 
Envoyé : mercredi 18 décembre 2013 00:48
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)



On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>> The goal was to not move the PBK files out to a different repo and 
>> instead, package a subset of the flex-sdk repo.
>
>Why can't it be on a different repo ?
It can.
>From our early discussion on the subject (see email thread "PixelBender 
>and Builds.a.o"),  I understood that PBK sources were moved to a sub 
>project in flex-utilities.
>Which means PBK sources and any reference to pixelbender should be 
>completely removed from flex sdk.
>Morever, the pixel-bender project in flex-utilities was supposed to 
>have its own build.xml.
>The result of the new pixel-bender build would be manually committed to 
>dist svn repo (and voted for).
At the end of that discussion (around December 12), you talked me out of putting it in a different repo.
>
>IMO, it would be much simpler to do it that way than "logically 
>partitioning" the flex-sdk sources and build files.
Well, re-read the end of that thread and let me know where you stand.

>
>WDYT ?
>
>Maurice
>
>-----Message d'origine-----
>De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi 
>18 décembre 2013 00:19 À : dev@flex.apache.org Objet : Re: [DISCUSS] 
>Discuss Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>Hi,
>
>> OK.  Good point about the overlay of the notice files.  I'll add an 
>> ant target to copy just the pbk/pbj.
>That would be required for the CI anyway wouldn't it?
>
>> The goal was to not move the PBK files out to a different repo and 
>> instead, package a subset of the flex-sdk repo.
>Can we actually do that ie does it follow Apache release guidelines? 
>I'm not sure. Does that mean we also need to vote on a release a 
>version of pixel bender when making a new SDK release?
>
>>  Do you think everything on this list is required?
>Not everything, It is expected that someone can take the source release 
>and compile it and verify it to what's in version control.
>
>> 1) can we tell folks in the RELEASE_NOTES not to run 
>> release-pixelbender target and say that it is for extracting this 
>> package from a full flex-sdk repo?
>We can say what we want in RELEASE_NOTE/README. But it seem odd to me 
>that you need the full Flex SDK is required just to make a release of 
>pixel bender. What do other people think?
>
>> 2) can we say that the LICENSE file contains extra licenses that may 
>> only apply to the full repo?
>I would assume that LICENSE/NOTICE file needs to refer to the actual 
>release (and any upstream projects) they are in not any downstream 
>projects. The Apache licence make reference to the NOTICE file so we 
>would need to legally comply with that.
>
>> 3) can we say that the build.xml and properties files reference the 
>> full flex-sdk build?
>Does this mean we need to make a new PB release every time they change?
>
>> 4) can we say that the clean target doesn't work?
>I think it would be expected that it should work.
>
>Thanks,
>Justin


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.

On 12/17/13 3:35 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:

>> The goal was to not move the PBK files out to a different repo and
>> instead, package a subset of the flex-sdk repo.
>
>Why can't it be on a different repo ?
It can.
>From our early discussion on the subject (see email thread "PixelBender
>and Builds.a.o"),  I understood that PBK sources were moved to a sub
>project in flex-utilities.
>Which means PBK sources and any reference to pixelbender should be
>completely removed from flex sdk.
>Morever, the pixel-bender project in flex-utilities was supposed to have
>its own build.xml.
>The result of the new pixel-bender build would be manually committed to
>dist svn repo (and voted for).
At the end of that discussion (around December 12), you talked me out of
putting it in a different repo.
>
>IMO, it would be much simpler to do it that way than "logically
>partitioning" the flex-sdk sources and build files.
Well, re-read the end of that thread and let me know where you stand.

>
>WDYT ?
>
>Maurice 
>
>-----Message d'origine-----
>De : Justin Mclean [mailto:justin@classsoftware.com]
>Envoyé : mercredi 18 décembre 2013 00:19
>À : dev@flex.apache.org
>Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0
>(RC2)
>
>Hi,
>
>> OK.  Good point about the overlay of the notice files.  I'll add an
>> ant target to copy just the pbk/pbj.
>That would be required for the CI anyway wouldn't it?
>
>> The goal was to not move the PBK files out to a different repo and
>> instead, package a subset of the flex-sdk repo.
>Can we actually do that ie does it follow Apache release guidelines? I'm
>not sure. Does that mean we also need to vote on a release a version of
>pixel bender when making a new SDK release?
>
>>  Do you think everything on this list is required?
>Not everything, It is expected that someone can take the source release
>and compile it and verify it to what's in version control.
>
>> 1) can we tell folks in the RELEASE_NOTES not to run
>> release-pixelbender target and say that it is for extracting this
>> package from a full flex-sdk repo?
>We can say what we want in RELEASE_NOTE/README. But it seem odd to me
>that you need the full Flex SDK is required just to make a release of
>pixel bender. What do other people think?
>
>> 2) can we say that the LICENSE file contains extra licenses that may
>> only apply to the full repo?
>I would assume that LICENSE/NOTICE file needs to refer to the actual
>release (and any upstream projects) they are in not any downstream
>projects. The Apache licence make reference to the NOTICE file so we
>would need to legally comply with that.
>
>> 3) can we say that the build.xml and properties files reference the
>> full flex-sdk build?
>Does this mean we need to make a new PB release every time they change?
>
>> 4) can we say that the clean target doesn't work?
>I think it would be expected that it should work.
>
>Thanks,
>Justin


RE: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Maurice Amsellem <ma...@systar.com>.
> The goal was to not move the PBK files out to a different repo and 
> instead, package a subset of the flex-sdk repo.

Why can't it be on a different repo ?  
>From our early discussion on the subject (see email thread "PixelBender and Builds.a.o"),  I understood that PBK sources were moved to a sub project in flex-utilities.
Which means PBK sources and any reference to pixelbender should be completely removed from flex sdk.
Morever, the pixel-bender project in flex-utilities was supposed to have its own build.xml.
The result of the new pixel-bender build would be manually committed to dist svn repo (and voted for).

IMO, it would be much simpler to do it that way than "logically partitioning" the flex-sdk sources and build files.

WDYT ?

Maurice 

-----Message d'origine-----
De : Justin Mclean [mailto:justin@classsoftware.com] 
Envoyé : mercredi 18 décembre 2013 00:19
À : dev@flex.apache.org
Objet : Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Hi,

> OK.  Good point about the overlay of the notice files.  I'll add an 
> ant target to copy just the pbk/pbj.
That would be required for the CI anyway wouldn't it?

> The goal was to not move the PBK files out to a different repo and 
> instead, package a subset of the flex-sdk repo.
Can we actually do that ie does it follow Apache release guidelines? I'm not sure. Does that mean we also need to vote on a release a version of pixel bender when making a new SDK release?

>  Do you think everything on this list is required?
Not everything, It is expected that someone can take the source release and compile it and verify it to what's in version control.

> 1) can we tell folks in the RELEASE_NOTES not to run 
> release-pixelbender target and say that it is for extracting this 
> package from a full flex-sdk repo?
We can say what we want in RELEASE_NOTE/README. But it seem odd to me that you need the full Flex SDK is required just to make a release of pixel bender. What do other people think?

> 2) can we say that the LICENSE file contains extra licenses that may 
> only apply to the full repo?
I would assume that LICENSE/NOTICE file needs to refer to the actual release (and any upstream projects) they are in not any downstream projects. The Apache licence make reference to the NOTICE file so we would need to legally comply with that.

> 3) can we say that the build.xml and properties files reference the 
> full flex-sdk build?
Does this mean we need to make a new PB release every time they change?

> 4) can we say that the clean target doesn't work?
I think it would be expected that it should work.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> OK.  Good point about the overlay of the notice files.  I'll add an ant
> target to copy just the pbk/pbj.
That would be required for the CI anyway wouldn't it?

> The goal was to not move the PBK files out to a different repo and
> instead, package a subset of the flex-sdk repo.
Can we actually do that ie does it follow Apache release guidelines? I'm not sure. Does that mean we also need to vote on a release a version of pixel bender when making a new SDK release?

>  Do you think everything on this list is required?
Not everything, It is expected that someone can take the source release and compile it and verify it to what's in version control.

> 1) can we tell folks in the RELEASE_NOTES not to run release-pixelbender
> target and say that it is for extracting this package from a full flex-sdk
> repo?
We can say what we want in RELEASE_NOTE/README. But it seem odd to me that you need the full Flex SDK is required just to make a release of pixel bender. What do other people think?

> 2) can we say that the LICENSE file contains extra licenses that may only
> apply to the full repo?
I would assume that LICENSE/NOTICE file needs to refer to the actual release (and any upstream projects) they are in not any downstream projects. The Apache licence make reference to the NOTICE file so we would need to legally comply with that.

> 3) can we say that the build.xml and properties files reference the full
> flex-sdk build?
Does this mean we need to make a new PB release every time they change?

> 4) can we say that the clean target doesn't work?
I think it would be expected that it should work.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.
OK.  Good point about the overlay of the notice files.  I'll add an ant
target to copy just the pbk/pbj.

The goal was to not move the PBK files out to a different repo and
instead, package a subset of the flex-sdk repo.  Do you think everything
on this list is required?  IOW:

1) can we tell folks in the RELEASE_NOTES not to run release-pixelbender
target and say that it is for extracting this package from a full flex-sdk
repo?

2) can we say that the LICENSE file contains extra licenses that may only
apply to the full repo?

3) can we say that the build.xml and properties files reference the full
flex-sdk build?

4) can we say that the clean target doesn't work?

Thanks for looking at it,
-Alex

On 12/17/13 2:26 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>Tested on OSX, there still a few things that need a little work IMO - see
>below.
>
>- MD5 and sigs all good (even though sig used is not in web of trust)
>gpg: Signature made Wed 18 Dec 04:28:17 2013 EST using RSA key ID DA9CCFF2
>gpg: Good signature from "Alex Harui (CODE SIGNING KEY)
><ah...@apache.org>"
>gpg: WARNING: This key is not certified with a trusted signature!
>
>- README still needs a little work eg git location of pixel bender is?
>
>- Release candidate not tagged in git (as far as I can see)
>
>- NOTICE file is incorrect (contains licences that shouldn't be there)
>
>- RELEASE_NOTES doesn't look right to me
>
>- "ant build-pixelbender" seems to work
>
>- to build the project ANT_HOME is not required (as far as I can tell)
>
>- "ant release-pixelbender" requires PLAYERGLOBAL_HOME, AIR_HOME,
>TLF_HOME and FLASHPLAYER_DEBUGGER to be set. While it likely they are set
>if you building the SDK, they shouldn't be required.
>
>- "ant release-pixelbender" fails with this error:
>BUILD FAILED
>/Users/justinmclean/Downloads/pixelbender/apache-flex-sdk-pixelbender-1.0.
>0-src/build.xml:850: Warning: Could not find file
>/Users/justinmclean/Downloads/pixelbender/apache-flex-sdk-pixelbender-1.0.
>0-src/README.pb to copy.
>
>- "ant clean" fails
>
>- build.properties and env-template.properties refer to Apache Flex 4.12
>
>- The build.xml contains much more than is needed to just build this
>project
>
>-"ant rat-check" fails but all files I checked did have correct license
>header (this does require ANT_HOME)
>
>- I have concerns about the instal instructions "It is meant to be
>expanded on top of an existing Flex SDK folder." This means that existing
>README, RELEASE_NOTES , build.xml files etc will be copied over. I think
>it would be better to have ant or  a script that moved only the needed
>files into a SDK directory.
>
>Thanks,
>Justin


Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

Tested on OSX, there still a few things that need a little work IMO - see below.

- MD5 and sigs all good (even though sig used is not in web of trust)
gpg: Signature made Wed 18 Dec 04:28:17 2013 EST using RSA key ID DA9CCFF2
gpg: Good signature from "Alex Harui (CODE SIGNING KEY) <ah...@apache.org>"
gpg: WARNING: This key is not certified with a trusted signature!

- README still needs a little work eg git location of pixel bender is?

- Release candidate not tagged in git (as far as I can see)

- NOTICE file is incorrect (contains licences that shouldn't be there)

- RELEASE_NOTES doesn't look right to me

- "ant build-pixelbender" seems to work

- to build the project ANT_HOME is not required (as far as I can tell)

- "ant release-pixelbender" requires PLAYERGLOBAL_HOME, AIR_HOME, TLF_HOME and FLASHPLAYER_DEBUGGER to be set. While it likely they are set if you building the SDK, they shouldn't be required.

- "ant release-pixelbender" fails with this error:
BUILD FAILED
/Users/justinmclean/Downloads/pixelbender/apache-flex-sdk-pixelbender-1.0.0-src/build.xml:850: Warning: Could not find file /Users/justinmclean/Downloads/pixelbender/apache-flex-sdk-pixelbender-1.0.0-src/README.pb to copy.

- "ant clean" fails

- build.properties and env-template.properties refer to Apache Flex 4.12

- The build.xml contains much more than is needed to just build this project

-"ant rat-check" fails but all files I checked did have correct license header (this does require ANT_HOME)

- I have concerns about the instal instructions "It is meant to be expanded on top of an existing Flex SDK folder." This means that existing README, RELEASE_NOTES , build.xml files etc will be copied over. I think it would be better to have ant or  a script that moved only the needed files into a SDK directory.

Thanks,
Justin

Re: [DISCUSS] Discuss Release Apache Flex PixelBender Package 1.0 (RC2)

Posted by Alex Harui <ah...@adobe.com>.
My new key is in the KEYS file (in the folder above the rc) so you will
need to import it to verify the signature.

On 12/17/13 9:46 AM, "Alex Harui" <ah...@adobe.com> wrote:

>Please use this thread for discussion.
>
>Thanks,
>-Alex
>