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/11 20:09:31 UTC
PixelBender and Builds.a.o
Thanks to Maurice, we have a pretty good idea of why Jenkins on builds.a.o
is not able to build the Flex SDK. Unfortunately, it isn't clear that
infra knows how to fix it or can fix it given how they want to run that
server.
Meanwhile, I'm still trying to get access to the PB compiler source, but
one person I talked to said that Alchemy-based shaders will outperform PB
shaders. So, one potential way to solve this problem is to replace our
shaders with Alchemy shaders. I have no idea how hard that would be.
Anybody think they can do it quickly?
Another option, which is a variant of what Maurice was proposing yesterday
is that we quickly create an official release package that contains just
the PBK files. Then the corresponding convenience binary package would
have the PBJ files. We call this an upstream package that only is
supported on Mac and Win. We would not use CI for this release.
Then we adjust the SDK build to use this upstream package. This is make
more official the workaround we are using for Linux and bring Linux up to
par with Mac and Win. Yes, the installer has to change as well, but
hopefully I'll have new installer capability ready shortly anyway that
should make it easier for us to make these changes.
Thoughts?
-Alex
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
This problem, aka "Session 0 Isolation", appeared with Windows XP.
Unfortunately, there is no simple workaround to access the GPU, without rewriting the .exe file.
Other software have the same issue ( gpu-accelerated databases, etc...)
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463353.aspx + click on the "download" button
google for "Session 0 isolation".
Regards,
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : mercredi 11 décembre 2013 20:27
À : dev@flex.apache.org
Objet : RE: PixelBender and Builds.a.o
Erik,
I am almost sure that he actually clicked on the "Install as service" menu in the Jenkins slave (startup command line of Jenkins slave match the "service" pattern, not the JNLP pattern).
That would make sense for them, because they certainly prefer that the Jenkins process could be run out of session, which is not the case with JNLP (the window is closed when you close the session).
Maurice
-----Message d'origine-----
De : Erik de Bruin [mailto:erik@ixsoftware.nl] Envoyé : mercredi 11 décembre 2013 20:21 À : dev@flex.apache.org Objet : Re: PixelBender and Builds.a.o
Your solution sounds good, and I like the "bring Linux up to par" part.
What I still can't figure out is why the builds stopped working suddenly a week ago, with Gavin maintaining he never changed a thing.
Well, I guess it doesn't really matter. I hope Om gets his VM online soon, so we can leave build@a.o behind us and maintain all aspects of our CI ourselves.
EdB
On Wed, Dec 11, 2013 at 8:09 PM, Alex Harui <ah...@adobe.com> wrote:
> Thanks to Maurice, we have a pretty good idea of why Jenkins on
> builds.a.o is not able to build the Flex SDK. Unfortunately, it isn't
> clear that infra knows how to fix it or can fix it given how they want
> to run that server.
>
> Meanwhile, I'm still trying to get access to the PB compiler source,
> but one person I talked to said that Alchemy-based shaders will
> outperform PB shaders. So, one potential way to solve this problem is
> to replace our shaders with Alchemy shaders. I have no idea how hard that would be.
> Anybody think they can do it quickly?
>
> Another option, which is a variant of what Maurice was proposing
> yesterday is that we quickly create an official release package that
> contains just the PBK files. Then the corresponding convenience
> binary package would have the PBJ files. We call this an upstream
> package that only is supported on Mac and Win. We would not use CI for this release.
>
> Then we adjust the SDK build to use this upstream package. This is
> make more official the workaround we are using for Linux and bring
> Linux up to par with Mac and Win. Yes, the installer has to change as
> well, but hopefully I'll have new installer capability ready shortly
> anyway that should make it easier for us to make these changes.
>
> Thoughts?
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
Erik,
I am almost sure that he actually clicked on the "Install as service" menu in the Jenkins slave (startup command line of Jenkins slave match the "service" pattern, not the JNLP pattern).
That would make sense for them, because they certainly prefer that the Jenkins process could be run out of session, which is not the case with JNLP (the window is closed when you close the session).
Maurice
-----Message d'origine-----
De : Erik de Bruin [mailto:erik@ixsoftware.nl]
Envoyé : mercredi 11 décembre 2013 20:21
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
Your solution sounds good, and I like the "bring Linux up to par" part.
What I still can't figure out is why the builds stopped working suddenly a week ago, with Gavin maintaining he never changed a thing.
Well, I guess it doesn't really matter. I hope Om gets his VM online soon, so we can leave build@a.o behind us and maintain all aspects of our CI ourselves.
EdB
On Wed, Dec 11, 2013 at 8:09 PM, Alex Harui <ah...@adobe.com> wrote:
> Thanks to Maurice, we have a pretty good idea of why Jenkins on
> builds.a.o is not able to build the Flex SDK. Unfortunately, it isn't
> clear that infra knows how to fix it or can fix it given how they want
> to run that server.
>
> Meanwhile, I'm still trying to get access to the PB compiler source,
> but one person I talked to said that Alchemy-based shaders will
> outperform PB shaders. So, one potential way to solve this problem is
> to replace our shaders with Alchemy shaders. I have no idea how hard that would be.
> Anybody think they can do it quickly?
>
> Another option, which is a variant of what Maurice was proposing
> yesterday is that we quickly create an official release package that
> contains just the PBK files. Then the corresponding convenience
> binary package would have the PBJ files. We call this an upstream
> package that only is supported on Mac and Win. We would not use CI for this release.
>
> Then we adjust the SDK build to use this upstream package. This is
> make more official the workaround we are using for Linux and bring
> Linux up to par with Mac and Win. Yes, the installer has to change as
> well, but hopefully I'll have new installer capability ready shortly
> anyway that should make it easier for us to make these changes.
>
> Thoughts?
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
I'm not sure if it is worth more time to find out why it stopped working.
It could be the server was not running as a service until a recent reboot,
or some recent upgrade of Jenkins broke the option that should have
allowed the service to use a window.
But if we are going to abandon builds.a.o forever, then should we still go
through all of this just to bring Linux up to par?
-Alex
On 12/11/13 11:20 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Your solution sounds good, and I like the "bring Linux up to par" part.
>
>What I still can't figure out is why the builds stopped working
>suddenly a week ago, with Gavin maintaining he never changed a thing.
>Well, I guess it doesn't really matter. I hope Om gets his VM online
>soon, so we can leave build@a.o behind us and maintain all aspects of
>our CI ourselves.
>
>EdB
>
>
>
>On Wed, Dec 11, 2013 at 8:09 PM, Alex Harui <ah...@adobe.com> wrote:
>> Thanks to Maurice, we have a pretty good idea of why Jenkins on
>>builds.a.o
>> is not able to build the Flex SDK. Unfortunately, it isn't clear that
>> infra knows how to fix it or can fix it given how they want to run that
>> server.
>>
>> Meanwhile, I'm still trying to get access to the PB compiler source, but
>> one person I talked to said that Alchemy-based shaders will outperform
>>PB
>> shaders. So, one potential way to solve this problem is to replace our
>> shaders with Alchemy shaders. I have no idea how hard that would be.
>> Anybody think they can do it quickly?
>>
>> Another option, which is a variant of what Maurice was proposing
>>yesterday
>> is that we quickly create an official release package that contains just
>> the PBK files. Then the corresponding convenience binary package would
>> have the PBJ files. We call this an upstream package that only is
>> supported on Mac and Win. We would not use CI for this release.
>>
>> Then we adjust the SDK build to use this upstream package. This is make
>> more official the workaround we are using for Linux and bring Linux up
>>to
>> par with Mac and Win. Yes, the installer has to change as well, but
>> hopefully I'll have new installer capability ready shortly anyway that
>> should make it easier for us to make these changes.
>>
>> Thoughts?
>> -Alex
>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: PixelBender and Builds.a.o
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Your solution sounds good, and I like the "bring Linux up to par" part.
What I still can't figure out is why the builds stopped working
suddenly a week ago, with Gavin maintaining he never changed a thing.
Well, I guess it doesn't really matter. I hope Om gets his VM online
soon, so we can leave build@a.o behind us and maintain all aspects of
our CI ourselves.
EdB
On Wed, Dec 11, 2013 at 8:09 PM, Alex Harui <ah...@adobe.com> wrote:
> Thanks to Maurice, we have a pretty good idea of why Jenkins on builds.a.o
> is not able to build the Flex SDK. Unfortunately, it isn't clear that
> infra knows how to fix it or can fix it given how they want to run that
> server.
>
> Meanwhile, I'm still trying to get access to the PB compiler source, but
> one person I talked to said that Alchemy-based shaders will outperform PB
> shaders. So, one potential way to solve this problem is to replace our
> shaders with Alchemy shaders. I have no idea how hard that would be.
> Anybody think they can do it quickly?
>
> Another option, which is a variant of what Maurice was proposing yesterday
> is that we quickly create an official release package that contains just
> the PBK files. Then the corresponding convenience binary package would
> have the PBJ files. We call this an upstream package that only is
> supported on Mac and Win. We would not use CI for this release.
>
> Then we adjust the SDK build to use this upstream package. This is make
> more official the workaround we are using for Linux and bring Linux up to
> par with Mac and Win. Yes, the installer has to change as well, but
> hopefully I'll have new installer capability ready shortly anyway that
> should make it easier for us to make these changes.
>
> Thoughts?
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: PixelBender and Builds.a.o
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Dec 11, 2013 at 11:30 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/11/13 11:25 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Wed, Dec 11, 2013 at 11:09 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Thanks to Maurice, we have a pretty good idea of why Jenkins on
> >>builds.a.o
> >> is not able to build the Flex SDK. Unfortunately, it isn't clear that
> >> infra knows how to fix it or can fix it given how they want to run that
> >> server.
> >>
> >
> >I will give Gavin a day or so and then ping him again. I think we should
> >be able to get a fix for this soon.
> Well, if he wants to run Jenkins as a service, is there really a fix? I'm
> thinking that we should change our packaging so he doesn't have to deal
> with this.
>
If he does not want to fix it, then we don't have a choice. But he hasn't
said no yet.
But +1 for figuring out workarounds instead of just waiting.
>
> >
> >
> >>
> >> Meanwhile, I'm still trying to get access to the PB compiler source, but
> >> one person I talked to said that Alchemy-based shaders will outperform
> >>PB
> >> shaders. So, one potential way to solve this problem is to replace our
> >> shaders with Alchemy shaders. I have no idea how hard that would be.
> >> Anybody think they can do it quickly?
> >>
> >
> >It should be possible, but that quickly removes FP 10.2, 10.3 and AIR
> >2.6,27 from the supported runtimes list. Alchemy/FlasCC is supported only
> >FP 11.0/AIR 3.0 and up [1]. Is this something we want to do?
> >From an enterprise support point of view, keeping support for 10.2 and
> >10.3
> >can only benefit us. I wouldnt want to give this up for a few shaders.
> OK.
> >
> >
> >>
> >> Another option, which is a variant of what Maurice was proposing
> >>yesterday
> >> is that we quickly create an official release package that contains just
> >> the PBK files. Then the corresponding convenience binary package would
> >> have the PBJ files. We call this an upstream package that only is
> >> supported on Mac and Win. We would not use CI for this release.
> >>
> >> Then we adjust the SDK build to use this upstream package. This is make
> >> more official the workaround we are using for Linux and bring Linux up
> >>to
> >> par with Mac and Win. Yes, the installer has to change as well, but
> >> hopefully I'll have new installer capability ready shortly anyway that
> >> should make it easier for us to make these changes.
> >>
> >
> >Works for me. We have not changed the pbk files forever, yet we keep
> >compiling them everytime and run into issues like these often. BTW, we
> >already have a job on builds.apache.org that does this [2]
> I assume this job would fail if it ever ran again?
>
>
It runs only after a successful build of flex-sdk, so it should be fine.
In any case, it does not matter because the artifacts of the last
successful build is good enough because the source pbk files have not
changed.
Thanks,
Om
> -Alex
>
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/11/13 11:25 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Wed, Dec 11, 2013 at 11:09 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> Thanks to Maurice, we have a pretty good idea of why Jenkins on
>>builds.a.o
>> is not able to build the Flex SDK. Unfortunately, it isn't clear that
>> infra knows how to fix it or can fix it given how they want to run that
>> server.
>>
>
>I will give Gavin a day or so and then ping him again. I think we should
>be able to get a fix for this soon.
Well, if he wants to run Jenkins as a service, is there really a fix? I'm
thinking that we should change our packaging so he doesn't have to deal
with this.
>
>
>>
>> Meanwhile, I'm still trying to get access to the PB compiler source, but
>> one person I talked to said that Alchemy-based shaders will outperform
>>PB
>> shaders. So, one potential way to solve this problem is to replace our
>> shaders with Alchemy shaders. I have no idea how hard that would be.
>> Anybody think they can do it quickly?
>>
>
>It should be possible, but that quickly removes FP 10.2, 10.3 and AIR
>2.6,27 from the supported runtimes list. Alchemy/FlasCC is supported only
>FP 11.0/AIR 3.0 and up [1]. Is this something we want to do?
>From an enterprise support point of view, keeping support for 10.2 and
>10.3
>can only benefit us. I wouldnt want to give this up for a few shaders.
OK.
>
>
>>
>> Another option, which is a variant of what Maurice was proposing
>>yesterday
>> is that we quickly create an official release package that contains just
>> the PBK files. Then the corresponding convenience binary package would
>> have the PBJ files. We call this an upstream package that only is
>> supported on Mac and Win. We would not use CI for this release.
>>
>> Then we adjust the SDK build to use this upstream package. This is make
>> more official the workaround we are using for Linux and bring Linux up
>>to
>> par with Mac and Win. Yes, the installer has to change as well, but
>> hopefully I'll have new installer capability ready shortly anyway that
>> should make it easier for us to make these changes.
>>
>
>Works for me. We have not changed the pbk files forever, yet we keep
>compiling them everytime and run into issues like these often. BTW, we
>already have a job on builds.apache.org that does this [2]
I assume this job would fail if it ever ran again?
-Alex
Re: PixelBender and Builds.a.o
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Dec 11, 2013 at 11:09 AM, Alex Harui <ah...@adobe.com> wrote:
> Thanks to Maurice, we have a pretty good idea of why Jenkins on builds.a.o
> is not able to build the Flex SDK. Unfortunately, it isn't clear that
> infra knows how to fix it or can fix it given how they want to run that
> server.
>
I will give Gavin a day or so and then ping him again. I think we should
be able to get a fix for this soon.
>
> Meanwhile, I'm still trying to get access to the PB compiler source, but
> one person I talked to said that Alchemy-based shaders will outperform PB
> shaders. So, one potential way to solve this problem is to replace our
> shaders with Alchemy shaders. I have no idea how hard that would be.
> Anybody think they can do it quickly?
>
It should be possible, but that quickly removes FP 10.2, 10.3 and AIR
2.6,27 from the supported runtimes list. Alchemy/FlasCC is supported only
FP 11.0/AIR 3.0 and up [1]. Is this something we want to do?
>From an enterprise support point of view, keeping support for 10.2 and 10.3
can only benefit us. I wouldnt want to give this up for a few shaders.
>
> Another option, which is a variant of what Maurice was proposing yesterday
> is that we quickly create an official release package that contains just
> the PBK files. Then the corresponding convenience binary package would
> have the PBJ files. We call this an upstream package that only is
> supported on Mac and Win. We would not use CI for this release.
>
> Then we adjust the SDK build to use this upstream package. This is make
> more official the workaround we are using for Linux and bring Linux up to
> par with Mac and Win. Yes, the installer has to change as well, but
> hopefully I'll have new installer capability ready shortly anyway that
> should make it easier for us to make these changes.
>
Works for me. We have not changed the pbk files forever, yet we keep
compiling them everytime and run into issues like these often. BTW, we
already have a job on builds.apache.org that does this [2]
>
> Thoughts?
> -Alex
>
>
[1] http://www.adobe.com/devnet-docs/flascc/
[2] https://builds.apache.org/job/flex-sdk_pixelbender/
Re: PixelBender and Builds.a.o
Posted by Tom Chiverton <tc...@extravision.com>.
On 12/12/2013 16:27, Maurice Amsellem wrote:
> What option in 4) I think a) is the easiest, and it does not break any Apache rule.
But it makes these files even more special than they already are.
The installers job is to fetch dependencies of the SDK and do the right
thing with them, so adding these files as another step seems clearer.
Tom
Re: PixelBender and Builds.a.o
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> I'm still curious as to where it is written down so I don't forget next
> time when I put up FlexJS or Falcon rcs.
I took a look at a few other project in the release area and it's basically all over the place. (There's even some RCs in the dist release area!) The important thing obviously is it must be the the source and binary packages, beyond that it's probably only a nice to have (just like the KEYS, README or RELEASE_NOTES files) so you can read them before having to download the release.
Justin
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
OK. I added following the pattern I saw in the sdk folder.
I'm still curious as to where it is written down so I don't forget next
time when I put up FlexJS or Falcon rcs.
-Alex
On 12/13/13 12:15 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>>
>>https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SD
>>K
>> Should it be updated to also mention LICENSE?
>
>The LICENSE file is above the rc directories there so there no need to
>change the docs as there no need to add it every time you make a RC.
>
>Thanks,
>Justin
Re: PixelBender and Builds.a.o
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK
> Should it be updated to also mention LICENSE?
The LICENSE file is above the rc directories there so there no need to change the docs as there no need to add it every time you make a RC.
Thanks,
Justin
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 11:44 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>>> You might want to add a LICENSE file before calling a vote :-)
>> Crap. Which package(s) is it missing from?
>I didn't check the packages (yet), but there's normally one in the SVN
>tree.
I was following
https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK
Should it be updated to also mention LICENSE?
>
>>> And while not essential a KEYs file is also useful.
>> I thought KEYS weren't supposed to be in the package?
>Also put in SVn to help verify the release - not essential - just makes
>it easier.
>
>Justin
Re: PixelBender and Builds.a.o
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> You might want to add a LICENSE file before calling a vote :-)
> Crap. Which package(s) is it missing from?
I didn't check the packages (yet), but there's normally one in the SVN tree.
>> And while not essential a KEYs file is also useful.
> I thought KEYS weren't supposed to be in the package?
Also put in SVn to help verify the release - not essential - just makes it easier.
Justin
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 11:25 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>You might want to add a LICENSE file before calling a vote :-)
Crap. Which package(s) is it missing from? I'm seeing one when I expand
the src.tar.gz and -bin.zip
>
>And while not essential a KEYs file is also useful.
I thought KEYS weren't supposed to be in the package?
>
>Thanks,
>Justin
Re: PixelBender and Builds.a.o
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
You might want to add a LICENSE file before calling a vote :-)
And while not essential a KEYs file is also useful.
Thanks,
Justin
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
OK, I've pushed the changes for this. The rc for the pixel bender
packages is at [1]
I'll call for a vote if jenkins starts working and nothing obvious breaks.
It's almost quitting time for tonight so if there is fallout, I'll have
to deal with it tomorrow.
-Alex
[1] https://dist.apache.org/repos/dist/dev/flex/pixelbender/rc1/
On 12/12/13 11:12 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>Someone would run this script once, then commit the zip file to
>>flex-utilities/pixel_bender, that could be used by other scripts...
>>I think with this plan we won't be touching flex-utilities. We can't
>>check a zip in there. The packages will go on dist after a vote.
>
>Sorry, I meant "commit to dist".
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 20:02
>À : dev@flex.apache.org
>Objet : Re: PixelBender and Builds.a.o
>
>
>
>On 12/12/13 10:32 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.
>>
>>That sound like a good idea.
>>I think the build script should be a concatenation of the current
>>pixel_bender_compile (that produces the pbj in place) and "archive-pbj"
>>target in the main build.xml, that zips the sdk pbjs, in ./out/pb.tar.
>I think more adjustments are needed. I think we have to create a true
>source and binary package, package up NOTICE and LICENSE files, etc.
>
>>Someone would run this script once, then commit the zip file to
>>flex-utilities/pixel_bender, that could be used by other scripts...
>I think with this plan we won't be touching flex-utilities. We can't
>check a zip in there. The packages will go on dist after a vote.
>
>Or am I missing something?
>
>-Alex
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
>Someone would run this script once, then commit the zip file to
>flex-utilities/pixel_bender, that could be used by other scripts...
>I think with this plan we won't be touching flex-utilities. We can't check a zip in there. The packages will go on dist after a vote.
Sorry, I meant "commit to dist".
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 20:02
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
On 12/12/13 10:32 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.
>
>That sound like a good idea.
>I think the build script should be a concatenation of the current
>pixel_bender_compile (that produces the pbj in place) and "archive-pbj"
>target in the main build.xml, that zips the sdk pbjs, in ./out/pb.tar.
I think more adjustments are needed. I think we have to create a true source and binary package, package up NOTICE and LICENSE files, etc.
>Someone would run this script once, then commit the zip file to
>flex-utilities/pixel_bender, that could be used by other scripts...
I think with this plan we won't be touching flex-utilities. We can't check a zip in there. The packages will go on dist after a vote.
Or am I missing something?
-Alex
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 10:32 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.
>
>That sound like a good idea.
>I think the build script should be a concatenation of the current
>pixel_bender_compile (that produces the pbj in place)
>and "archive-pbj" target in the main build.xml, that zips the sdk pbjs,
>in ./out/pb.tar.
I think more adjustments are needed. I think we have to create a true
source and binary package, package up NOTICE and LICENSE files, etc.
>Someone would run this script once, then commit the zip file to
>flex-utilities/pixel_bender, that could be used by other scripts...
I think with this plan we won't be touching flex-utilities. We can't
check a zip in there. The packages will go on dist after a vote.
Or am I missing something?
-Alex
RE: PixelBender and Builds.a.o
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.
That sound like a good idea.
I think the build script should be a concatenation of the current pixel_bender_compile (that produces the pbj in place)
and "archive-pbj" target in the main build.xml, that zips the sdk pbjs, in ./out/pb.tar.
Someone would run this script once, then commit the zip file to flex-utilities/pixel_bender, that could be used by other scripts...
WDYT?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 19:06
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
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.
-Alex
On 12/12/13 9:55 AM, "Alex Harui" <ah...@adobe.com> wrote:
>I was going to move (not copy) the pbks out to flex-utilities. Today
>we already pull in source from flex-tlf repo when making a release package.
>I think it will work if I do essentially the same thing for the pbks.
>
>-Alex
>
>On 12/12/13 9:42 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>IMO, the binary package can only contain pbj's if the source package
>>>contains the source pbk's and a way to compile them.
>>>The binary package probably cannot contain >a zip of the pbj's either.
>>>The idea of the binary package is that it contains the result of the
>>>compilation, to save folks >having to set up the compile/build
>>>environment. >My understanding is that it cannot contain other
>>>artifacts.
>>
>>You are correct.
>>So does this mean the pbk would be duplicated on both dist repo and
>>flex-sdk git repo?
>>I don't like the idea to have duplicate source code.
>>
>>Otherwise, this means the pbk would be in one single place, so
>>necessarily in flex-sdk git repo (as is currently the case).
>>This implies the build file in dist would fetch the pbk sources from
>>git, which means cloning the whole git flex-sdk repo for 10 source files...
>>
>>So it's git clone for 10 files, or duplicate source, but for files
>>that won't change much.
>>
>>WDYT?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 18:20 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>
>>
>>On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>> B) I don't think I understood your 4a, but it doesn't sound like it
>>>>would meet policy. No zips are allowed in svn.
>>>
>>>I am confused.
>>> Isn't
>>>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>>>an svn repo?
>>> And it does contain zip and binaries.
>>>
>>>So if svn cannot contain zips, how do we make commit the result of pb
>>>compilation ? as plain files ?
>>Ah, I understand now. Yes, we use SVN to put things on dist. We
>>didn't used to. When you say svn or git I think of our repos. Dist
>>(and
>>archive) can have binary artifacts.
>>>
>>>My 4a) is more or less your B) => "build scripts copy the pbk source
>>>from dist into the source package and pbjs from dist into the binary
>>>package".
>>>Expect that I retrieve one zip file with internal directory structure
>>>(same as the one produced by obsolete pixel_bender Jenkins job) from
>>>dist and copy it to binary package, instead of individual flat files.
>>>I don't think this breaks any rule ..
>>IMO, the binary package can only contain pbj's if the source package
>>contains the source pbk's and a way to compile them. The binary
>>package probably cannot contain a zip of the pbj's either. The idea
>>of the binary package is that it contains the result of the
>>compilation, to save folks having to set up the compile/build
>>environment. My understanding is that it cannot contain other artifacts.
>>
>>>
>>>>If you plan to take this on, please let us know
>>>Not at the moment. I am just trying to detail the steps, in case it
>>>needs to be done later (by anyone who want to).
>>>Hoping the infra will fix the current issue...
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>Builds.a.o
>>>
>>>I agree with most of it except:
>>>
>>>A) we can't auto-commit to dist. I believe only voted on artifacts
>>>can go there. But realistically, I think we're only going to commit
>>>once unless someone find a reason to change the PBK files.
>>>
>>>B) I don't think I understood your 4a, but it doesn't sound like it
>>>would meet policy. No zips are allowed in svn.
>>>
>>>A binary package is only supposed to additionally contain compiled
>>>artifacts of the source package. I'd rather not have to change the
>>>installer either right now since I'm working on a major upgrade to it
>>>and don't want to add that to the delays to get our CI up and running
>>>again.
>>>I think the best short term answer is that the SDK build scripts copy
>>>the pbk source from dist into the source package and pbjs from dist
>>>into the binary package. That sort of fudges the tag==package policy
>>>but essentially we can show there are already multiple tags in our
>>>packages since we pull TLF from its own repo.
>>>
>>>If you plan to take this on, please let us know. I'm waiting to see
>>>if Infra did try again to reboot the server. If they did and the
>>>recent failure means it is still busted, it is definitely time to
>>>start making these changes, so one of should start on it.
>>>
>>>-Alex
>>>
>>>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>>>wrote:
>>>
>>>>Thanks Alex.
>>>>
>>>>So IIUC,
>>>>
>>>>1) create new folder "pixel_bender" under
>>>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>>>> - will contain the zip files generated by the build below
>>>>
>>>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT
>>>>repo
>>>>containing:
>>>> - PBK sources for flex-sdk
>>>> - build file for compiling pbk into pbj
>>>> Output = pb.zip file containing pbj + pbk (similar structure to
>>>>current pixelbender upstream Jenkins job)
>>>> [Bonus] auto-commmit the zip file to
>>>>dist/.../pixel_bender
>>>>
>>>>=> build file must be run manually by "Release manager"
>>>>
>>>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>>>(obsolete)
>>>>
>>>>4) to include pbk+pbj in Flex SDK release there are two options
>>>>a) modify build_release.sh (or equivalent) to checkout pb.zip from
>>>>svn and unzip into dist
>>>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>>>
>>>>Is that correct?
>>>>What option in 4) I think a) is the easiest, and it does not break
>>>>any Apache rule.
>>>>
>>>>Maurice
>>>>
>>>>-----Message d'origine-----
>>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>>Builds.a.o
>>>>
>>>>
>>>>
>>>>On 12/12/13 5:03 AM, "Maurice Amsellem"
>>>><ma...@systar.com>
>>>>wrote:
>>>>
>>>>>I am trying to understand the steps below:
>>>>>
>>>>>Where would the pbk => pbj compilation take place ?
>>>>In the build script for this "project".
>>>>>
>>>>>Where would the pbj be stored after the build , if the build does
>>>>>not occur on the CI?
>>>>On the same servers we store our voted on releases.
>>>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>>>somewhere ?
>>>>All releases are compiled by someone running the build script and
>>>>signing the artifacts. Apache even seems to not want to allow
>>>>signing of Jenkins-built artifacts.
>>>>
>>>>-Alex
>>>>
>>>
>>
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.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.
-Alex
On 12/12/13 9:55 AM, "Alex Harui" <ah...@adobe.com> wrote:
>I was going to move (not copy) the pbks out to flex-utilities. Today we
>already pull in source from flex-tlf repo when making a release package.
>I think it will work if I do essentially the same thing for the pbks.
>
>-Alex
>
>On 12/12/13 9:42 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>IMO, the binary package can only contain pbj's if the source package
>>>contains the source pbk's and a way to compile them.
>>>The binary package probably cannot contain >a zip of the pbj's either.
>>>The idea of the binary package is that it contains the result of the
>>>compilation, to save folks >having to set up the compile/build
>>>environment. >My understanding is that it cannot contain other
>>>artifacts.
>>
>>You are correct.
>>So does this mean the pbk would be duplicated on both dist repo and
>>flex-sdk git repo?
>>I don't like the idea to have duplicate source code.
>>
>>Otherwise, this means the pbk would be in one single place, so
>>necessarily in flex-sdk git repo (as is currently the case).
>>This implies the build file in dist would fetch the pbk sources from git,
>>which means cloning the whole git flex-sdk repo for 10 source files...
>>
>>So it's git clone for 10 files, or duplicate source, but for files that
>>won't change much.
>>
>>WDYT?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com]
>>Envoyé : jeudi 12 décembre 2013 18:20
>>À : dev@flex.apache.org
>>Objet : Re: PixelBender and Builds.a.o
>>
>>
>>
>>On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>> B) I don't think I understood your 4a, but it doesn't sound like it
>>>>would meet policy. No zips are allowed in svn.
>>>
>>>I am confused.
>>> Isn't
>>>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>>>an svn repo?
>>> And it does contain zip and binaries.
>>>
>>>So if svn cannot contain zips, how do we make commit the result of pb
>>>compilation ? as plain files ?
>>Ah, I understand now. Yes, we use SVN to put things on dist. We didn't
>>used to. When you say svn or git I think of our repos. Dist (and
>>archive) can have binary artifacts.
>>>
>>>My 4a) is more or less your B) => "build scripts copy the pbk source
>>>from dist into the source package and pbjs from dist into the binary
>>>package".
>>>Expect that I retrieve one zip file with internal directory structure
>>>(same as the one produced by obsolete pixel_bender Jenkins job) from
>>>dist and copy it to binary package, instead of individual flat files.
>>>I don't think this breaks any rule ..
>>IMO, the binary package can only contain pbj's if the source package
>>contains the source pbk's and a way to compile them. The binary package
>>probably cannot contain a zip of the pbj's either. The idea of the
>>binary package is that it contains the result of the compilation, to save
>>folks having to set up the compile/build environment. My understanding
>>is that it cannot contain other artifacts.
>>
>>>
>>>>If you plan to take this on, please let us know
>>>Not at the moment. I am just trying to detail the steps, in case it
>>>needs to be done later (by anyone who want to).
>>>Hoping the infra will fix the current issue...
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>Builds.a.o
>>>
>>>I agree with most of it except:
>>>
>>>A) we can't auto-commit to dist. I believe only voted on artifacts can
>>>go there. But realistically, I think we're only going to commit once
>>>unless someone find a reason to change the PBK files.
>>>
>>>B) I don't think I understood your 4a, but it doesn't sound like it
>>>would meet policy. No zips are allowed in svn.
>>>
>>>A binary package is only supposed to additionally contain compiled
>>>artifacts of the source package. I'd rather not have to change the
>>>installer either right now since I'm working on a major upgrade to it
>>>and don't want to add that to the delays to get our CI up and running
>>>again.
>>>I think the best short term answer is that the SDK build scripts copy
>>>the pbk source from dist into the source package and pbjs from dist
>>>into the binary package. That sort of fudges the tag==package policy
>>>but essentially we can show there are already multiple tags in our
>>>packages since we pull TLF from its own repo.
>>>
>>>If you plan to take this on, please let us know. I'm waiting to see if
>>>Infra did try again to reboot the server. If they did and the recent
>>>failure means it is still busted, it is definitely time to start making
>>>these changes, so one of should start on it.
>>>
>>>-Alex
>>>
>>>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>>>wrote:
>>>
>>>>Thanks Alex.
>>>>
>>>>So IIUC,
>>>>
>>>>1) create new folder "pixel_bender" under
>>>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>>>> - will contain the zip files generated by the build below
>>>>
>>>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT
>>>>repo
>>>>containing:
>>>> - PBK sources for flex-sdk
>>>> - build file for compiling pbk into pbj
>>>> Output = pb.zip file containing pbj + pbk (similar structure to
>>>>current pixelbender upstream Jenkins job)
>>>> [Bonus] auto-commmit the zip file to
>>>>dist/.../pixel_bender
>>>>
>>>>=> build file must be run manually by "Release manager"
>>>>
>>>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>>>(obsolete)
>>>>
>>>>4) to include pbk+pbj in Flex SDK release there are two options
>>>>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>>>>and unzip into dist
>>>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>>>
>>>>Is that correct?
>>>>What option in 4) I think a) is the easiest, and it does not break
>>>>any Apache rule.
>>>>
>>>>Maurice
>>>>
>>>>-----Message d'origine-----
>>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>>Builds.a.o
>>>>
>>>>
>>>>
>>>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>>>wrote:
>>>>
>>>>>I am trying to understand the steps below:
>>>>>
>>>>>Where would the pbk => pbj compilation take place ?
>>>>In the build script for this "project".
>>>>>
>>>>>Where would the pbj be stored after the build , if the build does not
>>>>>occur on the CI?
>>>>On the same servers we store our voted on releases.
>>>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>>>somewhere ?
>>>>All releases are compiled by someone running the build script and
>>>>signing the artifacts. Apache even seems to not want to allow signing
>>>>of Jenkins-built artifacts.
>>>>
>>>>-Alex
>>>>
>>>
>>
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 10:08 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I was going to move (not copy) the pbks out to flex-utilities. Today we
>>already pull in source from flex-tlf repo when making a release package.
>>I think it will work if I do essentially the same thing for the pbks.
>
>So that means the pbk sources won't be present in the git repo, but only
>in the released source and released binary source.
>And people who want to modify / manually build the sdk will have to
>download them separately from flex-utilies, like they currently do for
>TLF.
>
>Is that correct ?
Yup. See my other reply. It might be best to just add new targets to the
SDK build scripts.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 18:56
>À : dev@flex.apache.org
>Objet : Re: PixelBender and Builds.a.o
>
>I was going to move (not copy) the pbks out to flex-utilities. Today we
>already pull in source from flex-tlf repo when making a release package.
>I think it will work if I do essentially the same thing for the pbks.
>
>-Alex
>
>On 12/12/13 9:42 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>IMO, the binary package can only contain pbj's if the source package
>>>contains the source pbk's and a way to compile them.
>>>The binary package probably cannot contain >a zip of the pbj's either.
>>>The idea of the binary package is that it contains the result of the
>>>compilation, to save folks >having to set up the compile/build
>>>environment. >My understanding is that it cannot contain other
>>>artifacts.
>>
>>You are correct.
>>So does this mean the pbk would be duplicated on both dist repo and
>>flex-sdk git repo?
>>I don't like the idea to have duplicate source code.
>>
>>Otherwise, this means the pbk would be in one single place, so
>>necessarily in flex-sdk git repo (as is currently the case).
>>This implies the build file in dist would fetch the pbk sources from
>>git, which means cloning the whole git flex-sdk repo for 10 source
>>files...
>>
>>So it's git clone for 10 files, or duplicate source, but for files that
>>won't change much.
>>
>>WDYT?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 18:20 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>
>>
>>On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>> B) I don't think I understood your 4a, but it doesn't sound like it
>>>>would meet policy. No zips are allowed in svn.
>>>
>>>I am confused.
>>> Isn't
>>>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>>>an svn repo?
>>> And it does contain zip and binaries.
>>>
>>>So if svn cannot contain zips, how do we make commit the result of pb
>>>compilation ? as plain files ?
>>Ah, I understand now. Yes, we use SVN to put things on dist. We
>>didn't used to. When you say svn or git I think of our repos. Dist
>>(and
>>archive) can have binary artifacts.
>>>
>>>My 4a) is more or less your B) => "build scripts copy the pbk source
>>>from dist into the source package and pbjs from dist into the binary
>>>package".
>>>Expect that I retrieve one zip file with internal directory structure
>>>(same as the one produced by obsolete pixel_bender Jenkins job) from
>>>dist and copy it to binary package, instead of individual flat files.
>>>I don't think this breaks any rule ..
>>IMO, the binary package can only contain pbj's if the source package
>>contains the source pbk's and a way to compile them. The binary
>>package probably cannot contain a zip of the pbj's either. The idea of
>>the binary package is that it contains the result of the compilation,
>>to save folks having to set up the compile/build environment. My
>>understanding is that it cannot contain other artifacts.
>>
>>>
>>>>If you plan to take this on, please let us know
>>>Not at the moment. I am just trying to detail the steps, in case it
>>>needs to be done later (by anyone who want to).
>>>Hoping the infra will fix the current issue...
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>Builds.a.o
>>>
>>>I agree with most of it except:
>>>
>>>A) we can't auto-commit to dist. I believe only voted on artifacts
>>>can go there. But realistically, I think we're only going to commit
>>>once unless someone find a reason to change the PBK files.
>>>
>>>B) I don't think I understood your 4a, but it doesn't sound like it
>>>would meet policy. No zips are allowed in svn.
>>>
>>>A binary package is only supposed to additionally contain compiled
>>>artifacts of the source package. I'd rather not have to change the
>>>installer either right now since I'm working on a major upgrade to it
>>>and don't want to add that to the delays to get our CI up and running
>>>again.
>>>I think the best short term answer is that the SDK build scripts copy
>>>the pbk source from dist into the source package and pbjs from dist
>>>into the binary package. That sort of fudges the tag==package policy
>>>but essentially we can show there are already multiple tags in our
>>>packages since we pull TLF from its own repo.
>>>
>>>If you plan to take this on, please let us know. I'm waiting to see
>>>if Infra did try again to reboot the server. If they did and the
>>>recent failure means it is still busted, it is definitely time to
>>>start making these changes, so one of should start on it.
>>>
>>>-Alex
>>>
>>>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>>>wrote:
>>>
>>>>Thanks Alex.
>>>>
>>>>So IIUC,
>>>>
>>>>1) create new folder "pixel_bender" under
>>>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>>>> - will contain the zip files generated by the build below
>>>>
>>>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT
>>>>repo
>>>>containing:
>>>> - PBK sources for flex-sdk
>>>> - build file for compiling pbk into pbj
>>>> Output = pb.zip file containing pbj + pbk (similar structure to
>>>>current pixelbender upstream Jenkins job)
>>>> [Bonus] auto-commmit the zip file to
>>>>dist/.../pixel_bender
>>>>
>>>>=> build file must be run manually by "Release manager"
>>>>
>>>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>>>(obsolete)
>>>>
>>>>4) to include pbk+pbj in Flex SDK release there are two options
>>>>a) modify build_release.sh (or equivalent) to checkout pb.zip from
>>>>svn and unzip into dist
>>>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>>>
>>>>Is that correct?
>>>>What option in 4) I think a) is the easiest, and it does not break
>>>>any Apache rule.
>>>>
>>>>Maurice
>>>>
>>>>-----Message d'origine-----
>>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>>Builds.a.o
>>>>
>>>>
>>>>
>>>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>>>wrote:
>>>>
>>>>>I am trying to understand the steps below:
>>>>>
>>>>>Where would the pbk => pbj compilation take place ?
>>>>In the build script for this "project".
>>>>>
>>>>>Where would the pbj be stored after the build , if the build does
>>>>>not occur on the CI?
>>>>On the same servers we store our voted on releases.
>>>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>>>somewhere ?
>>>>All releases are compiled by someone running the build script and
>>>>signing the artifacts. Apache even seems to not want to allow
>>>>signing of Jenkins-built artifacts.
>>>>
>>>>-Alex
>>>>
>>>
>>
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
>I was going to move (not copy) the pbks out to flex-utilities. Today we already pull in source from flex-tlf repo when making a release package.
>I think it will work if I do essentially the same thing for the pbks.
So that means the pbk sources won't be present in the git repo, but only in the released source and released binary source.
And people who want to modify / manually build the sdk will have to download them separately from flex-utilies, like they currently do for TLF.
Is that correct ?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 18:56
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
I was going to move (not copy) the pbks out to flex-utilities. Today we already pull in source from flex-tlf repo when making a release package.
I think it will work if I do essentially the same thing for the pbks.
-Alex
On 12/12/13 9:42 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>IMO, the binary package can only contain pbj's if the source package
>>contains the source pbk's and a way to compile them.
>>The binary package probably cannot contain >a zip of the pbj's either.
>>The idea of the binary package is that it contains the result of the
>>compilation, to save folks >having to set up the compile/build
>>environment. >My understanding is that it cannot contain other
>>artifacts.
>
>You are correct.
>So does this mean the pbk would be duplicated on both dist repo and
>flex-sdk git repo?
>I don't like the idea to have duplicate source code.
>
>Otherwise, this means the pbk would be in one single place, so
>necessarily in flex-sdk git repo (as is currently the case).
>This implies the build file in dist would fetch the pbk sources from
>git, which means cloning the whole git flex-sdk repo for 10 source files...
>
>So it's git clone for 10 files, or duplicate source, but for files that
>won't change much.
>
>WDYT?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>2013 18:20 À : dev@flex.apache.org Objet : Re: PixelBender and
>Builds.a.o
>
>
>
>On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>> B) I don't think I understood your 4a, but it doesn't sound like it
>>>would meet policy. No zips are allowed in svn.
>>
>>I am confused.
>> Isn't
>>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>>an svn repo?
>> And it does contain zip and binaries.
>>
>>So if svn cannot contain zips, how do we make commit the result of pb
>>compilation ? as plain files ?
>Ah, I understand now. Yes, we use SVN to put things on dist. We
>didn't used to. When you say svn or git I think of our repos. Dist
>(and
>archive) can have binary artifacts.
>>
>>My 4a) is more or less your B) => "build scripts copy the pbk source
>>from dist into the source package and pbjs from dist into the binary
>>package".
>>Expect that I retrieve one zip file with internal directory structure
>>(same as the one produced by obsolete pixel_bender Jenkins job) from
>>dist and copy it to binary package, instead of individual flat files.
>>I don't think this breaks any rule ..
>IMO, the binary package can only contain pbj's if the source package
>contains the source pbk's and a way to compile them. The binary
>package probably cannot contain a zip of the pbj's either. The idea of
>the binary package is that it contains the result of the compilation,
>to save folks having to set up the compile/build environment. My
>understanding is that it cannot contain other artifacts.
>
>>
>>>If you plan to take this on, please let us know
>>Not at the moment. I am just trying to detail the steps, in case it
>>needs to be done later (by anyone who want to).
>>Hoping the infra will fix the current issue...
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>I agree with most of it except:
>>
>>A) we can't auto-commit to dist. I believe only voted on artifacts
>>can go there. But realistically, I think we're only going to commit
>>once unless someone find a reason to change the PBK files.
>>
>>B) I don't think I understood your 4a, but it doesn't sound like it
>>would meet policy. No zips are allowed in svn.
>>
>>A binary package is only supposed to additionally contain compiled
>>artifacts of the source package. I'd rather not have to change the
>>installer either right now since I'm working on a major upgrade to it
>>and don't want to add that to the delays to get our CI up and running
>>again.
>>I think the best short term answer is that the SDK build scripts copy
>>the pbk source from dist into the source package and pbjs from dist
>>into the binary package. That sort of fudges the tag==package policy
>>but essentially we can show there are already multiple tags in our
>>packages since we pull TLF from its own repo.
>>
>>If you plan to take this on, please let us know. I'm waiting to see
>>if Infra did try again to reboot the server. If they did and the
>>recent failure means it is still busted, it is definitely time to
>>start making these changes, so one of should start on it.
>>
>>-Alex
>>
>>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>Thanks Alex.
>>>
>>>So IIUC,
>>>
>>>1) create new folder "pixel_bender" under
>>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>>> - will contain the zip files generated by the build below
>>>
>>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>>>containing:
>>> - PBK sources for flex-sdk
>>> - build file for compiling pbk into pbj
>>> Output = pb.zip file containing pbj + pbk (similar structure to
>>>current pixelbender upstream Jenkins job)
>>> [Bonus] auto-commmit the zip file to
>>>dist/.../pixel_bender
>>>
>>>=> build file must be run manually by "Release manager"
>>>
>>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>>(obsolete)
>>>
>>>4) to include pbk+pbj in Flex SDK release there are two options
>>>a) modify build_release.sh (or equivalent) to checkout pb.zip from
>>>svn and unzip into dist
>>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>>
>>>Is that correct?
>>>What option in 4) I think a) is the easiest, and it does not break
>>>any Apache rule.
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>Builds.a.o
>>>
>>>
>>>
>>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>>wrote:
>>>
>>>>I am trying to understand the steps below:
>>>>
>>>>Where would the pbk => pbj compilation take place ?
>>>In the build script for this "project".
>>>>
>>>>Where would the pbj be stored after the build , if the build does
>>>>not occur on the CI?
>>>On the same servers we store our voted on releases.
>>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>>somewhere ?
>>>All releases are compiled by someone running the build script and
>>>signing the artifacts. Apache even seems to not want to allow
>>>signing of Jenkins-built artifacts.
>>>
>>>-Alex
>>>
>>
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
I was going to move (not copy) the pbks out to flex-utilities. Today we
already pull in source from flex-tlf repo when making a release package.
I think it will work if I do essentially the same thing for the pbks.
-Alex
On 12/12/13 9:42 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>IMO, the binary package can only contain pbj's if the source package
>>contains the source pbk's and a way to compile them.
>>The binary package probably cannot contain >a zip of the pbj's either.
>>The idea of the binary package is that it contains the result of the
>>compilation, to save folks >having to set up the compile/build
>>environment. >My understanding is that it cannot contain other
>>artifacts.
>
>You are correct.
>So does this mean the pbk would be duplicated on both dist repo and
>flex-sdk git repo?
>I don't like the idea to have duplicate source code.
>
>Otherwise, this means the pbk would be in one single place, so
>necessarily in flex-sdk git repo (as is currently the case).
>This implies the build file in dist would fetch the pbk sources from git,
>which means cloning the whole git flex-sdk repo for 10 source files...
>
>So it's git clone for 10 files, or duplicate source, but for files that
>won't change much.
>
>WDYT?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 18:20
>À : dev@flex.apache.org
>Objet : Re: PixelBender and Builds.a.o
>
>
>
>On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>> B) I don't think I understood your 4a, but it doesn't sound like it
>>>would meet policy. No zips are allowed in svn.
>>
>>I am confused.
>> Isn't
>>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>>an svn repo?
>> And it does contain zip and binaries.
>>
>>So if svn cannot contain zips, how do we make commit the result of pb
>>compilation ? as plain files ?
>Ah, I understand now. Yes, we use SVN to put things on dist. We didn't
>used to. When you say svn or git I think of our repos. Dist (and
>archive) can have binary artifacts.
>>
>>My 4a) is more or less your B) => "build scripts copy the pbk source
>>from dist into the source package and pbjs from dist into the binary
>>package".
>>Expect that I retrieve one zip file with internal directory structure
>>(same as the one produced by obsolete pixel_bender Jenkins job) from
>>dist and copy it to binary package, instead of individual flat files.
>>I don't think this breaks any rule ..
>IMO, the binary package can only contain pbj's if the source package
>contains the source pbk's and a way to compile them. The binary package
>probably cannot contain a zip of the pbj's either. The idea of the
>binary package is that it contains the result of the compilation, to save
>folks having to set up the compile/build environment. My understanding
>is that it cannot contain other artifacts.
>
>>
>>>If you plan to take this on, please let us know
>>Not at the moment. I am just trying to detail the steps, in case it
>>needs to be done later (by anyone who want to).
>>Hoping the infra will fix the current issue...
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>I agree with most of it except:
>>
>>A) we can't auto-commit to dist. I believe only voted on artifacts can
>>go there. But realistically, I think we're only going to commit once
>>unless someone find a reason to change the PBK files.
>>
>>B) I don't think I understood your 4a, but it doesn't sound like it
>>would meet policy. No zips are allowed in svn.
>>
>>A binary package is only supposed to additionally contain compiled
>>artifacts of the source package. I'd rather not have to change the
>>installer either right now since I'm working on a major upgrade to it
>>and don't want to add that to the delays to get our CI up and running
>>again.
>>I think the best short term answer is that the SDK build scripts copy
>>the pbk source from dist into the source package and pbjs from dist
>>into the binary package. That sort of fudges the tag==package policy
>>but essentially we can show there are already multiple tags in our
>>packages since we pull TLF from its own repo.
>>
>>If you plan to take this on, please let us know. I'm waiting to see if
>>Infra did try again to reboot the server. If they did and the recent
>>failure means it is still busted, it is definitely time to start making
>>these changes, so one of should start on it.
>>
>>-Alex
>>
>>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>Thanks Alex.
>>>
>>>So IIUC,
>>>
>>>1) create new folder "pixel_bender" under
>>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>>> - will contain the zip files generated by the build below
>>>
>>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>>>containing:
>>> - PBK sources for flex-sdk
>>> - build file for compiling pbk into pbj
>>> Output = pb.zip file containing pbj + pbk (similar structure to
>>>current pixelbender upstream Jenkins job)
>>> [Bonus] auto-commmit the zip file to
>>>dist/.../pixel_bender
>>>
>>>=> build file must be run manually by "Release manager"
>>>
>>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>>(obsolete)
>>>
>>>4) to include pbk+pbj in Flex SDK release there are two options
>>>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>>>and unzip into dist
>>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>>
>>>Is that correct?
>>>What option in 4) I think a) is the easiest, and it does not break
>>>any Apache rule.
>>>
>>>Maurice
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>>Builds.a.o
>>>
>>>
>>>
>>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>>wrote:
>>>
>>>>I am trying to understand the steps below:
>>>>
>>>>Where would the pbk => pbj compilation take place ?
>>>In the build script for this "project".
>>>>
>>>>Where would the pbj be stored after the build , if the build does not
>>>>occur on the CI?
>>>On the same servers we store our voted on releases.
>>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>>somewhere ?
>>>All releases are compiled by someone running the build script and
>>>signing the artifacts. Apache even seems to not want to allow signing
>>>of Jenkins-built artifacts.
>>>
>>>-Alex
>>>
>>
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
>IMO, the binary package can only contain pbj's if the source package contains the source pbk's and a way to compile them.
>The binary package probably cannot contain >a zip of the pbj's either. The idea of the binary package is that it contains the result of the compilation, to save folks >having to set up the compile/build environment. >My understanding is that it cannot contain other artifacts.
You are correct.
So does this mean the pbk would be duplicated on both dist repo and flex-sdk git repo?
I don't like the idea to have duplicate source code.
Otherwise, this means the pbk would be in one single place, so necessarily in flex-sdk git repo (as is currently the case).
This implies the build file in dist would fetch the pbk sources from git,
which means cloning the whole git flex-sdk repo for 10 source files...
So it's git clone for 10 files, or duplicate source, but for files that won't change much.
WDYT?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 18:20
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>> B) I don't think I understood your 4a, but it doesn't sound like it
>>would meet policy. No zips are allowed in svn.
>
>I am confused.
> Isn't
>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/
>an svn repo?
> And it does contain zip and binaries.
>
>So if svn cannot contain zips, how do we make commit the result of pb
>compilation ? as plain files ?
Ah, I understand now. Yes, we use SVN to put things on dist. We didn't used to. When you say svn or git I think of our repos. Dist (and
archive) can have binary artifacts.
>
>My 4a) is more or less your B) => "build scripts copy the pbk source
>from dist into the source package and pbjs from dist into the binary
>package".
>Expect that I retrieve one zip file with internal directory structure
>(same as the one produced by obsolete pixel_bender Jenkins job) from
>dist and copy it to binary package, instead of individual flat files.
>I don't think this breaks any rule ..
IMO, the binary package can only contain pbj's if the source package contains the source pbk's and a way to compile them. The binary package probably cannot contain a zip of the pbj's either. The idea of the binary package is that it contains the result of the compilation, to save folks having to set up the compile/build environment. My understanding is that it cannot contain other artifacts.
>
>>If you plan to take this on, please let us know
>Not at the moment. I am just trying to detail the steps, in case it
>needs to be done later (by anyone who want to).
>Hoping the infra will fix the current issue...
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and
>Builds.a.o
>
>I agree with most of it except:
>
>A) we can't auto-commit to dist. I believe only voted on artifacts can
>go there. But realistically, I think we're only going to commit once
>unless someone find a reason to change the PBK files.
>
>B) I don't think I understood your 4a, but it doesn't sound like it
>would meet policy. No zips are allowed in svn.
>
>A binary package is only supposed to additionally contain compiled
>artifacts of the source package. I'd rather not have to change the
>installer either right now since I'm working on a major upgrade to it
>and don't want to add that to the delays to get our CI up and running again.
>I think the best short term answer is that the SDK build scripts copy
>the pbk source from dist into the source package and pbjs from dist
>into the binary package. That sort of fudges the tag==package policy
>but essentially we can show there are already multiple tags in our
>packages since we pull TLF from its own repo.
>
>If you plan to take this on, please let us know. I'm waiting to see if
>Infra did try again to reboot the server. If they did and the recent
>failure means it is still busted, it is definitely time to start making
>these changes, so one of should start on it.
>
>-Alex
>
>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Thanks Alex.
>>
>>So IIUC,
>>
>>1) create new folder "pixel_bender" under
>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>> - will contain the zip files generated by the build below
>>
>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>>containing:
>> - PBK sources for flex-sdk
>> - build file for compiling pbk into pbj
>> Output = pb.zip file containing pbj + pbk (similar structure to
>>current pixelbender upstream Jenkins job)
>> [Bonus] auto-commmit the zip file to
>>dist/.../pixel_bender
>>
>>=> build file must be run manually by "Release manager"
>>
>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>(obsolete)
>>
>>4) to include pbk+pbj in Flex SDK release there are two options
>>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>>and unzip into dist
>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>
>>Is that correct?
>>What option in 4) I think a) is the easiest, and it does not break
>>any Apache rule.
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>
>>
>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>I am trying to understand the steps below:
>>>
>>>Where would the pbk => pbj compilation take place ?
>>In the build script for this "project".
>>>
>>>Where would the pbj be stored after the build , if the build does not
>>>occur on the CI?
>>On the same servers we store our voted on releases.
>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>somewhere ?
>>All releases are compiled by someone running the build script and
>>signing the artifacts. Apache even seems to not want to allow signing
>>of Jenkins-built artifacts.
>>
>>-Alex
>>
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 9:00 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>> B) I don't think I understood your 4a, but it doesn't sound like it
>>would meet policy. No zips are allowed in svn.
>
>I am confused.
> Isn't
>https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/ an
>svn repo?
> And it does contain zip and binaries.
>
>So if svn cannot contain zips, how do we make commit the result of pb
>compilation ? as plain files ?
Ah, I understand now. Yes, we use SVN to put things on dist. We didn't
used to. When you say svn or git I think of our repos. Dist (and
archive) can have binary artifacts.
>
>My 4a) is more or less your B) => "build scripts copy the pbk source
>from dist into the source package and pbjs from dist into the binary
>package".
>Expect that I retrieve one zip file with internal directory structure
>(same as the one produced by obsolete pixel_bender Jenkins job) from dist
>and copy it to binary package, instead of individual flat files.
>I don't think this breaks any rule ..
IMO, the binary package can only contain pbj's if the source package
contains the source pbk's and a way to compile them. The binary package
probably cannot contain a zip of the pbj's either. The idea of the binary
package is that it contains the result of the compilation, to save folks
having to set up the compile/build environment. My understanding is that
it cannot contain other artifacts.
>
>>If you plan to take this on, please let us know
>Not at the moment. I am just trying to detail the steps, in case it
>needs to be done later (by anyone who want to).
>Hoping the infra will fix the current issue...
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 17:44
>À : dev@flex.apache.org
>Objet : Re: PixelBender and Builds.a.o
>
>I agree with most of it except:
>
>A) we can't auto-commit to dist. I believe only voted on artifacts can
>go there. But realistically, I think we're only going to commit once
>unless someone find a reason to change the PBK files.
>
>B) I don't think I understood your 4a, but it doesn't sound like it would
>meet policy. No zips are allowed in svn.
>
>A binary package is only supposed to additionally contain compiled
>artifacts of the source package. I'd rather not have to change the
>installer either right now since I'm working on a major upgrade to it and
>don't want to add that to the delays to get our CI up and running again.
>I think the best short term answer is that the SDK build scripts copy the
>pbk source from dist into the source package and pbjs from dist into the
>binary package. That sort of fudges the tag==package policy but
>essentially we can show there are already multiple tags in our packages
>since we pull TLF from its own repo.
>
>If you plan to take this on, please let us know. I'm waiting to see if
>Infra did try again to reboot the server. If they did and the recent
>failure means it is still busted, it is definitely time to start making
>these changes, so one of should start on it.
>
>-Alex
>
>On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Thanks Alex.
>>
>>So IIUC,
>>
>>1) create new folder "pixel_bender" under
>>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
>> - will contain the zip files generated by the build below
>>
>>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>>containing:
>> - PBK sources for flex-sdk
>> - build file for compiling pbk into pbj
>> Output = pb.zip file containing pbj + pbk (similar structure to
>>current pixelbender upstream Jenkins job)
>> [Bonus] auto-commmit the zip file to
>>dist/.../pixel_bender
>>
>>=> build file must be run manually by "Release manager"
>>
>>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>>(obsolete)
>>
>>4) to include pbk+pbj in Flex SDK release there are two options
>>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>>and unzip into dist
>>b) add checkout+checkMD5+unzip step in flex sdk installer
>>
>>Is that correct?
>>What option in 4) I think a) is the easiest, and it does not break any
>>Apache rule.
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>>Builds.a.o
>>
>>
>>
>>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>I am trying to understand the steps below:
>>>
>>>Where would the pbk => pbj compilation take place ?
>>In the build script for this "project".
>>>
>>>Where would the pbj be stored after the build , if the build does not
>>>occur on the CI?
>>On the same servers we store our voted on releases.
>>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>>somewhere ?
>>All releases are compiled by someone running the build script and
>>signing the artifacts. Apache even seems to not want to allow signing
>>of Jenkins-built artifacts.
>>
>>-Alex
>>
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
> B) I don't think I understood your 4a, but it doesn't sound like it would meet policy. No zips are allowed in svn.
I am confused.
Isn't https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/ an svn repo?
And it does contain zip and binaries.
So if svn cannot contain zips, how do we make commit the result of pb compilation ? as plain files ?
My 4a) is more or less your B) => "build scripts copy the pbk source from dist into the source package and pbjs from dist into the binary package".
Expect that I retrieve one zip file with internal directory structure (same as the one produced by obsolete pixel_bender Jenkins job) from dist and copy it to binary package, instead of individual flat files.
I don't think this breaks any rule ..
>If you plan to take this on, please let us know
Not at the moment. I am just trying to detail the steps, in case it needs to be done later (by anyone who want to).
Hoping the infra will fix the current issue...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 17:44
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
I agree with most of it except:
A) we can't auto-commit to dist. I believe only voted on artifacts can go there. But realistically, I think we're only going to commit once unless someone find a reason to change the PBK files.
B) I don't think I understood your 4a, but it doesn't sound like it would meet policy. No zips are allowed in svn.
A binary package is only supposed to additionally contain compiled artifacts of the source package. I'd rather not have to change the installer either right now since I'm working on a major upgrade to it and don't want to add that to the delays to get our CI up and running again.
I think the best short term answer is that the SDK build scripts copy the pbk source from dist into the source package and pbjs from dist into the binary package. That sort of fudges the tag==package policy but essentially we can show there are already multiple tags in our packages since we pull TLF from its own repo.
If you plan to take this on, please let us know. I'm waiting to see if Infra did try again to reboot the server. If they did and the recent failure means it is still busted, it is definitely time to start making these changes, so one of should start on it.
-Alex
On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Thanks Alex.
>
>So IIUC,
>
>1) create new folder "pixel_bender" under
>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
> - will contain the zip files generated by the build below
>
>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>containing:
> - PBK sources for flex-sdk
> - build file for compiling pbk into pbj
> Output = pb.zip file containing pbj + pbk (similar structure to
>current pixelbender upstream Jenkins job)
> [Bonus] auto-commmit the zip file to
>dist/.../pixel_bender
>
>=> build file must be run manually by "Release manager"
>
>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins
>(obsolete)
>
>4) to include pbk+pbj in Flex SDK release there are two options
>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>and unzip into dist
>b) add checkout+checkMD5+unzip step in flex sdk installer
>
>Is that correct?
>What option in 4) I think a) is the easiest, and it does not break any
>Apache rule.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and
>Builds.a.o
>
>
>
>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>I am trying to understand the steps below:
>>
>>Where would the pbk => pbj compilation take place ?
>In the build script for this "project".
>>
>>Where would the pbj be stored after the build , if the build does not
>>occur on the CI?
>On the same servers we store our voted on releases.
>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>somewhere ?
>All releases are compiled by someone running the build script and
>signing the artifacts. Apache even seems to not want to allow signing
>of Jenkins-built artifacts.
>
>-Alex
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
I agree with most of it except:
A) we can't auto-commit to dist. I believe only voted on artifacts can go
there. But realistically, I think we're only going to commit once unless
someone find a reason to change the PBK files.
B) I don't think I understood your 4a, but it doesn't sound like it would
meet policy. No zips are allowed in svn.
A binary package is only supposed to additionally contain compiled
artifacts of the source package. I'd rather not have to change the
installer either right now since I'm working on a major upgrade to it and
don't want to add that to the delays to get our CI up and running again.
I think the best short term answer is that the SDK build scripts copy the
pbk source from dist into the source package and pbjs from dist into the
binary package. That sort of fudges the tag==package policy but
essentially we can show there are already multiple tags in our packages
since we pull TLF from its own repo.
If you plan to take this on, please let us know. I'm waiting to see if
Infra did try again to reboot the server. If they did and the recent
failure means it is still busted, it is definitely time to start making
these changes, so one of should start on it.
-Alex
On 12/12/13 8:27 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Thanks Alex.
>
>So IIUC,
>
>1) create new folder "pixel_bender" under
>https://dist.apache.org/repos/dist/dev/flex/ SVN repo
> - will contain the zip files generated by the build below
>
>2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo
>containing:
> - PBK sources for flex-sdk
> - build file for compiling pbk into pbj
> Output = pb.zip file containing pbj + pbk (similar structure to current
>pixelbender upstream Jenkins job)
> [Bonus] auto-commmit the zip file to dist/.../pixel_bender
>
>=> build file must be run manually by "Release manager"
>
>3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins (obsolete)
>
>4) to include pbk+pbj in Flex SDK release there are two options
>a) modify build_release.sh (or equivalent) to checkout pb.zip from svn
>and unzip into dist
>b) add checkout+checkMD5+unzip step in flex sdk installer
>
>Is that correct?
>What option in 4) I think a) is the easiest, and it does not break any
>Apache rule.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 15:40
>À : dev@flex.apache.org
>Objet : Re: PixelBender and Builds.a.o
>
>
>
>On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>I am trying to understand the steps below:
>>
>>Where would the pbk => pbj compilation take place ?
>In the build script for this "project".
>>
>>Where would the pbj be stored after the build , if the build does not
>>occur on the CI?
>On the same servers we store our voted on releases.
>>Will the pbj be compiled by Jenkins ? or built manually and stored
>>somewhere ?
>All releases are compiled by someone running the build script and signing
>the artifacts. Apache even seems to not want to allow signing of
>Jenkins-built artifacts.
>
>-Alex
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
Thanks Alex.
So IIUC,
1) create new folder "pixel_bender" under https://dist.apache.org/repos/dist/dev/flex/ SVN repo
- will contain the zip files generated by the build below
2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo containing:
- PBK sources for flex-sdk
- build file for compiling pbk into pbj
Output = pb.zip file containing pbj + pbk (similar structure to current pixelbender upstream Jenkins job)
[Bonus] auto-commmit the zip file to dist/.../pixel_bender
=> build file must be run manually by "Release manager"
3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins (obsolete)
4) to include pbk+pbj in Flex SDK release there are two options
a) modify build_release.sh (or equivalent) to checkout pb.zip from svn and unzip into dist
b) add checkout+checkMD5+unzip step in flex sdk installer
Is that correct?
What option in 4) I think a) is the easiest, and it does not break any Apache rule.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 15:40
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>I am trying to understand the steps below:
>
>Where would the pbk => pbj compilation take place ?
In the build script for this "project".
>
>Where would the pbj be stored after the build , if the build does not
>occur on the CI?
On the same servers we store our voted on releases.
>Will the pbj be compiled by Jenkins ? or built manually and stored
>somewhere ?
All releases are compiled by someone running the build script and signing the artifacts. Apache even seems to not want to allow signing of Jenkins-built artifacts.
-Alex
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
On 12/12/13 5:03 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>I am trying to understand the steps below:
>
>Where would the pbk => pbj compilation take place ?
In the build script for this "project".
>
>Where would the pbj be stored after the build , if the build does not
>occur on the CI?
On the same servers we store our voted on releases.
>Will the pbj be compiled by Jenkins ? or built manually and stored
>somewhere ?
All releases are compiled by someone running the build script and signing
the artifacts. Apache even seems to not want to allow signing of
Jenkins-built artifacts.
-Alex
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
I am trying to understand the steps below:
Where would the pbk => pbj compilation take place ?
Where would the pbj be stored after the build , if the build does not occur on the CI?
Will the pbj be compiled by Jenkins ? or built manually and stored somewhere ?
Thanks,
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : mercredi 11 décembre 2013 22:49
À : dev@flex.apache.org
Objet : Re: PixelBender and Builds.a.o
It is probably worth waiting for response from Justin.
Any volunteers to do the work? I think the steps are:
1) copy the pbk files somewhere (flex-utilities repo?)
2) setup build for them
3) create release candidate
4) hold vote.
5) put up candidates on dist
6) change the sdk builds to use the packages on dist
-Alex
On 12/11/13 1:02 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Agree with the upstream package. Sounds like a good solution, and
>rather easy to put in place.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11 décembre
>2013 20:10 À : dev@flex.apache.org Objet : PixelBender and Builds.a.o
>
>Thanks to Maurice, we have a pretty good idea of why Jenkins on
>builds.a.o is not able to build the Flex SDK. Unfortunately, it isn't
>clear that infra knows how to fix it or can fix it given how they want
>to run that server.
>
>Meanwhile, I'm still trying to get access to the PB compiler source,
>but one person I talked to said that Alchemy-based shaders will
>outperform PB shaders. So, one potential way to solve this problem is
>to replace our shaders with Alchemy shaders. I have no idea how hard that would be.
>Anybody think they can do it quickly?
>
>Another option, which is a variant of what Maurice was proposing
>yesterday is that we quickly create an official release package that
>contains just the PBK files. Then the corresponding convenience binary
>package would have the PBJ files. We call this an upstream package
>that only is supported on Mac and Win. We would not use CI for this release.
>
>Then we adjust the SDK build to use this upstream package. This is
>make more official the workaround we are using for Linux and bring
>Linux up to par with Mac and Win. Yes, the installer has to change as
>well, but hopefully I'll have new installer capability ready shortly
>anyway that should make it easier for us to make these changes.
>
>Thoughts?
>-Alex
>
Re: PixelBender and Builds.a.o
Posted by Alex Harui <ah...@adobe.com>.
It is probably worth waiting for response from Justin.
Any volunteers to do the work? I think the steps are:
1) copy the pbk files somewhere (flex-utilities repo?)
2) setup build for them
3) create release candidate
4) hold vote.
5) put up candidates on dist
6) change the sdk builds to use the packages on dist
-Alex
On 12/11/13 1:02 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Agree with the upstream package. Sounds like a good solution, and rather
>easy to put in place.
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : mercredi 11 décembre 2013 20:10
>À : dev@flex.apache.org
>Objet : PixelBender and Builds.a.o
>
>Thanks to Maurice, we have a pretty good idea of why Jenkins on
>builds.a.o is not able to build the Flex SDK. Unfortunately, it isn't
>clear that infra knows how to fix it or can fix it given how they want to
>run that server.
>
>Meanwhile, I'm still trying to get access to the PB compiler source, but
>one person I talked to said that Alchemy-based shaders will outperform PB
>shaders. So, one potential way to solve this problem is to replace our
>shaders with Alchemy shaders. I have no idea how hard that would be.
>Anybody think they can do it quickly?
>
>Another option, which is a variant of what Maurice was proposing
>yesterday is that we quickly create an official release package that
>contains just the PBK files. Then the corresponding convenience binary
>package would have the PBJ files. We call this an upstream package that
>only is supported on Mac and Win. We would not use CI for this release.
>
>Then we adjust the SDK build to use this upstream package. This is make
>more official the workaround we are using for Linux and bring Linux up to
>par with Mac and Win. Yes, the installer has to change as well, but
>hopefully I'll have new installer capability ready shortly anyway that
>should make it easier for us to make these changes.
>
>Thoughts?
>-Alex
>
RE: PixelBender and Builds.a.o
Posted by Maurice Amsellem <ma...@systar.com>.
Agree with the upstream package. Sounds like a good solution, and rather easy to put in place.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : mercredi 11 décembre 2013 20:10
À : dev@flex.apache.org
Objet : PixelBender and Builds.a.o
Thanks to Maurice, we have a pretty good idea of why Jenkins on builds.a.o is not able to build the Flex SDK. Unfortunately, it isn't clear that infra knows how to fix it or can fix it given how they want to run that server.
Meanwhile, I'm still trying to get access to the PB compiler source, but one person I talked to said that Alchemy-based shaders will outperform PB shaders. So, one potential way to solve this problem is to replace our shaders with Alchemy shaders. I have no idea how hard that would be.
Anybody think they can do it quickly?
Another option, which is a variant of what Maurice was proposing yesterday is that we quickly create an official release package that contains just the PBK files. Then the corresponding convenience binary package would have the PBJ files. We call this an upstream package that only is supported on Mac and Win. We would not use CI for this release.
Then we adjust the SDK build to use this upstream package. This is make more official the workaround we are using for Linux and bring Linux up to par with Mac and Win. Yes, the installer has to change as well, but hopefully I'll have new installer capability ready shortly anyway that should make it easier for us to make these changes.
Thoughts?
-Alex