>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:aha...@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" <maurice.amsel...@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:aha...@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" <maurice.amsel...@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:aha...@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" <maurice.amsel...@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:aha...@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" <maurice.amsel...@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 >>> >> >
