On Tue, Dec 10, 2013 at 9:48 AM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> I think he has the same MSDN as me, which should give him enough > 'credits' to run a medium sized VM for ever... I currently run the > Mustella VM as a large instance for about half a month, then switch it > to medium for the remainder. A bit of a hassle, but worth it to run > Mustella smoothly, I think. A 'regular' Jenkins server should run > perfectly fine on a medium instance. > > EdB > > Yes, that is correct. All Apache committers get a free MSDN subscription [1] which is supposed to be used for the benefit of Apache projects. A monthly credit for Windows Azure VMs comes with this subscription. My goal is to create a clone-able public image which has everything needed to run Mustella builds that each committer can instantiate and deploy. I want to make this whole process as simple as possible so that we can get as many committers' VMs up and running in no time. After that we will have one master Jenkins and set up all other VMs as slaves. This way, we can first distribute VMs to do runs of various FP/AIR combinations. And then eventually, break down Mustella tests into various sections and have each slave run a subset, in order to reduce the time taken for each Mustella run. And we need to dedicate a VM specifically for building the SDK (that Erik wanted) so as to reduce our dependence on bui...@apache.org. I need a volunteer committer to help test out and document this process. Any takers? Thanks, Om [1] https://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html > > > On Tue, Dec 10, 2013 at 6:14 PM, Alex Harui <aha...@adobe.com> wrote: > > I don't think we actually know the cause of the problem. I am going to > > continue to spend cycles to try to find out though. > > > > It would be nice to have an alternative to builds.a.o. I'm not sure if > it > > will cost Om money to run a builds server. > > > > -Alex > > > > On 12/10/13 2:01 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> > > wrote: > > > >>I understand that. > >> > >>Actually, my "understanding" on this issue was that pixel bender compiler > >>required some sort of hardware configuration (OpenGL, etc...) that were > >>not present on the b.a.o. new Windows Jenkins slave node, so that's why > >>the build was failing, and the Apache Infra was reluctant to let us > >>modify anything, or even access the VM ourselves. > >>So that's why I was proposing a "software only" solution. > >> > >>Now, it seems from what Om is saying that we can set up and use our own > >>Jenkins slave node VM. > >> > >>That, of course, is much preferable... > >> > >>Maurice > >> > >>-----Message d'origine----- > >>De : Erik de Bruin [mailto:e...@ixsoftware.nl] > >>Envoyé : mardi 10 décembre 2013 10:44 > >>À : dev@flex.apache.org > >>Objet : Re: [Builds/Jenkins] Help and advise needed > >> > >>Maurice, > >> > >>Your help is very much appreciated! > >> > >>I put "legal" in quotes, the issue is not really one of the law, more of > >>the rules. An Apache release is supposed to be 'source only', and we if > >>we can produce needed binaries from source, we keep only the source, not > >>the artefacts themselves in the repo. > >> > >> > >>EdB > >> > >> > >> > >>On Tue, Dec 10, 2013 at 10:34 AM, Maurice Amsellem > >><maurice.amsel...@systar.com> wrote: > >>>>In addition to the various "legal" issues with binaries in the repo. > >>> I understand it's not a good idea to have binaries in the repo, so I > >>>won't insist. > >>> But please can you explain what are the legal issues of having binaries > >>>in the repo? Is this because of Adobe, or ASF rules ? > >>> > >>> On a side note, I was just trying to help, with my limited > >>> understanding and knowledge, and because the email thread was titled > >>> "help and advise needed" ;-) > >>> > >>> Regards, > >>> > >>> Maurice > >>> > >>> -----Message d'origine----- > >>> De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 10 > >>> décembre 2013 09:12 À : dev@flex.apache.org Objet : Re: > >>> [Builds/Jenkins] Help and advise needed > >>> > >>> In addition to the various "legal" issues with binaries in the repo, > >>>we'd be masking the cause of this failure. In order to prevent further > >>>deterioration of the build process, we need to figure out what went > >>>wrong and fix it. > >>> > >>> EdB > >>> > >>> PS. Thanks for leaving the keyboard on the Mustella VM set to FR... > >>> Took me while to figure out that I hadn't gone insane or if my > >>> keyboard was broken ;-) > >>> > >>> > >>> > >>> On Tue, Dec 10, 2013 at 9:04 AM, Maurice Amsellem > >>><maurice.amsel...@systar.com> wrote: > >>>>> someone who does use the pbj's will grab the nightly and complain. > >>>> > >>>> I don't understand. > >>>> Why would someone complain if the pbj's are in the nightly? > >>>> > >>>> [From the other emai] > >>>>>Apache repos aren't supposed to contain compiled code. The pbj files > >>>>>were removed during the initial release audit. > >>>>>I don't think a workaround can involve checking in the pbj files. But > >>>>>we could borrow them from a prior release package temporarily. > >>>> > >>>>>So we could make the compilation conditional on a env parameter, and > >>>>>set that in the Jenkins job accordingly? > >>>>>Yes but ... > >>>> > >>>> Alex, the conversation is getting out synch, so I am not sure that I > >>>>have understood what you said. > >>>> > >>>> So can we include the pbj in the repo, and have a parameter to > >>>>conditionally compile the pbj ? > >>>> - This parameter would be set by default to do the compilation (so > >>>> that folks can recompile) > >>>> - and turned off on the b.a.o vm, with pre-compiled pbj's. > >>>> > >>>> > >>>> Maurice > >>>> > >>> > >>> > >>> > >>> -- > >>> Ix Multimedia Software > >>> > >>> Jan Luykenstraat 27 > >>> 3521 VB Utrecht > >>> > >>> T. 06-51952295 > >>> I. www.ixsoftware.nl > >> > >> > >> > >>-- > >>Ix Multimedia Software > >> > >>Jan Luykenstraat 27 > >>3521 VB Utrecht > >> > >>T. 06-51952295 > >>I. www.ixsoftware.nl > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
