Re: Flex PMD donation
Hi, >> Regarding the release ... I would be willing to step up as Release Manager >> for FlexUnit, BlazeDS, Mavenizer and as soon as it's ready FlexPMD. I'd try one at a time :-) >> My new Employer grants me one working day per week Nice - more employers should allow that. Thanks, Justin
Re: Flex PMD donation
> Regarding the release ... I would be willing to step up as Release Manager > for FlexUnit, BlazeDS, Mavenizer and as soon as it's ready FlexPMD. My new > Employer grants me one working day per week for stuff like this and I would > be glad to do so. > > This is awesome news, Chris! Thanks, Om > Chris > > > Von: Justin Mclean > Gesendet: Mittwoch, 27. August 2014 04:23 > An: dev@flex.apache.org > Betreff: Re: Flex PMD donation > > Hi, > > > I updated the structure to be more intuitive. Updated to Flexmojos > 7.1.0-SNAPSHOT, Apache Flex 4.13.0, Apache FlexUnit 4.2, ... > Thanks - hopefully we can get it working. > > > It was quite a lot of work and a big number of Tests will definitely > fail, > I've fixed a few of those and will check in once I can get teh new > structure working. > > > You need a few jars manually deployed as well as Flex 4.13.0 created by > the Mavenizer (mavenizer-refactoring branch). > Are the step by step instructions on how to do this? > > I would of guessed that this: > java -cp ./target/flex-sdk-converter-1.0.0-SNAPSHOT.jar SDKGenerator > $FLEX_HOME ~/.m2 true > > Would mavinise a SDK and place in to my local repo but (obviously) I don't > really know what I'm doing. > > Currently when trying to build FlexPMD I get: > [ERROR] Unresolveable build extension: Plugin > net.flexmojos.oss:flexmojos-maven-plugin:7.1.0-SNAPSHOT or one of its > dependencies could not be resolved: The following artifacts could not be > resolved: net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT, > net.flexmojos.oss:flexmojos-threadlocaltoolkit-wrapper:jar:7.1.0-SNAPSHOT, > org.apache.flex:compiler:pom:4.13.0.20140701: Could not find artifact > net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT -> [Help 2] > [ERROR] Unknown packaging: swc @ line 29, column 13 > > > We have so much stuff in a pending state ... finally starting to release > our stuff would make things so much easier. > For that we need people willing to fix this stuff up and someone to be a > release manager. > > Thanks, > Justin >
AW: Flex PMD donation
Hi Alex, well I wrote such a step-by-step tutorial .. it should be in our Wiki: https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+SDK+Mavenizer But seems you have successfully mavenized Flex. The problem is that I haven't released Flexmojos 7.1 yet so you need to add the sonatype snapshot repo: https://oss.sonatype.org/content/repositories/snapshots Probably it would be better for me to release 7.1 and to target implementing the final changes to 7.2. Regarding the release ... I would be willing to step up as Release Manager for FlexUnit, BlazeDS, Mavenizer and as soon as it's ready FlexPMD. My new Employer grants me one working day per week for stuff like this and I would be glad to do so. Chris Von: Justin Mclean Gesendet: Mittwoch, 27. August 2014 04:23 An: dev@flex.apache.org Betreff: Re: Flex PMD donation Hi, > I updated the structure to be more intuitive. Updated to Flexmojos > 7.1.0-SNAPSHOT, Apache Flex 4.13.0, Apache FlexUnit 4.2, ... Thanks - hopefully we can get it working. > It was quite a lot of work and a big number of Tests will definitely fail, I've fixed a few of those and will check in once I can get teh new structure working. > You need a few jars manually deployed as well as Flex 4.13.0 created by the > Mavenizer (mavenizer-refactoring branch). Are the step by step instructions on how to do this? I would of guessed that this: java -cp ./target/flex-sdk-converter-1.0.0-SNAPSHOT.jar SDKGenerator $FLEX_HOME ~/.m2 true Would mavinise a SDK and place in to my local repo but (obviously) I don't really know what I'm doing. Currently when trying to build FlexPMD I get: [ERROR] Unresolveable build extension: Plugin net.flexmojos.oss:flexmojos-maven-plugin:7.1.0-SNAPSHOT or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT, net.flexmojos.oss:flexmojos-threadlocaltoolkit-wrapper:jar:7.1.0-SNAPSHOT, org.apache.flex:compiler:pom:4.13.0.20140701: Could not find artifact net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT -> [Help 2] [ERROR] Unknown packaging: swc @ line 29, column 13 > We have so much stuff in a pending state ... finally starting to release our > stuff would make things so much easier. For that we need people willing to fix this stuff up and someone to be a release manager. Thanks, Justin
Re: Reason for the release process
Hi, > Keep in mind that we may not be able to do this for 3rd party component > developers. Because we want to hotlink to their examples and code > directly, we may not be able to 'build' a release from our side. > > I propose that we create a new thirdparty.xml and allow direct editing of > the file on the site so that 3rd party content will show up immediately > without having to go through a release process. Created an issue in JIRA for this: https://issues.apache.org/jira/browse/FLEX-34501 Justin
Re: OSMF bugs
Hi, Don't really care if it's part of our project or not, but as it's an optional part of installing the SDK it would be good to have it at Apache. Justin
Re: OSMF bugs
Oh I definitely think it's something to have aYo www.ayobinitie.com mrbinitie.blogspot.com On Aug 27, 2014 5:01 AM, "Alex Harui" wrote: > Don't know anything about OSMF. Would we want it, or would it be a > separate Apache project. Seems like it has its own community already? > > I'll try to figure out who is in charge at Adobe. > > -Alex > > On 8/26/14 7:42 PM, "Justin Mclean" wrote: > > >Hi, > > > >I notice that recent bugs in Adobe bug base on OSMF have been closed with > >"NotEnoughTime" as the reason. Does any one know if Adobe has considered > >donating the framework to Apache and f not could we make that happen? > > > >Thanks, > >Justin > >
Re: Reason for the release process
On 8/26/14 7:56 PM, "Justin Mclean" wrote: > >This is also one other subtle issue I've just released. If we don't use >the standard release process, then as per CTR -1 counts as a veto >effectually blocking a release. Do we want to do there? Well, it blocks that commit, just like a -1 blocks any other commit. Each commit would normally not be tons of files at a time, probably just one or two, so it wouldn't really block something of release proportions. -ALex
Re: OSMF bugs
Don't know anything about OSMF. Would we want it, or would it be a separate Apache project. Seems like it has its own community already? I'll try to figure out who is in charge at Adobe. -Alex On 8/26/14 7:42 PM, "Justin Mclean" wrote: >Hi, > >I notice that recent bugs in Adobe bug base on OSMF have been closed with >"NotEnoughTime" as the reason. Does any one know if Adobe has considered >donating the framework to Apache and f not could we make that happen? > >Thanks, >Justin
Re: Reason for the release process
HI, > Unless I get some support from others, we'll be doing it the way you want. OK, thanks. This is also one other subtle issue I've just released. If we don't use the standard release process, then as per CTR -1 counts as a veto effectually blocking a release. Do we want to do there? Thanks, Justin
OSMF bugs
Hi, I notice that recent bugs in Adobe bug base on OSMF have been closed with "NotEnoughTime" as the reason. Does any one know if Adobe has considered donating the framework to Apache and f not could we make that happen? Thanks, Justin
Re: Flex PMD donation
Hi, > I updated the structure to be more intuitive. Updated to Flexmojos > 7.1.0-SNAPSHOT, Apache Flex 4.13.0, Apache FlexUnit 4.2, ... Thanks - hopefully we can get it working. > It was quite a lot of work and a big number of Tests will definitely fail, I've fixed a few of those and will check in once I can get teh new structure working. > You need a few jars manually deployed as well as Flex 4.13.0 created by the > Mavenizer (mavenizer-refactoring branch). Are the step by step instructions on how to do this? I would of guessed that this: java -cp ./target/flex-sdk-converter-1.0.0-SNAPSHOT.jar SDKGenerator $FLEX_HOME ~/.m2 true Would mavinise a SDK and place in to my local repo but (obviously) I don't really know what I'm doing. Currently when trying to build FlexPMD I get: [ERROR] Unresolveable build extension: Plugin net.flexmojos.oss:flexmojos-maven-plugin:7.1.0-SNAPSHOT or one of its dependencies could not be resolved: The following artifacts could not be resolved: net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT, net.flexmojos.oss:flexmojos-threadlocaltoolkit-wrapper:jar:7.1.0-SNAPSHOT, org.apache.flex:compiler:pom:4.13.0.20140701: Could not find artifact net.flexmojos.oss:flexmojos-maven-plugin:jar:7.1.0-SNAPSHOT -> [Help 2] [ERROR] Unknown packaging: swc @ line 29, column 13 > We have so much stuff in a pending state ... finally starting to release our > stuff would make things so much easier. For that we need people willing to fix this stuff up and someone to be a release manager. Thanks, Justin
Re: Agreeing to Disagree (was: Re: The Flex PMC isŠ)
Hi, > The rest of the PMC seems to agree with me that Justin has had ample time to > make his > case, and we are not convinced, and therefore it is time to end the > discussion, agree to disagree, and move on. Given people don't know the context or have access to that list I think it only fair the say that a few vocal people disagreed with me, the majority of the PMC was silent on these issues and I did receive support for some of my views and in some cases we can agree to disagree. Thanks, Justin
Re: [Off Topic] Actionscipt and tiobe index
Hi, > I think it means it drops a few ranks, the fluctuation is expectable though. A few months back it wasn't in the top 20 and hadn't been for some time. Thanks, Justin
Re: [Off Topic] Actionscipt and tiobe index
I think it means it drops a few ranks, the fluctuation is expectable though. On Aug 25, 2014 11:04 PM, "Justin Mclean" wrote: > Hi, > > Just noticed ActionScript has climbed a few more spots in the Tiobe index > and is now at 17. [1] Was was actually 14 in June! Here's the graph [2]. I > certainly won't claim this is a scientific measurement in any way but is > still interesting to note. > > Thanks, > Justin > > 1. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html > 2. http://www.tiobe.com/index.php/content/paperinfo/tpci/ActionScript.html
Re: Reason for the release process
On 8/26/14 4:34 PM, "Justin Mclean" wrote: >Hi, > >> Agreed, TDF might attract a new pool of developers. We are just >> disagreeing on what the best way of attracting them is. I think trying >>to >> attracting them by asking them to do manual testing is not as attractive >> as asking them to provide TDF fixes. > >1. So manually testing is: >- compiling the release candidates >- running it >- if you find an issue report it in JIRA > >2. Fixing is: >- Setting up git and getting our repo >- compiling the code >- running it >- finding an issue >- Tying to find out what causes the issue >- Recompile and change code a few times until issue is fixed or give up >as you can't fix it >- Creating a patch file >- Reporting it in JIRA > >Which sounds harder? If someone does 1, other people with different >skills get to see and hopefully help up. If we insist on 2, then only >people who mange to fix stuff will report it. That's not a valid argument. Folks don't need the repo to offer a patch for TDF. All of the source is right there! Anyway, at this point I think I have made my case. It is compliant with Apache policy. We are currently applying a different set of rules for Badge Installer, but that should probably be a different thread. Time to agree to disagree. Unless I get some support from others, we'll be doing it the way you want. -Alex
Re: Reason for the release process
Hi, > Agreed, TDF might attract a new pool of developers. We are just > disagreeing on what the best way of attracting them is. I think trying to > attracting them by asking them to do manual testing is not as attractive > as asking them to provide TDF fixes. 1. So manually testing is: - compiling the release candidates - running it - if you find an issue report it in JIRA 2. Fixing is: - Setting up git and getting our repo - compiling the code - running it - finding an issue - Tying to find out what causes the issue - Recompile and change code a few times until issue is fixed or give up as you can't fix it - Creating a patch file - Reporting it in JIRA Which sounds harder? If someone does 1, other people with different skills get to see and hopefully help up. If we insist on 2, then only people who mange to fix stuff will report it. Justin
Re: Reason for the release process
Hi, > I know it seems clear to you, but other incubator folks disagree with you. Two people suggesting you could possibly release it as snapshop is not exactly the same thing as disagreeing with me. > If the explorer.xml was not compiled in, flexicious's examples would be > hooked up by now. There are a few minor issues we still need to sort out there (see my other email) and someone would need to do the work. Justin
Re: Reason for the release process
On 8/26/14 4:04 PM, "Justin Mclean" wrote: >No, you can't announce / promote nightly build/snapshots [1]. >" Do not include any links on the project website that might encourage >non-developers to download and use nightly builds, snapshots, release >candidates, or any other similar package." > >So That would mean we would need to remove all links from navigation in >the web site? I would even argue that "use" in this content meant put up >content to view on our web site. > >White you're at that link you might also note: >"Releases are, by definition, anything that is published beyond the group >that owns it. In our case, that means any publication outside the group >of people on the product dev list." >"Each PMC must obey the ASF requirements on approving any release." >"Proper release management is a key aspect of Apache software >development." > >This really seams quite clear cut to me. I know it seems clear to you, but other incubator folks disagree with you. Under your interpretation we'll have to run a vote for the badge installer as well. I don't believe we've done that. > >> IMO, having a bug up there for 3 days is a worse quality perception than >> fixing in minutes. > >I'm not seeing those bugs being fixed in minutes. Are you putting your >hand up for that role? If the explorer.xml was not compiled in, flexicious's examples would be hooked up by now. > >>> - Less reason for community to be involved (no RCs to test or vote on) >> Most folks I know want to write code instead of run manual tests. > >Not everyone has the skills or motivation to fix issues in the SDK (or >testing the SDK eg mustella is part of that). Let's try and widen our >talent pool a little and get a few more people involved and use to the >Apache way of doing things. Agreed, TDF might attract a new pool of developers. We are just disagreeing on what the best way of attracting them is. I think trying to attracting them by asking them to do manual testing is not as attractive as asking them to provide TDF fixes. > >>> - No need for a release manager or in fact any further releases >> True, that's another time saving we could spend elsewhere. > >Really? In that case why don't we just move the project to github, that >way we can get rid of all this unnecessary Apache process. :-) Alex as >you know this process is here for a very good reasons and as a PMC member >and the PMC chair you should be promoting it's use, not trying to find >ways to avoid using it. Nobody on the incubator except you seems to think my proposal does not align with the Apache Way. -ALex
Re: Reason for the release process
Hi, > I think it would have been much more rewarding > to the person offering the 3rd party links if we could have hooked him up > yesterday. I'm not sure that they are currently in a form that can be used in the application and we would need to change the application to make it clear in the application that it is not endorsement - as discussed. Happy to continue that conversation and work with them to get it included along with any other 3rd party who want to be in the application. > Justin switched to embedding XML to avoid a potential trust file issue > when running locally, but I think as soon as you hit the next swf you'll > get the same issue. Not correct, The trust file issue only related to how the XML was previously loaded. The swfs load fine locally even when the location is not trusted. Thanks, Justin
Re: Reason for the release process
On Tue, Aug 26, 2014 at 4:00 PM, Alex Harui wrote: > > > On 8/26/14 3:31 PM, "OmPrakash Muppirala" wrote: > > >On Tue, Aug 26, 2014 at 3:24 PM, Alex Harui wrote: > > > >>I don't believe my proposal is the "wrong way", just another alternative. > >> > > > >I think your way would lead to confusion. Let's try to avoid that. > What kind of confusion? > > Everything Justin listed. Most importantly, the binary artifact on the website being different from the released source package. If someone decides to create a branch and we end up creating a swf from that branch by mistake, it becomes even more complicated. > >> In fact, we already approved one tweak when we added analytics to > >> the landing page. Where are you drawing the line? > >> > > > >I would say the line is when we compile a swf with the code in the repo, > >we > >need to make an official release. If we are hot linking, i.e. we don't > >have the source for an example, we don't need to go through the release > >process. Same way as the Installer. If we know that a dependency has > >changed, we just change it in the installer config xml and push the site. > >If we need to change the Installer itself, we go through a release > >process. > The installer is different because people download it and run it. > Everytime someone comes to the flex.apache.org/tourdeflex page, they are essentially downloading and running it, albeit via the browser. > Although there is a nightly installer build for Windows available. > An update to installer config xml does not trigger a new build. In any case, I don't see how this relevant. > > Related: Are you in favor of going back to loading explorer.xml? Right > now it is compiled into explorer.swf so in order to point to the 3rd party > content we need to re-compile explorer.mxml and under your preferences, go > through another release. I think it would have been much more rewarding > to the person offering the 3rd party links if we could have hooked him up > yesterday. > I want to separate explorer.xml and thirdparty.xml. exploerer.xml can get embedded, but thirdparty.xml will have to be downloaded everytime, preferably should be non-cacheable by the browser. > > Justin switched to embedding XML to avoid a potential trust file issue > when running locally, but I think as soon as you hit the next swf you'll > get the same issue. We should just document in the release notes that you > have to set up a trust file, and maybe add a global exception handler that > says "Hey, you need to set up a trust file". > We have the same issue with the Installer badge. We employ a simple technique to avoid this issue when running locally. Perhaps we should build an AIR based shell of TourDeFlex and avoid using a browser when running locally. > > > > >And in some cases where we need to make minor changes (like the Google > >Analytics hook), we can quickly take a [LAZY] vote to see if there are > >objections. > IMO, no vote is needed prior. It is just a commit and folks can veto. > I am fine with that. Thanks, Om > > -Alex > >
Re: Reason for the release process
Hi, > I would say the line is when we compile a swf with the code in the repo, we > need to make an official release. +1 to that. > If we are hot linking, i.e. we don't have the source for an example, we > don't need to go through the release > process. Same way as the Installer. +1 Seems reasonable to me. > And in some cases where we need to make minor changes (like the Google > Analytics hook), we can quickly take a [LAZY] vote to see if there are > objections. +1 as changes to HTML shell that host the app are really part of the web site not the application itself. No need for a [LAZY] IMO as the checkin can be veto if needed as we use a CTR process, but no objections. Thanks, Justin
Re: Reason for the release process
Hi, > I'm not sure extra process invites community building. It already has, we've had people report issues during the RC process. >> - PMC endorsement > What are the benefits of that. Are you claiming more people will use it > if endorsed? I would say more people would use an official voted on release than a nightly build yes. >> - Legal angle covered (IP issues etc) > No more dangerous than any other nightly build. Expect that it is live on our web site for all users to see, not something available to only people who know where to get nightly builds. > Seemed like more folks waited until announced instead of helping with the RC. There was involvement in the RC by committers and non committers during the RC process, not sure why you are ignoring that. > I'd rather submit a few patches to the examples than test the RC. > Seems like that's the pattern we see from other folks too. I see you've not submitted a patch to TourDeFlex yet. Testing RCs is useful and find issues, there have been many time if we had just shipped it without an RC process there are issues that would of not been discovered and would of been harder to fix once released. That doesn't mean we find everything. > Can we not blog that some new example was added to the TDF on the site? No, you can't announce / promote nightly build/snapshots [1]. " Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package." So That would mean we would need to remove all links from navigation in the web site? I would even argue that "use" in this content meant put up content to view on our web site. White you're at that link you might also note: "Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list." "Each PMC must obey the ASF requirements on approving any release." "Proper release management is a key aspect of Apache software development." This really seams quite clear cut to me. > IMO, having a bug up there for 3 days is a worse quality perception than > fixing in minutes. I'm not seeing those bugs being fixed in minutes. Are you putting your hand up for that role? >> - Less reason for community to be involved (no RCs to test or vote on) > Most folks I know want to write code instead of run manual tests. Not everyone has the skills or motivation to fix issues in the SDK (or testing the SDK eg mustella is part of that). Let's try and widen our talent pool a little and get a few more people involved and use to the Apache way of doing things. >> - No need for a release manager or in fact any further releases > True, that's another time saving we could spend elsewhere. Really? In that case why don't we just move the project to github, that way we can get rid of all this unnecessary Apache process. :-) Alex as you know this process is here for a very good reasons and as a PMC member and the PMC chair you should be promoting it's use, not trying to find ways to avoid using it. > We'll see what others think. I'd rather just save the time. I don't get > why we need to have 3 people look at simple changes before they go on the > site. We're talking about code changes here, yes the application is simple, but that doesn't mean that it's exempt from the release process and there are very good reason to use that process. Thanks, Justin 1. http://www.apache.org/dev/release.html
Re: Reason for the release process
On 8/26/14 3:31 PM, "OmPrakash Muppirala" wrote: >On Tue, Aug 26, 2014 at 3:24 PM, Alex Harui wrote: > >>I don't believe my proposal is the "wrong way", just another alternative. >> > >I think your way would lead to confusion. Let's try to avoid that. What kind of confusion? >> In fact, we already approved one tweak when we added analytics to >> the landing page. Where are you drawing the line? >> > >I would say the line is when we compile a swf with the code in the repo, >we >need to make an official release. If we are hot linking, i.e. we don't >have the source for an example, we don't need to go through the release >process. Same way as the Installer. If we know that a dependency has >changed, we just change it in the installer config xml and push the site. >If we need to change the Installer itself, we go through a release >process. The installer is different because people download it and run it. Although there is a nightly installer build for Windows available. Related: Are you in favor of going back to loading explorer.xml? Right now it is compiled into explorer.swf so in order to point to the 3rd party content we need to re-compile explorer.mxml and under your preferences, go through another release. I think it would have been much more rewarding to the person offering the 3rd party links if we could have hooked him up yesterday. Justin switched to embedding XML to avoid a potential trust file issue when running locally, but I think as soon as you hit the next swf you'll get the same issue. We should just document in the release notes that you have to set up a trust file, and maybe add a global exception handler that says "Hey, you need to set up a trust file". > >And in some cases where we need to make minor changes (like the Google >Analytics hook), we can quickly take a [LAZY] vote to see if there are >objections. IMO, no vote is needed prior. It is just a commit and folks can veto. -Alex
Re: Agreeing to Disagree (was: Re: The Flex PMC isŠ)
Alex, Thanks for the info on email subjects. Will also keep that in mind (I too replied to the original thread). Just wanted to drop a note here letting ya know I caught this one too :) Chris On Tue, Aug 26, 2014 at 10:40 AM, Alex Harui wrote: > Hi Mihai, > > I didn't want our lack of response to imply to you that, as a new > committer, your thoughts are not welcome. They are, and I suspect most of > us do not have any disagreement with the basic principles of your message. > > First, I want to share some information I've learned about Apache. This > is still a relatively young project, and it is my first open-source > project. > > 1) Sometimes, an email thread's subject matter changes enough that it > should have a different subject. The convention at Apache for doing that > is what I did above: Use a new subject and add (was: ), > although I truncated the old subject in this case because I feel it is too > inflammatory (and incorrect). > > 2) Every project has at least one public mailing list like this one, and a > private mailing list that the PMC uses to discuss things like whether a > candidate for committer should be approved or not. > > 3) There is no objective standard at Apache for whether someone should get > approved. And since it is subjective, there can be disagreements. > > 4) Projects start out as "podlings" in the incubator that are guided by > mentors who have been at Apache for a while. They provide guidance on > recommended ways for an open source community to make progress. The > mentors fade away over time as the project becomes a official project. > > For sure, we don't want to silence anyone permanently, but in this case > you only saw a fraction of the total discussion. Several lengthy > discussions were properly held on the private list, and in each case, > Justin was the lone person supporting a particular position. The rest of > the PMC seems to agree with me that Justin has had ample time to make his > case, and we are not convinced, and therefore it is time to end the > discussion, agree to disagree, and move on. > > Now there have been many times in history where the lone supporter turned > out to be right, so if you still feel that we are being unfair to Justin, > I will ask our former mentors to review some of the email threads and > offer their thoughts, which they may do on the private list. I may do so > anyway. > > Thanks, > -Alex > > On 8/25/14 4:20 PM, "Mihai Chira" wrote: > > >So far I worked in 7 different closed-source (and 'closed' in many > >other ways) companies. There I've seen just how much backlash there > >can be when someone speaks up about what's not working. Over time > >people learn to stay silent. It saddens me to see this happening in an > >open-source project. I think as a community we could do a better job > >of appreciating those who reflect on what we do and find ways we can > >improve, even if we don't agree with their assessment. > > > >In that vein, I think Justin is doing a great job speaking out, > >despite the frequently dismissive and negative replies to his views. > > > >A community is defined not only by what it does, but also by how it > >does it. I share the interest in the processes we adopt, what they > >imply and what they say about us. > > > >I agree that it would probably have been beneficial if the Radii8 code > >donation happened on the dev mailing list. We would have all seen 1) > >that donations to apache flex are possible (I didn't know, or hadn't > >realised that before), and 2) what work they imply. Plus, they would > >have helped make visible this otherwise hidden work that the PMC > >members and donors do for the project. That's very important for > >recognition of contributions and, thus, for community building. So I > >think we should do it next time there's a donation. > >(And when the details of the donation process become uninteresting we > >can simply stop following that conversation thread, just like any > >other.) > > > >However, in terms of the importance of the problems outlined by Justin > >I think the last one is crucial. It definitely relates to the health > >of the community for more members to take responsibilities and help > >spread the workload and knowledge rather than having it concentrated > >in a small number of (thus precious) members. It's just as relevant > >for open-source projects to have a small Bus factor[1]. > >And I don't know when, how, or even if this happened, but if other > >contributions than code are not valued, this certainly reduces the > >likelihood that some people will spend time on the project. > > > >The current situation is that we are faced with a member of the > >community (Justin) considering to step down because he does not think > >we are doing some things right. As a result, he has provoked a > >discussion on those things, which I think is great. I suggest we > >should (as some have) talk about them and define for ourselves, as a > >community, whether we want
Re: The Flex PMC is broken
I was not sure how I'd give feedback on this, but I'd have to say Mihai hit the nail on the head for how I felt too reading these emails. After reading his email some thoughts came to mind which probably also parrot a little of what Alex said. This project is a labor of love. We all are here because we deeply care about the project, and when you care a lot about something, emotions can run high. Those emotions can get in the way of communication. This can happen at both ends. Both for the person making a statement and for someone who reads it. I think it's important to remember we all want this to grow and be the best it can be. And with that thought in mind, do our best to not only temper our emotion when we speak up, but also temper our emotion before we reply. I chose the word temper specifically. Temper in the sense that one would then make sure it would have the best effect and forethought before making use of it. Chris On Mon, Aug 25, 2014 at 6:33 PM, Justin Mclean wrote: > Hi, > > Thanks Mihai for your considered thoughts on this subject. > > Justin >
AW: Flex PMD donation
Hi Guys, ok so I just committed the refactored FlexPMD project (develop branch). I updated the structure to be more intuitive. Updated to Flexmojos 7.1.0-SNAPSHOT, Apache Flex 4.13.0, Apache FlexUnit 4.2, ... It was quite a lot of work and a big number of Tests will definitely fail, cause the Apache Headers have a different size than the Adobe ones and a lot of tests count line numbers or check line numbers of certain lines. I would like to ask you guys to spend a few hours in fixing them. You need a few jars manually deployed as well as Flex 4.13.0 created by the Mavenizer (mavenizer-refactoring branch). We have so much stuff in a pending state ... finally starting to release our stuff would make things so much easier. Chris Von: Justin Mclean Gesendet: Dienstag, 26. August 2014 00:43 An: dev@flex.apache.org Betreff: Re: Flex PMD donation Hi, > @Justin ... you claimed to have had the build running, I wonder how this is > possible. Most of the Unit Tests depend on line numbers. Yep I had to modify a few unit tests to get it to work and I hadn't got all sub projects to compile just 4 or 5. > What's currently blocking me, is that the class FlexMetricsReportMojo is > depending on some classes, which I simply can't find anywhere: > > import com.adobe.ac.pmd.metrics.maven.generators.NcssAggregateReportGenerator; > import com.adobe.ac.pmd.metrics.maven.generators.NcssReportGenerator; > import com.adobe.ac.pmd.metrics.maven.utils.ModuleReport; Didn't get that far so not much help there sorry. Thanks, Justin
Re: Reason for the release process
On Tue, Aug 26, 2014 at 3:24 PM, Alex Harui wrote: > > > On 8/26/14 2:54 PM, "OmPrakash Muppirala" wrote: > > >+1 to Justin's proposal. It makes sense to do things the right way and to > >encourage new folks to become Release Managers as the overhead is very low > >for TourDeFlex project. > I don't believe my proposal is the "wrong way", just another alternative. > I think your way would lead to confusion. Let's try to avoid that. > > > >Keep in mind that we may not be able to do this for 3rd party component > >developers. Because we want to hotlink to their examples and code > >directly, we may not be able to 'build' a release from our side. > > > >I propose that we create a new thirdparty.xml and allow direct editing of > >the file on the site so that 3rd party content will show up immediately > >without having to go through a release process. > I'm not sure I understand your position. I think you are saying you only > want to push a compiled source release to the site, but now I think you > are saying that it won't be a pure compilation, that some tweaks will be > made. In fact, we already approved one tweak when we added analytics to > the landing page. Where are you drawing the line? > I would say the line is when we compile a swf with the code in the repo, we need to make an official release. If we are hot linking, i.e. we don't have the source for an example, we don't need to go through the release process. Same way as the Installer. If we know that a dependency has changed, we just change it in the installer config xml and push the site. If we need to change the Installer itself, we go through a release process. And in some cases where we need to make minor changes (like the Google Analytics hook), we can quickly take a [LAZY] vote to see if there are objections. Thanks, Om > > -Alex > >
Re: Reason for the release process
As a side note, it will make your in-line responses more readable if you leave an extra line of space between the quote and the response. Thanks, Om On Tue, Aug 26, 2014 at 3:21 PM, Alex Harui wrote: > Sorry in advance for the point-for-point rebuttal, but I couldn't resist... > > On 8/26/14 2:46 PM, "Justin Mclean" wrote: > > >>I don't see any reason to add process where process is not required > >It's about community building. > I'm not sure extra process invites community building. > > > >> we can save time by not having to through the release process to fix > >>bugs > >> in the website version of TDF > >Can you spell out the process here. > Modify the landing page to give a proper label: "Daily Update", "Bleeding > Edge", "Snapshot", etc. > Fix or modify code in the repo or maybe a separate branch if we need to > reference 3rd party stuff that we don't want in the official versions. > Someone compiles it, if they like it, they push it up to the site. > If someone feels like it, cut another release. But hopefully not too > often. > > > > >As I see it - benefits of using a voting process: > >- PMC endorsement > What are the benefits of that. Are you claiming more people will use it > if endorsed? > >- Legal angle covered (IP issues etc) > No more dangerous than any other nightly build. > >- Community engagement (testing RCs + finding / fixing bugs + responding > >to release announcement) > Seemed like more folks waited until announced instead of helping with the > RC. > >- Voting process is relatively simple and straight forward > >- Testing RCs and being involved in process == more "points" towards > >committership * > Me, I'd rather submit a few patches to the examples than test the RC. > Seems like that's the pattern we see from other folks too. > >- RC process encourages people to find and report issues > It does, but it hasn't worked. > >- Hopefully potential people to consider for commitership > Folks submitting patches would also be considered wouldn't they? > >- Hopefully encourage a person to step forward and be a release manger > I'd rather encourage folks to spend time making TDF better. > >- Clear idea of changes between versions (via release notes) > >- Can announce on apache lists and in blogs - we can't announce snapshots > >(basically nightly builds) that way > Can we not blog that some new example was added to the TDF on the site? > You're right that we can't use an Announce email, but it seems like we'd > be able to make more noise by blogging often as each new example comes in. > >- Not in "under construction" / "development use only" mode continually. > >Different quality perception. > IMO, having a bug up there for 3 days is a worse quality perception than > fixing in minutes. > > > >Only down side I see is that we can't make changes very quickly (ie a few > >hours or days). But how quickly do we fix errors that arise anyway? > >There's JIRA's about broken examples that have been open for a few days > >but no one rushed in to fix them yet I see. ;-) > If we were set up as I propose, I'd be more inclined to fix something > instead of waiting until there's a push for a new release. > > > > >If we make changes directly on web site: > >- Gives an expectation that issues will be fixed quickly - can we > >actually do that? > We do that already for some issues in other packages. We tell folks to > try the nightly build. > >- IP or other legal issues may arise if all checkin /patches are not > >carefully monitored > Is true for any other nightly build. > >- Less reason for community to be involved (no RCs to test or vote on) > Most folks I know want to write code instead of run manual tests. > >- No need for a release manager or in fact any further releases > True, that's another time saving we could spend elsewhere. > >- Pages on web site / artefacts in dist will become out of date and not > >match site > Could release every 3 to six months if someone has the time and energy. > >- JIRAs may become confused as we may not have version numbers (what's > >the version number of a nightly build?) > Same for any other nightly build. If someone tries any nightly build and > finds a problem, how do they report it? > >- Can't announce on apache lists and in blogs = less apache exposure and > >less social media engagement > IMO, we could blog more often, and maybe the person who contributes the > change would blog right away as well instead of having to wait days to do > it. > > > > > >How about let's see if we can make a release or two under the existing RC > >candidates / voting system and if that process causes any issues revisit > >it? > We'll see what others think. I'd rather just save the time. I don't get > why we need to have 3 people look at simple changes before they go on the > site. > > -Alex > >
Re: Reason for the release process
On 8/26/14 2:54 PM, "OmPrakash Muppirala" wrote: >+1 to Justin's proposal. It makes sense to do things the right way and to >encourage new folks to become Release Managers as the overhead is very low >for TourDeFlex project. I don't believe my proposal is the "wrong way", just another alternative. > >Keep in mind that we may not be able to do this for 3rd party component >developers. Because we want to hotlink to their examples and code >directly, we may not be able to 'build' a release from our side. > >I propose that we create a new thirdparty.xml and allow direct editing of >the file on the site so that 3rd party content will show up immediately >without having to go through a release process. I'm not sure I understand your position. I think you are saying you only want to push a compiled source release to the site, but now I think you are saying that it won't be a pure compilation, that some tweaks will be made. In fact, we already approved one tweak when we added analytics to the landing page. Where are you drawing the line? -Alex
Re: Reason for the release process
Sorry in advance for the point-for-point rebuttal, but I couldn't resist... On 8/26/14 2:46 PM, "Justin Mclean" wrote: >>I don't see any reason to add process where process is not required >It's about community building. I'm not sure extra process invites community building. > >> we can save time by not having to through the release process to fix >>bugs >> in the website version of TDF >Can you spell out the process here. Modify the landing page to give a proper label: "Daily Update", "Bleeding Edge", "Snapshot", etc. Fix or modify code in the repo or maybe a separate branch if we need to reference 3rd party stuff that we don't want in the official versions. Someone compiles it, if they like it, they push it up to the site. If someone feels like it, cut another release. But hopefully not too often. > >As I see it - benefits of using a voting process: >- PMC endorsement What are the benefits of that. Are you claiming more people will use it if endorsed? >- Legal angle covered (IP issues etc) No more dangerous than any other nightly build. >- Community engagement (testing RCs + finding / fixing bugs + responding >to release announcement) Seemed like more folks waited until announced instead of helping with the RC. >- Voting process is relatively simple and straight forward >- Testing RCs and being involved in process == more "points" towards >committership * Me, I'd rather submit a few patches to the examples than test the RC. Seems like that's the pattern we see from other folks too. >- RC process encourages people to find and report issues It does, but it hasn't worked. >- Hopefully potential people to consider for commitership Folks submitting patches would also be considered wouldn't they? >- Hopefully encourage a person to step forward and be a release manger I'd rather encourage folks to spend time making TDF better. >- Clear idea of changes between versions (via release notes) >- Can announce on apache lists and in blogs - we can't announce snapshots >(basically nightly builds) that way Can we not blog that some new example was added to the TDF on the site? You're right that we can't use an Announce email, but it seems like we'd be able to make more noise by blogging often as each new example comes in. >- Not in "under construction" / "development use only" mode continually. >Different quality perception. IMO, having a bug up there for 3 days is a worse quality perception than fixing in minutes. > >Only down side I see is that we can't make changes very quickly (ie a few >hours or days). But how quickly do we fix errors that arise anyway? >There's JIRA's about broken examples that have been open for a few days >but no one rushed in to fix them yet I see. ;-) If we were set up as I propose, I'd be more inclined to fix something instead of waiting until there's a push for a new release. > >If we make changes directly on web site: >- Gives an expectation that issues will be fixed quickly - can we >actually do that? We do that already for some issues in other packages. We tell folks to try the nightly build. >- IP or other legal issues may arise if all checkin /patches are not >carefully monitored Is true for any other nightly build. >- Less reason for community to be involved (no RCs to test or vote on) Most folks I know want to write code instead of run manual tests. >- No need for a release manager or in fact any further releases True, that's another time saving we could spend elsewhere. >- Pages on web site / artefacts in dist will become out of date and not >match site Could release every 3 to six months if someone has the time and energy. >- JIRAs may become confused as we may not have version numbers (what's >the version number of a nightly build?) Same for any other nightly build. If someone tries any nightly build and finds a problem, how do they report it? >- Can't announce on apache lists and in blogs = less apache exposure and >less social media engagement IMO, we could blog more often, and maybe the person who contributes the change would blog right away as well instead of having to wait days to do it. > > >How about let's see if we can make a release or two under the existing RC >candidates / voting system and if that process causes any issues revisit >it? We'll see what others think. I'd rather just save the time. I don't get why we need to have 3 people look at simple changes before they go on the site. -Alex
Re: [OT] Who owns the code?
Hi, > In my experience / opinion; It is quite common for corporate contracts with > non-legally-enforcable clauses. They certainly sometimes try - even here in Australia. Our employment laws however makes it quite clear some types of these clauses are not actually enforceable, in the case of non competition, there are restriction of trade laws that prohibit misuse of them. Thanks, Justin
Re: [OT] Who owns the code?
Hi, > My understanding is that when contractors work for a client, the client > generally owns the code. Depends on what part of the world you are in and the contract you have signed with your employer or client. It's very different in the US to the rest or the world. With most of my contacts I sign I give the client a perpetual royalty free licence, meaning they can do what they want with to code and I can do what I want with it. I have in in past charged more for clients who insisted on exclusive IP rights. Sometimes this also brings up the subject of a non competitive clause (ie working for people who may be their competitors). If it is of unreasonable length then I usually ask for a list of all their competitors so that I don't accidentally work for the wrong people, and that clause usually gets removed. :-) I've had some clients who are happy for me to fix a bug or two in the SDK that was a concern to them and donate fixes to the SDK in their time and others who have not. But 99% of my time on Apache Flex is unpaid. Thanks, Justin
Re: Reason for the release process
+1 to Justin's proposal. It makes sense to do things the right way and to encourage new folks to become Release Managers as the overhead is very low for TourDeFlex project. Only problem is the required wait time of 72 hours for an RC to be promoted to production. Can we skip the 72 hours if we get enough votes for a release? Keep in mind that we may not be able to do this for 3rd party component developers. Because we want to hotlink to their examples and code directly, we may not be able to 'build' a release from our side. I propose that we create a new thirdparty.xml and allow direct editing of the file on the site so that 3rd party content will show up immediately without having to go through a release process. Thanks, Om On Tue, Aug 26, 2014 at 2:46 PM, Justin Mclean wrote: > Hi, > > > They said we could label the website version as a "development version" > or "snapshot" (like Maven) does. > I'm really not sure we want to do that (see below). > > > I don't see any reason to add process where process is not required > It's about community building. > > > we can save time by not having to through the release process to fix bugs > > in the website version of TDF > Can you spell out the process here. > > As I see it - benefits of using a voting process: > - PMC endorsement > - Legal angle covered (IP issues etc) > - Community engagement (testing RCs + finding / fixing bugs + responding > to release announcement) > - Voting process is relatively simple and straight forward > - Testing RCs and being involved in process == more "points" towards > committership * > - RC process encourages people to find and report issues > - Hopefully potential people to consider for commitership > - Hopefully encourage a person to step forward and be a release manger > - Clear idea of changes between versions (via release notes) > - Can announce on apache lists and in blogs - we can't announce snapshots > (basically nightly builds) that way > - Not in "under construction" / "development use only" mode continually. > Different quality perception. > > Note that apache blog announcements can get several thousand views and > gives good visibility of Apache Flex in the wider Apache community. The > Tour De Flex announcement yesterday got 1300+ views. > > Only down side I see is that we can't make changes very quickly (ie a few > hours or days). But how quickly do we fix errors that arise anyway? There's > JIRA's about broken examples that have been open for a few days but no one > rushed in to fix them yet I see. ;-) > > If we make changes directly on web site: > - Gives an expectation that issues will be fixed quickly - can we actually > do that? > - IP or other legal issues may arise if all checkin /patches are not > carefully monitored > - Less reason for community to be involved (no RCs to test or vote on) > - No need for a release manager or in fact any further releases > - Pages on web site / artefacts in dist will become out of date and not > match site > - JIRAs may become confused as we may not have version numbers (what's the > version number of a nightly build?) > - Can't announce on apache lists and in blogs = less apache exposure and > less social media engagement > > How about let's see if we can make a release or two under the existing RC > candidates / voting system and if that process causes any issues revisit it? > > Thanks, > Justin
Re: Reason for the release process
Hi, > They said we could label the website version as a "development version" or > "snapshot" (like Maven) does. I'm really not sure we want to do that (see below). > I don't see any reason to add process where process is not required It's about community building. > we can save time by not having to through the release process to fix bugs > in the website version of TDF Can you spell out the process here. As I see it - benefits of using a voting process: - PMC endorsement - Legal angle covered (IP issues etc) - Community engagement (testing RCs + finding / fixing bugs + responding to release announcement) - Voting process is relatively simple and straight forward - Testing RCs and being involved in process == more "points" towards committership * - RC process encourages people to find and report issues - Hopefully potential people to consider for commitership - Hopefully encourage a person to step forward and be a release manger - Clear idea of changes between versions (via release notes) - Can announce on apache lists and in blogs - we can't announce snapshots (basically nightly builds) that way - Not in "under construction" / "development use only" mode continually. Different quality perception. Note that apache blog announcements can get several thousand views and gives good visibility of Apache Flex in the wider Apache community. The Tour De Flex announcement yesterday got 1300+ views. Only down side I see is that we can't make changes very quickly (ie a few hours or days). But how quickly do we fix errors that arise anyway? There's JIRA's about broken examples that have been open for a few days but no one rushed in to fix them yet I see. ;-) If we make changes directly on web site: - Gives an expectation that issues will be fixed quickly - can we actually do that? - IP or other legal issues may arise if all checkin /patches are not carefully monitored - Less reason for community to be involved (no RCs to test or vote on) - No need for a release manager or in fact any further releases - Pages on web site / artefacts in dist will become out of date and not match site - JIRAs may become confused as we may not have version numbers (what's the version number of a nightly build?) - Can't announce on apache lists and in blogs = less apache exposure and less social media engagement How about let's see if we can make a release or two under the existing RC candidates / voting system and if that process causes any issues revisit it? Thanks, Justin
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-34476 Added RichTextEditor
HI, > Just happened to notice that ColorPicker's button appears to have been > changed in a way that wouldn't be backward-compatible. Changing the min width and height by 3 pixels is hardly a huge compatibility breaker. Plus it's one of the experimental spark components. Justin
RE: [OT] Who owns the code?
> My understanding is that a contractor "must" have the option of doing > non-client work. If that's true, if you found an SDK bug while working for a > client, would you "stop the clock", fix the bug, then "start the clock" > again? That way the fix would be owned by you. If the fix is owned by the > client, the client may need to give permission for the fix to be contributed > to Apache. We do two things. Our starting point is: if we are working with an open source framework/tool/project and we find a bug and fix it, it's going to be donated and we try to clarify that ownership in the contract from the beginning. For clients that refuse that, we 'stop the clock' so that we can fix and donate. Mike
Re: [OT] Who owns the code?
On 8/26/2014 3:56 PM, Nick Collins wrote: In many states ( California may be one of the exceptions ) those kinds of clauses are completely unenforceable if the "invention" is developed on your own time and only on your own equipment. If you are using company resources, then it definitely murkies the waters, but so long as you steer clear of that, then the generally accepted IP guidelines state that unless your contract specifically denotes the specific code your are writing is a "work made for hire" then you by default own the source code. In my experience / opinion; It is quite common for corporate contracts with non-legally-enforcable clauses. If put the responsibility on the 'lowly contractor' to prove he is in the right; which can be very expensive if it ever came to that. That is probably why such clauses exist in contracts. -- Jeffry Houser Technical Entrepreneur http://www.jeffryhouser.com 203-379-0773
Re: [OT] Who owns the code?
In many states ( California may be one of the exceptions ) those kinds of clauses are completely unenforceable if the "invention" is developed on your own time and only on your own equipment. If you are using company resources, then it definitely murkies the waters, but so long as you steer clear of that, then the generally accepted IP guidelines state that unless your contract specifically denotes the specific code your are writing is a "work made for hire" then you by default own the source code. If, in the case of JavaScript or other similar languages the deliverable is actually, by the nature of the technology, the code, then it gets into a grey area as well, because the person who contracted the code to be written is granted an implied license to use the deliverable. In the case of compiled code, say a Java JAR, the implied license only extends to the JAR, since they can use the API contained within it without your involvement. However, they do not automatically get an implied license to the code that was written to create that JAR. If they were to say, want to hire a different contractor to take over maintenance of the project, they could not require you to give that new contractor the source code to the JAR. Now, many contractors will do that at the onset as a show of good faith, but they are not legally bound to do so. Again, this is only based on my experience and extensive conversations I had with my IP attorney when I had to deal with a couple situations arising from people unrightly demanding my proprietary code from me, so depending on your state and local statutes, ymmv. Nick On Tue, Aug 26, 2014 at 12:45 PM, Jeffry Houser wrote: > On 8/26/2014 1:00 PM, Alex Harui wrote: > >> Thanks Jeffry, >> >> One followup question: My understanding is that a contractor "must" have >> the option of doing non-client work. >> > As lubricious as it sounds; a lot of contracts I am provided by employers > [bu default] they own everything I do regardless of whether it is done for > them or not. I, personally, have never signed a contract like that. And I > cannot imagine a company trying to enforce such a thing on a contractor. > > The whole thing boggles my mind. > > > If that's true, if you found an SDK >> bug while working for a client, would you "stop the clock", fix the bug, >> then "start the clock" again? >> > I would try to get approval for the client to pay for the bug fix. :-) > But, in lieu of that I'd stop the clock. > > > If >> the fix is owned by the client, the client may need to give permission for >> the fix to be contributed to Apache. >> > > Agreed! > > > -- > Jeffry Houser > Technical Entrepreneur > http://www.jeffryhouser.com > 203-379-0773 > >
Re: Flex 4 Plag In
I've tried calling him at the element river phone number, emailing him, and contacting him on LinkedIn before, just to find out what his plans were for SourceMate, and have yet to ever receive a response. That's why I thought if someone on this list knew him personally they may get more traction. On Tue, Aug 26, 2014 at 2:50 PM, OmPrakash Muppirala wrote: > On Tue, Aug 26, 2014 at 12:39 PM, Nick Collins > wrote: > > > Along those lines, I wonder if anybody here knows Chris Gross and might > be > > able to convince him to donate SourceMate (since it hasn't been updated > in > > a few years) so that we could integrate it into the Flash Builder plugin. > > > > > I believe this is him: https://twitter.com/chris_gross > If someone wants to contact him... > > Thanks, > Om > > > > > > On Mon, Aug 25, 2014 at 8:07 AM, Patel Amit > > wrote: > > > > > Hello, > > > > > > Is there any plugin for the Flex that we can use into the Eclipse > Indigo > > ? > > > > > > Amit > > > > > >
Re: Flex 4 Plag In
On Tue, Aug 26, 2014 at 12:39 PM, Nick Collins wrote: > Along those lines, I wonder if anybody here knows Chris Gross and might be > able to convince him to donate SourceMate (since it hasn't been updated in > a few years) so that we could integrate it into the Flash Builder plugin. > > I believe this is him: https://twitter.com/chris_gross If someone wants to contact him... Thanks, Om > > On Mon, Aug 25, 2014 at 8:07 AM, Patel Amit > wrote: > > > Hello, > > > > Is there any plugin for the Flex that we can use into the Eclipse Indigo > ? > > > > Amit > > >
Re: Flex 4 Plag In
Along those lines, I wonder if anybody here knows Chris Gross and might be able to convince him to donate SourceMate (since it hasn't been updated in a few years) so that we could integrate it into the Flash Builder plugin. On Mon, Aug 25, 2014 at 8:07 AM, Patel Amit wrote: > Hello, > > Is there any plugin for the Flex that we can use into the Eclipse Indigo ? > > Amit >
Re: Order on download menu on website
Makes sense. Less is more! EdB On Tuesday, August 26, 2014, Mihai Chira wrote: > Additionally, could we remove the prefix "Download the"? It feels > self-evident, since all the menu items are under the "Download Flex" > parent item. > > On 26 August 2014 17:53, Mihai Chira > > wrote: > > +1 > > > > On 26 August 2014 17:51, Chris Martin > > wrote: > >> +1 > >> > >> > >> On Mon, Aug 25, 2014 at 11:53 PM, Justin Mclean < > jus...@classsoftware.com > > >> wrote: > >> > >>> Hi, > >>> > >>> > +1. Didn't realize folks went after the binaries and source page > that > >>> > often. > >>> Me either was quite surprised - probably means estimates of number of > >>> installs is a lot lower than the actually number. Perhaps people have > been > >>> going there when the installer doesn't work? > >>> > >>> Thanks, > >>> Justin > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [OT] Who owns the code?
On 8/26/2014 1:00 PM, Alex Harui wrote: Thanks Jeffry, One followup question: My understanding is that a contractor "must" have the option of doing non-client work. As lubricious as it sounds; a lot of contracts I am provided by employers [bu default] they own everything I do regardless of whether it is done for them or not. I, personally, have never signed a contract like that. And I cannot imagine a company trying to enforce such a thing on a contractor. The whole thing boggles my mind. If that's true, if you found an SDK bug while working for a client, would you "stop the clock", fix the bug, then "start the clock" again? I would try to get approval for the client to pay for the bug fix. :-) But, in lieu of that I'd stop the clock. If the fix is owned by the client, the client may need to give permission for the fix to be contributed to Apache. Agreed! -- Jeffry Houser Technical Entrepreneur http://www.jeffryhouser.com 203-379-0773
Re: Order on download menu on website
No objection from me. I usually let something like this sit for 24-48 hours to give a chance for folks in different time zones to respond, then do it. So feel free to make the changes in a day or two. -Alex On 8/26/14 9:55 AM, "Mihai Chira" wrote: >Additionally, could we remove the prefix "Download the"? It feels >self-evident, since all the menu items are under the "Download Flex" >parent item. > >On 26 August 2014 17:53, Mihai Chira wrote: >> +1 >> >> On 26 August 2014 17:51, Chris Martin wrote: >>> +1 >>> >>> >>> On Mon, Aug 25, 2014 at 11:53 PM, Justin Mclean >>> >>> wrote: >>> Hi, > +1. Didn't realize folks went after the binaries and source page that > often. Me either was quite surprised - probably means estimates of number of installs is a lot lower than the actually number. Perhaps people have been going there when the installer doesn't work? Thanks, Justin
Agreeing to Disagree (was: Re: The Flex PMC isŠ)
Hi Mihai, I didn't want our lack of response to imply to you that, as a new committer, your thoughts are not welcome. They are, and I suspect most of us do not have any disagreement with the basic principles of your message. First, I want to share some information I've learned about Apache. This is still a relatively young project, and it is my first open-source project. 1) Sometimes, an email thread's subject matter changes enough that it should have a different subject. The convention at Apache for doing that is what I did above: Use a new subject and add (was: ), although I truncated the old subject in this case because I feel it is too inflammatory (and incorrect). 2) Every project has at least one public mailing list like this one, and a private mailing list that the PMC uses to discuss things like whether a candidate for committer should be approved or not. 3) There is no objective standard at Apache for whether someone should get approved. And since it is subjective, there can be disagreements. 4) Projects start out as "podlings" in the incubator that are guided by mentors who have been at Apache for a while. They provide guidance on recommended ways for an open source community to make progress. The mentors fade away over time as the project becomes a official project. For sure, we don't want to silence anyone permanently, but in this case you only saw a fraction of the total discussion. Several lengthy discussions were properly held on the private list, and in each case, Justin was the lone person supporting a particular position. The rest of the PMC seems to agree with me that Justin has had ample time to make his case, and we are not convinced, and therefore it is time to end the discussion, agree to disagree, and move on. Now there have been many times in history where the lone supporter turned out to be right, so if you still feel that we are being unfair to Justin, I will ask our former mentors to review some of the email threads and offer their thoughts, which they may do on the private list. I may do so anyway. Thanks, -Alex On 8/25/14 4:20 PM, "Mihai Chira" wrote: >So far I worked in 7 different closed-source (and 'closed' in many >other ways) companies. There I've seen just how much backlash there >can be when someone speaks up about what's not working. Over time >people learn to stay silent. It saddens me to see this happening in an >open-source project. I think as a community we could do a better job >of appreciating those who reflect on what we do and find ways we can >improve, even if we don't agree with their assessment. > >In that vein, I think Justin is doing a great job speaking out, >despite the frequently dismissive and negative replies to his views. > >A community is defined not only by what it does, but also by how it >does it. I share the interest in the processes we adopt, what they >imply and what they say about us. > >I agree that it would probably have been beneficial if the Radii8 code >donation happened on the dev mailing list. We would have all seen 1) >that donations to apache flex are possible (I didn't know, or hadn't >realised that before), and 2) what work they imply. Plus, they would >have helped make visible this otherwise hidden work that the PMC >members and donors do for the project. That's very important for >recognition of contributions and, thus, for community building. So I >think we should do it next time there's a donation. >(And when the details of the donation process become uninteresting we >can simply stop following that conversation thread, just like any >other.) > >However, in terms of the importance of the problems outlined by Justin >I think the last one is crucial. It definitely relates to the health >of the community for more members to take responsibilities and help >spread the workload and knowledge rather than having it concentrated >in a small number of (thus precious) members. It's just as relevant >for open-source projects to have a small Bus factor[1]. >And I don't know when, how, or even if this happened, but if other >contributions than code are not valued, this certainly reduces the >likelihood that some people will spend time on the project. > >The current situation is that we are faced with a member of the >community (Justin) considering to step down because he does not think >we are doing some things right. As a result, he has provoked a >discussion on those things, which I think is great. I suggest we >should (as some have) talk about them and define for ourselves, as a >community, whether we want to do things differently or not, instead of >being defensive by accusing him of "lashing out" or blackmailing us >into doing things "his way". The point, for me, is to figure out how >we move forward, as opposed to placing blame for what happened in the >past. And if Justin then steps down because he doesn't agree with our >way, it's perfectly fine. But if he steps down also because of the >hostility against him, we
Re: [OT] Who owns the code?
Thanks Jeffry, One followup question: My understanding is that a contractor "must" have the option of doing non-client work. If that's true, if you found an SDK bug while working for a client, would you "stop the clock", fix the bug, then "start the clock" again? That way the fix would be owned by you. If the fix is owned by the client, the client may need to give permission for the fix to be contributed to Apache. -Alex On 8/26/14 9:42 AM, "Jeffry Houser" wrote: > > I am not a lawyer, but that said.. > >On 8/26/2014 12:13 PM, Alex Harui wrote: >> My understanding is that when contractors work for a client, the client >> generally owns the code. > It depends on the contract, really. But, in my world it is very >uncommon for the client not to claim ownership of everything. [In fact >I often have to modify contract language to make it specific to work I >do for them]. > > My default contract has these clauses on ownership. It basically >says, "what is mine is mine; what is yours is yours". The second >aspect--cross-licenses says they can use/modify whatever is mine that I >add to the 'project' as part of the project. > >*6.OWNERSHIP* > >** > >If Client provides any of its intellectual property to DOTCOMIT in >connection with the development of the Work Assignment, such >intellectual property, together with all modifications to and >enhancements of, and all derivative works based upon, such works shall >remain the property of the Client (hereinafter referred to as the >³Client Proprietary Rights.²) > >Similarly, DOTCOMIT shall retain its title to the intellectual property, >software and tools used in the completion of the Work Assignment or in >connection with its development whether existing prior to the >commencement of this contract or developed during the course of its >performance, together with all modifications to and enhancements of, any >all derivatives based upon, such software and tools (hereinafter >referred to as ³Developer Proprietary Rights²). > >*7.CROSS LICENSES* > >** > >Effective upon completion and delivery of the Work Assignment from >DOTCOMIT to Client, DOTCOMIT grants to Client a perpetual, >non-exclusive, royalty-free license to use, perform and display the >Developer Proprietary Rights in connection with the use, display, >operation, maintenance and support of the Work Assignment in the manner >contemplated by the said Work Assignment. > >Effective upon completion and delivery of the Work Assignment from >DOTCOMIT to Client, Client grants to DOTCOMIT a perpetual, >non-exclusive, royalty-free license to use, reproduce, perform and >display the Work Assignment and Client Proprietary Rights solely and >exclusively for the use of DOTCOMIT in its marketing and promotional >efforts and to demonstrate its capabilities in the creation of such >works to potential customers or others without reservation or restriction. > > > > These clauses are often bones of contention and--depending on the >client--either get stripped out or heavily modified. > > >> So the question I have is: if you are a >> contractor and fix an SDK bug in the course of trying to get the >>client's >> app to run, who owns that fix? > It depends on the contract, but in most cases I would expect the >client 'owns' the fix. > >> Or do your contracts have ways of >> specifying what code the client gets to own or not. I would imagine >>some >> of you have an arsenal of libraries that you use in multiple projects. > I have never been able to build that arsenal of libraries because I >have never had a client contract which allowed me to re-use code for >other projects; and I never created it on my own. I've tried a few >times, but never got very far. > > Since I, generally, sell myself as a subject matter expert the bulk of >my clients are coming looking for help on their existing projects; so >they have massive code-bases already existing which I would modify. I >can understand why they wouldn't want to claim ownership. > > I know other contractors/consultants/companies who have had much >better luck with that than I in retaining code ownership. My impression >is that they are often providing semi-packaged solutions. I assume such >arrangements attract a different clientele. > > As an interesting note; at the most recent contract negotiation with >one of my bigger clients; their newly worded contract had very strict >restrictions on open source and code they didn't own. My interpretation >meant that doing any Flex dev for them--including maintaining the >existing apps they were hiring me to maintain--would be in immediate >violation of the terms. I spoke a little about this at a 360|Flex event >in the presentation "How to Fail Fantastically" [But the video seems to >have been taken down] > > > [Insert complaints about too much legalese on the dev list here] > >-- >Jeffry Houser >Technical Entrepreneur >http://www.jeffryhouser.com >203-379-0773 >
Re: FlexUnit Training on website and Flash Builder 4.7
Does anyone have an idea of which Flex SDK was used for the examples? Chris On Mon, Aug 25, 2014 at 1:48 PM, Chris Martin wrote: > Thanks Michael, will do! :D > > > On Mon, Aug 25, 2014 at 12:44 PM, Mihai Chira > wrote: > >> +1 >> On 23 Aug 2014 04:54, "Alex Harui" wrote: >> >> > +1 >> > >> > On 8/22/14 8:04 PM, "Justin Mclean" wrote: >> > >> > >Hi, >> > > >> > >> Started to think about updating the tutorial to also walk them >> through >> > >>the >> > >> UI differences too. Before I get too far into this, I wanted to run >> it >> > >> past the team. Is it cool if I go ahead and update the tutorials to >> > >>also >> > >> include the variations in FB 4.7 versus FB 4.6? >> > > >> > >No issues here +1 by me. >> > > >> > >Thanks, >> > >Justin >> > > >> > >> > >> > >
Re: [OT] Who owns the code?
Hi Mihai, If you have a "manager", that implies that you are an employee. The terms and conditions of your employment, and the manager's authority level in the company, factor into whether your contributions are sufficiently permitted. You may need to go up your management chain and get them to sign a CCLA. http://www.apache.org/licenses/cla-corporate.txt -Alex On 8/26/14 9:45 AM, "Mihai Chira" wrote: >I got my manager to explicitly consent to automatic donations to >Apache when we need to fix things in the SDK. I'm not sure this (i.e. >an email) is enough from a legal standpoint. > >On 26 August 2014 17:13, Alex Harui wrote: >> A question came up off-list that made me wonderŠ >> >> I've been an employee pretty much my whole career. Right now I work for >> Adobe and everything line of code I write is owned by Adobe, even at >>home >> after hours, even on my own computer, unless I cut a special deal. >> Fortunately, I have their blanket permission to auto-donate work related >> to Apache Flex to the ASF. >> >> My understanding is that when contractors work for a client, the client >> generally owns the code. So the question I have is: if you are a >> contractor and fix an SDK bug in the course of trying to get the >>client's >> app to run, who owns that fix? Or do your contracts have ways of >> specifying what code the client gets to own or not. I would imagine >>some >> of you have an arsenal of libraries that you use in multiple projects. >> >> Thanks in advance, >> -Alex >>
Re: Order on download menu on website
Additionally, could we remove the prefix "Download the"? It feels self-evident, since all the menu items are under the "Download Flex" parent item. On 26 August 2014 17:53, Mihai Chira wrote: > +1 > > On 26 August 2014 17:51, Chris Martin wrote: >> +1 >> >> >> On Mon, Aug 25, 2014 at 11:53 PM, Justin Mclean >> wrote: >> >>> Hi, >>> >>> > +1. Didn't realize folks went after the binaries and source page that >>> > often. >>> Me either was quite surprised - probably means estimates of number of >>> installs is a lot lower than the actually number. Perhaps people have been >>> going there when the installer doesn't work? >>> >>> Thanks, >>> Justin
Re: Order on download menu on website
+1 On 26 August 2014 17:51, Chris Martin wrote: > +1 > > > On Mon, Aug 25, 2014 at 11:53 PM, Justin Mclean > wrote: > >> Hi, >> >> > +1. Didn't realize folks went after the binaries and source page that >> > often. >> Me either was quite surprised - probably means estimates of number of >> installs is a lot lower than the actually number. Perhaps people have been >> going there when the installer doesn't work? >> >> Thanks, >> Justin
Re: Order on download menu on website
+1 On Mon, Aug 25, 2014 at 11:53 PM, Justin Mclean wrote: > Hi, > > > +1. Didn't realize folks went after the binaries and source page that > > often. > Me either was quite surprised - probably means estimates of number of > installs is a lot lower than the actually number. Perhaps people have been > going there when the installer doesn't work? > > Thanks, > Justin
Re: [OT] Who owns the code?
I got my manager to explicitly consent to automatic donations to Apache when we need to fix things in the SDK. I'm not sure this (i.e. an email) is enough from a legal standpoint. On 26 August 2014 17:13, Alex Harui wrote: > A question came up off-list that made me wonderŠ > > I've been an employee pretty much my whole career. Right now I work for > Adobe and everything line of code I write is owned by Adobe, even at home > after hours, even on my own computer, unless I cut a special deal. > Fortunately, I have their blanket permission to auto-donate work related > to Apache Flex to the ASF. > > My understanding is that when contractors work for a client, the client > generally owns the code. So the question I have is: if you are a > contractor and fix an SDK bug in the course of trying to get the client's > app to run, who owns that fix? Or do your contracts have ways of > specifying what code the client gets to own or not. I would imagine some > of you have an arsenal of libraries that you use in multiple projects. > > Thanks in advance, > -Alex >
Re: [OT] Who owns the code?
I am not a lawyer, but that said.. On 8/26/2014 12:13 PM, Alex Harui wrote: My understanding is that when contractors work for a client, the client generally owns the code. It depends on the contract, really. But, in my world it is very uncommon for the client not to claim ownership of everything. [In fact I often have to modify contract language to make it specific to work I do for them]. My default contract has these clauses on ownership. It basically says, "what is mine is mine; what is yours is yours". The second aspect--cross-licenses says they can use/modify whatever is mine that I add to the 'project' as part of the project. *6.OWNERSHIP* ** If Client provides any of its intellectual property to DOTCOMIT in connection with the development of the Work Assignment, such intellectual property, together with all modifications to and enhancements of, and all derivative works based upon, such works shall remain the property of the Client (hereinafter referred to as the “Client Proprietary Rights.”) Similarly, DOTCOMIT shall retain its title to the intellectual property, software and tools used in the completion of the Work Assignment or in connection with its development whether existing prior to the commencement of this contract or developed during the course of its performance, together with all modifications to and enhancements of, any all derivatives based upon, such software and tools (hereinafter referred to as “Developer Proprietary Rights”). *7.CROSS LICENSES* ** Effective upon completion and delivery of the Work Assignment from DOTCOMIT to Client, DOTCOMIT grants to Client a perpetual, non-exclusive, royalty-free license to use, perform and display the Developer Proprietary Rights in connection with the use, display, operation, maintenance and support of the Work Assignment in the manner contemplated by the said Work Assignment. Effective upon completion and delivery of the Work Assignment from DOTCOMIT to Client, Client grants to DOTCOMIT a perpetual, non-exclusive, royalty-free license to use, reproduce, perform and display the Work Assignment and Client Proprietary Rights solely and exclusively for the use of DOTCOMIT in its marketing and promotional efforts and to demonstrate its capabilities in the creation of such works to potential customers or others without reservation or restriction. These clauses are often bones of contention and--depending on the client--either get stripped out or heavily modified. So the question I have is: if you are a contractor and fix an SDK bug in the course of trying to get the client's app to run, who owns that fix? It depends on the contract, but in most cases I would expect the client 'owns' the fix. Or do your contracts have ways of specifying what code the client gets to own or not. I would imagine some of you have an arsenal of libraries that you use in multiple projects. I have never been able to build that arsenal of libraries because I have never had a client contract which allowed me to re-use code for other projects; and I never created it on my own. I've tried a few times, but never got very far. Since I, generally, sell myself as a subject matter expert the bulk of my clients are coming looking for help on their existing projects; so they have massive code-bases already existing which I would modify. I can understand why they wouldn't want to claim ownership. I know other contractors/consultants/companies who have had much better luck with that than I in retaining code ownership. My impression is that they are often providing semi-packaged solutions. I assume such arrangements attract a different clientele. As an interesting note; at the most recent contract negotiation with one of my bigger clients; their newly worded contract had very strict restrictions on open source and code they didn't own. My interpretation meant that doing any Flex dev for them--including maintaining the existing apps they were hiring me to maintain--would be in immediate violation of the terms. I spoke a little about this at a 360|Flex event in the presentation "How to Fail Fantastically" [But the video seems to have been taken down] [Insert complaints about too much legalese on the dev list here] -- Jeffry Houser Technical Entrepreneur http://www.jeffryhouser.com 203-379-0773
[OT] Who owns the code?
A question came up off-list that made me wonderŠ I've been an employee pretty much my whole career. Right now I work for Adobe and everything line of code I write is owned by Adobe, even at home after hours, even on my own computer, unless I cut a special deal. Fortunately, I have their blanket permission to auto-donate work related to Apache Flex to the ASF. My understanding is that when contractors work for a client, the client generally owns the code. So the question I have is: if you are a contractor and fix an SDK bug in the course of trying to get the client's app to run, who owns that fix? Or do your contracts have ways of specifying what code the client gets to own or not. I would imagine some of you have an arsenal of libraries that you use in multiple projects. Thanks in advance, -Alex
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-34476 Added RichTextEditor
I see it's in experimental, we don't care if the usage changes. Tom On 26/08/14 16:59, Alex Harui wrote: > Just happened to notice that ColorPicker's button appears to have been > changed in a way that wouldn't be backward-compatible. Do we care? After > all, it is still experimental. > > On 8/26/14 6:17 AM, "jmcl...@apache.org" wrote: > >> Repository: flex-sdk >> Updated Branches: >> refs/heads/develop 827297fc6 -> d4eeb05f5 >> >> >> FLEX-34476 Added RichTextEditor >> >> >> Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo >> Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/524cdbe3 >> Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/524cdbe3 >> Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/524cdbe3 >> >> Branch: refs/heads/develop >> Commit: 524cdbe33da270e1ce0b7b4f068bfdcf0be87f31 >> Parents: 827297f >> Author: Justin Mclean >> Authored: Tue Aug 26 23:12:57 2014 +1000 >> Committer: Justin Mclean >> Committed: Tue Aug 26 23:12:57 2014 +1000 >> >> -- >> frameworks/projects/experimental/spark-manifest.xml| 2 ++ >> frameworks/projects/experimental/src/ExperimentalClasses.as| 1 + >> .../experimental/src/spark/skins/ColorPickerButtonSkin.mxml| 2 +- >> 3 files changed, 4 insertions(+), 1 deletion(-) >> -- >> >> >> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >> rojects/experimental/spark-manifest.xml >> -- >> diff --git a/frameworks/projects/experimental/spark-manifest.xml >> b/frameworks/projects/experimental/spark-manifest.xml >> index 803a6f4..2a92ed4 100644 >> --- a/frameworks/projects/experimental/spark-manifest.xml >> +++ b/frameworks/projects/experimental/spark-manifest.xml >> @@ -46,4 +46,6 @@ >> >> > lookupOnly="true"/> >> > lookupOnly="true"/> >> + >> +> lookupOnly="true"/> >> >> >> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >> rojects/experimental/src/ExperimentalClasses.as >> -- >> diff --git a/frameworks/projects/experimental/src/ExperimentalClasses.as >> b/frameworks/projects/experimental/src/ExperimentalClasses.as >> index b11d626..33024da 100644 >> --- a/frameworks/projects/experimental/src/ExperimentalClasses.as >> +++ b/frameworks/projects/experimental/src/ExperimentalClasses.as >> @@ -32,6 +32,7 @@ package >> import spark.components.itemRenderers.MenuItemRenderer; >> MenuItemRenderer; >> import spark.components.listClasses.IListItemRenderer; >> IListItemRenderer; >> import spark.components.supportClasses.IDropDownContainer; >> IDropDownContainer; >> +import spark.components.RichTextEditor; RichTextEditor; >> import spark.containers.supportClasses.DeferredCreationPolicy; >> DeferredCreationPolicy; >> import spark.containers.Accordion; Accordion; >> import spark.events.ColorChangeEvent; ColorChangeEvent; >> >> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >> rojects/experimental/src/spark/skins/ColorPickerButtonSkin.mxml >> -- >> diff --git >> a/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >> xml >> b/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >> xml >> index 10dfc66..f8615b2 100644 >> --- >> a/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >> xml >> +++ >> b/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >> xml >> @@ -20,7 +20,7 @@ >> >> // >> // >> --> >> http://ns.adobe.com/mxml/2009"; >> xmlns:s="library://ns.adobe.com/flex/spark" >> -xmlns:fb="http://ns.adobe.com/flashbuilder/2009"; minWidth="24" >> minHeight="24"> >> +xmlns:fb="http://ns.adobe.com/flashbuilder/2009"; minWidth="21" >> minHeight="21"> >> >>
Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-34476 Added RichTextEditor
Just happened to notice that ColorPicker's button appears to have been changed in a way that wouldn't be backward-compatible. Do we care? After all, it is still experimental. On 8/26/14 6:17 AM, "jmcl...@apache.org" wrote: >Repository: flex-sdk >Updated Branches: > refs/heads/develop 827297fc6 -> d4eeb05f5 > > >FLEX-34476 Added RichTextEditor > > >Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo >Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/524cdbe3 >Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/524cdbe3 >Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/524cdbe3 > >Branch: refs/heads/develop >Commit: 524cdbe33da270e1ce0b7b4f068bfdcf0be87f31 >Parents: 827297f >Author: Justin Mclean >Authored: Tue Aug 26 23:12:57 2014 +1000 >Committer: Justin Mclean >Committed: Tue Aug 26 23:12:57 2014 +1000 > >-- > frameworks/projects/experimental/spark-manifest.xml| 2 ++ > frameworks/projects/experimental/src/ExperimentalClasses.as| 1 + > .../experimental/src/spark/skins/ColorPickerButtonSkin.mxml| 2 +- > 3 files changed, 4 insertions(+), 1 deletion(-) >-- > > >http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >rojects/experimental/spark-manifest.xml >-- >diff --git a/frameworks/projects/experimental/spark-manifest.xml >b/frameworks/projects/experimental/spark-manifest.xml >index 803a6f4..2a92ed4 100644 >--- a/frameworks/projects/experimental/spark-manifest.xml >+++ b/frameworks/projects/experimental/spark-manifest.xml >@@ -46,4 +46,6 @@ > > lookupOnly="true"/> > lookupOnly="true"/> >+ >+lookupOnly="true"/> > > >http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >rojects/experimental/src/ExperimentalClasses.as >-- >diff --git a/frameworks/projects/experimental/src/ExperimentalClasses.as >b/frameworks/projects/experimental/src/ExperimentalClasses.as >index b11d626..33024da 100644 >--- a/frameworks/projects/experimental/src/ExperimentalClasses.as >+++ b/frameworks/projects/experimental/src/ExperimentalClasses.as >@@ -32,6 +32,7 @@ package > import spark.components.itemRenderers.MenuItemRenderer; >MenuItemRenderer; > import spark.components.listClasses.IListItemRenderer; >IListItemRenderer; > import spark.components.supportClasses.IDropDownContainer; >IDropDownContainer; >+ import spark.components.RichTextEditor; RichTextEditor; > import spark.containers.supportClasses.DeferredCreationPolicy; >DeferredCreationPolicy; > import spark.containers.Accordion; Accordion; > import spark.events.ColorChangeEvent; ColorChangeEvent; > >http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/524cdbe3/frameworks/p >rojects/experimental/src/spark/skins/ColorPickerButtonSkin.mxml >-- >diff --git >a/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >xml >b/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >xml >index 10dfc66..f8615b2 100644 >--- >a/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >xml >+++ >b/frameworks/projects/experimental/src/spark/skins/ColorPickerButtonSkin.m >xml >@@ -20,7 +20,7 @@ > >// >// > --> > http://ns.adobe.com/mxml/2009"; >xmlns:s="library://ns.adobe.com/flex/spark" >-xmlns:fb="http://ns.adobe.com/flashbuilder/2009"; minWidth="24" >minHeight="24"> >+xmlns:fb="http://ns.adobe.com/flashbuilder/2009"; minWidth="21" >minHeight="21"> > >
Re: Reason for the release process
I was hoping you'd forward my reply so I don't have to write it again. Here it is again: So far, the two other folks on the incubator who replied to my question there have not supported your position. They said we could label the website version as a "development version" or "snapshot" (like Maven) does. I don't see any reason to add process where process is not required so if we can save time by not having to through the release process to fix bugs in the website version of TDF, we should save time and do so. In fact, I would argue it would give us better community involvement because someone can post a JIRA with a new or fixed example and we can place it on the site in minutes, not 72 hours or more later. And it would save us time because often more than one person reports the same bug so we have to service more duplicate JIRAs and emails. We've got plenty of other projects that do need a release process for folks who are looking to learn how to be an RM and serve as the model. I'm going to wait another day or two to see if Justin can get any support on the incubator list, and if not, I think we should start fixing bugs and adding to the web-site version of TDF so its users get the best possible experience. -Alex On 8/26/14 12:40 AM, "Justin Mclean" wrote: >Hi, > >Forwarding to dev@ at Om and Alex's request (with a couple of very minor >edits). Please feel free to comment. > >Justin > >> From: Justin Mclean >> Subject: Reason for the release process >> Date: 26 August 2014 12:07:29 pm AEST >> To: priv...@flex.apache.org >> >> Hi, >> >> This is come upon the dev list and incubator lists but is probably >>more relevant to the PMC, and a better place to discuss it, so I'm >>posting here. >> >> As I understand it Alex is suggesting we directly change TourDeFlex on >>the web site (ie deploy new compiled sources that we have not voted on) >>and not use the usual release process. Alex please feel free to clarify >>anything if I'm misunderstanding anything here. >> >> The whole point of the release process is to: >> 1. Have legal overview by the PMC >> 2. Engage and involve the community >> >> Why would we want to avoid either? As we've seen we've already had >>some community involvement in TourDeFlex and I expect a little more over >>the next week or so. Perhaps if we're lucky we'll even get someone to >>try and fix a bug or two who may in time end up being put forward as a >>committer. >> >> As [1] says "Under no circumstances are unapproved builds a substitute >>for releases. If this policy seems inconvenient, then release more >>often." >> >> I would like to make TourDeFlex a good example of the release process >>as it's relatively easy to change and update (compared to the SDK), and >>not hard to compile or vote on and a lot easier to make more frequent >>releases of (depending on contributions of course). Allso to show that >>the release process is it not something we should be scared or or try >>and avoid and hopefully even get someone else to try and be a release >>manager. Doing all of this means more community involvement and shares >>knowledge and responsibility about, which is a good thing in my books. >> >> And (with my PMC hat on) I'd also note that [1]: >> "Deviations from this policy may have an adverse effect on the legal >>shield's effectiveness, or the insurance premiums Apache pays to protect >>officers and directors, so are strongly discouraged without prior, >>explicit board approval." >> >> Thanks, >> Justin >> >> 1. http://www.apache.org/dev/release.html >
Re: Adding Tour De Flex to the web site
It worked. It could have been your cache, but Infra also has been fighting a web server problem where the server doesn't see new pages right away so it could be that as well. -Alex On 8/26/14 12:32 AM, "OmPrakash Muppirala" wrote: >On Tue, Aug 26, 2014 at 12:28 AM, Justin Mclean >wrote: > >> Hi, >> >> Published but didn't seem to work - anyone have any ideas? >> >> Thanks, >> Justin >> > >I do see it here: http://flex.apache.org/download-tourdeflex.html >Maybe you need to clear your cache and try again? > >Thanks, >Om
Re: [FlexJS] BarChartExample not compiling
Make sure your FlashBuilder set up is on a recent FlexJS install. The
Google Closure Library and Compiler versions changed and generate
different code.
On 8/26/14 7:35 AM, "Peter Ent" wrote:
>There seems to be two problems. The first is easily solvable: the
>build_example.xml has the HTML wrapper size restricted and it could be
>changed to 100% x 100%.
>
>The second problem seems more insidious. The SWF just seems blank and I
>have to investigate that further. The JS output that is being created is
>incorrect:
>
>BarChartExample.js winds up with this:
>
>BarChartExample = function() {
> BarChartExample.base(this, 'constructor');
>
>
>whereas the version created using the launch config in Flash Builder
>creates this:
>
>BarChartExample = function() {
> goog.base(this);
>
>
>
>Not sure what is going on with the ANT build from flex-asjs/examples.
>Maybe I have something out of date.
>
>I need to see if other examples are having the same issues.
>
>Peter Ent
>Adobe Systems
>
>On 8/26/14 8:07 AM, "Peter Ent" wrote:
>
>>I pushed changes to BarChartExample that reflect the latest changes to
>>the
>>SDK. I found one problem which I will look into today: the index.html
>>file
>>that is generated during the ANT build differs from the index.html
>>generated by Flash Builder. This difference, which is the coded
>>dimensions
>>of the SWF, is set to 400x300 in the ANT build but 100% x 100% when
>>generated from Flash Builder. The 400x300 size is incorrect and will not
>>display the content properly.
>>
>>Peter Ent
>>Adobe Systems
>>
>>On 8/26/14 6:50 AM, "Peter Ent" wrote:
>>
>>>Oops. I made a bunch of changes to the chart package. I will update the
>>>example soon.
>>>
>>>Peter Ent
>>>Adobe Systems
>>>
>>>
On Aug 26, 2014, at 1:48 AM, "OmPrakash Muppirala"
wrote:
I am getting this error:
build_example.compile:
[echo] Compiling BarChartExample.swf
[echo] FLEX_HOME: C:\p\flex_os\workspace\flexroot\git\flex-asjs
[mxmlc] Loading configuration:
C:\p\flex_os\workspace\flexroot\git\flex-asjs
\frameworks\flex-config.xml
[mxmlc]
[mxmlc]
C:\p\flex_os\workspace\flexroot\git\flex-asjs\examples\BarChartExamp
le\src\MyInitialView.mxml:62
[mxmlc] Error: This tag is unexpected. It will be ignored.
[mxmlc] >>> width="400"
height="200">
[mxmlc] ^
[mxmlc]
StackedChart is not found here:
flex-asjs\frameworks\as\projects\FlexJSUI\src\org\apache\flex\charts
Maybe it was not checked in?
Thanks,
Om
>>
>
Re: [FlexJS] BarChartExample not compiling
There seems to be two problems. The first is easily solvable: the
build_example.xml has the HTML wrapper size restricted and it could be
changed to 100% x 100%.
The second problem seems more insidious. The SWF just seems blank and I
have to investigate that further. The JS output that is being created is
incorrect:
BarChartExample.js winds up with this:
BarChartExample = function() {
BarChartExample.base(this, 'constructor');
whereas the version created using the launch config in Flash Builder
creates this:
BarChartExample = function() {
goog.base(this);
Not sure what is going on with the ANT build from flex-asjs/examples.
Maybe I have something out of date.
I need to see if other examples are having the same issues.
Peter Ent
Adobe Systems
On 8/26/14 8:07 AM, "Peter Ent" wrote:
>I pushed changes to BarChartExample that reflect the latest changes to the
>SDK. I found one problem which I will look into today: the index.html file
>that is generated during the ANT build differs from the index.html
>generated by Flash Builder. This difference, which is the coded dimensions
>of the SWF, is set to 400x300 in the ANT build but 100% x 100% when
>generated from Flash Builder. The 400x300 size is incorrect and will not
>display the content properly.
>
>Peter Ent
>Adobe Systems
>
>On 8/26/14 6:50 AM, "Peter Ent" wrote:
>
>>Oops. I made a bunch of changes to the chart package. I will update the
>>example soon.
>>
>>Peter Ent
>>Adobe Systems
>>
>>
>>> On Aug 26, 2014, at 1:48 AM, "OmPrakash Muppirala"
>>> wrote:
>>>
>>> I am getting this error:
>>>
>>> build_example.compile:
>>> [echo] Compiling BarChartExample.swf
>>> [echo] FLEX_HOME: C:\p\flex_os\workspace\flexroot\git\flex-asjs
>>>[mxmlc] Loading configuration:
>>> C:\p\flex_os\workspace\flexroot\git\flex-asjs
>>> \frameworks\flex-config.xml
>>>[mxmlc]
>>>[mxmlc]
>>> C:\p\flex_os\workspace\flexroot\git\flex-asjs\examples\BarChartExamp
>>> le\src\MyInitialView.mxml:62
>>>[mxmlc] Error: This tag is unexpected. It will be ignored.
>>>[mxmlc] >> width="400"
>>> height="200">
>>>[mxmlc] ^
>>>[mxmlc]
>>>
>>> StackedChart is not found here:
>>> flex-asjs\frameworks\as\projects\FlexJSUI\src\org\apache\flex\charts
>>>
>>> Maybe it was not checked in?
>>>
>>> Thanks,
>>> Om
>
Re: [FlexJS] BarChartExample not compiling
I pushed changes to BarChartExample that reflect the latest changes to the SDK. I found one problem which I will look into today: the index.html file that is generated during the ANT build differs from the index.html generated by Flash Builder. This difference, which is the coded dimensions of the SWF, is set to 400x300 in the ANT build but 100% x 100% when generated from Flash Builder. The 400x300 size is incorrect and will not display the content properly. Peter Ent Adobe Systems On 8/26/14 6:50 AM, "Peter Ent" wrote: >Oops. I made a bunch of changes to the chart package. I will update the >example soon. > >Peter Ent >Adobe Systems > > >> On Aug 26, 2014, at 1:48 AM, "OmPrakash Muppirala" >> wrote: >> >> I am getting this error: >> >> build_example.compile: >> [echo] Compiling BarChartExample.swf >> [echo] FLEX_HOME: C:\p\flex_os\workspace\flexroot\git\flex-asjs >>[mxmlc] Loading configuration: >> C:\p\flex_os\workspace\flexroot\git\flex-asjs >> \frameworks\flex-config.xml >>[mxmlc] >>[mxmlc] >> C:\p\flex_os\workspace\flexroot\git\flex-asjs\examples\BarChartExamp >> le\src\MyInitialView.mxml:62 >>[mxmlc] Error: This tag is unexpected. It will be ignored. >>[mxmlc] > width="400" >> height="200"> >>[mxmlc] ^ >>[mxmlc] >> >> StackedChart is not found here: >> flex-asjs\frameworks\as\projects\FlexJSUI\src\org\apache\flex\charts >> >> Maybe it was not checked in? >> >> Thanks, >> Om
Re: [FlexJS] BarChartExample not compiling
Oops. I made a bunch of changes to the chart package. I will update the example soon. Peter Ent Adobe Systems > On Aug 26, 2014, at 1:48 AM, "OmPrakash Muppirala" > wrote: > > I am getting this error: > > build_example.compile: > [echo] Compiling BarChartExample.swf > [echo] FLEX_HOME: C:\p\flex_os\workspace\flexroot\git\flex-asjs >[mxmlc] Loading configuration: > C:\p\flex_os\workspace\flexroot\git\flex-asjs > \frameworks\flex-config.xml >[mxmlc] >[mxmlc] > C:\p\flex_os\workspace\flexroot\git\flex-asjs\examples\BarChartExamp > le\src\MyInitialView.mxml:62 >[mxmlc] Error: This tag is unexpected. It will be ignored. >[mxmlc] width="400" > height="200"> >[mxmlc] ^ >[mxmlc] > > StackedChart is not found here: > flex-asjs\frameworks\as\projects\FlexJSUI\src\org\apache\flex\charts > > Maybe it was not checked in? > > Thanks, > Om
Re: Flash builder 4.7 plug in link ?
You mean this : http://www.adobe.com/uk/products/flash-builder.html ? Tom On 25/08/14 15:11, Patel Amit wrote: > Hi, > > Could some share the link for the flash builder 4.7 plugin for the Java > eclipse.? > > Amit > > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __
Fwd: Reason for the release process
Hi, Forwarding to dev@ at Om and Alex's request (with a couple of very minor edits). Please feel free to comment. Justin > From: Justin Mclean > Subject: Reason for the release process > Date: 26 August 2014 12:07:29 pm AEST > To: priv...@flex.apache.org > > Hi, > > This is come upon the dev list and incubator lists but is probably more > relevant to the PMC, and a better place to discuss it, so I'm posting here. > > As I understand it Alex is suggesting we directly change TourDeFlex on the > web site (ie deploy new compiled sources that we have not voted on) and not > use the usual release process. Alex please feel free to clarify anything if > I'm misunderstanding anything here. > > The whole point of the release process is to: > 1. Have legal overview by the PMC > 2. Engage and involve the community > > Why would we want to avoid either? As we've seen we've already had some > community involvement in TourDeFlex and I expect a little more over the next > week or so. Perhaps if we're lucky we'll even get someone to try and fix a > bug or two who may in time end up being put forward as a committer. > > As [1] says "Under no circumstances are unapproved builds a substitute for > releases. If this policy seems inconvenient, then release more often." > > I would like to make TourDeFlex a good example of the release process as it's > relatively easy to change and update (compared to the SDK), and not hard to > compile or vote on and a lot easier to make more frequent releases of > (depending on contributions of course). Allso to show that the release > process is it not something we should be scared or or try and avoid and > hopefully even get someone else to try and be a release manager. Doing all of > this means more community involvement and shares knowledge and responsibility > about, which is a good thing in my books. > > And (with my PMC hat on) I'd also note that [1]: > "Deviations from this policy may have an adverse effect on the legal shield's > effectiveness, or the insurance premiums Apache pays to protect officers and > directors, so are strongly discouraged without prior, explicit board > approval." > > Thanks, > Justin > > 1. http://www.apache.org/dev/release.html
Re: Adding Tour De Flex to the web site
On Tue, Aug 26, 2014 at 12:28 AM, Justin Mclean wrote: > Hi, > > Published but didn't seem to work - anyone have any ideas? > > Thanks, > Justin > I do see it here: http://flex.apache.org/download-tourdeflex.html Maybe you need to clear your cache and try again? Thanks, Om
Re: Adding Tour De Flex to the web site
Hi, Published but didn't seem to work - anyone have any ideas? Thanks, Justin
Re: [ANNOUNCE] Apache FlexJS 0.0.2 and Apache Flex FalconJX 0.0.2 Released
Unfortunately, Flash Builder 4.6 is not supported. You will need to use Flash Builder 4.7, or FDT or possibly IntelliJ. On 8/25/14 11:23 PM, "Patel Amit" wrote: >we have any demo how to configure the FlexJs or FalconJs into the adobe >flash builder 4.6 ? >or any other steps ,blogs related to that ? > > >On Mon, Aug 25, 2014 at 2:05 PM, piotrz wrote: > >> Slightly after time but posted information about release on some polish >> forums. >> >> Piotr >> >> >> >> - >> Apache Flex Committer >> piotrzarzyck...@gmail.com >> -- >> View this message in context: >> >>http://apache-flex-development.247.n4.nabble.com/ANNOUNCE-Apache-Flex >>JS-0-0-2-and-Apache-Flex-FalconJX-0-0-2-Released-tp39773p40036.html >> Sent from the Apache Flex Development mailing list archive at >>Nabble.com. >>
