Hi,
I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
and I think allowing vetoes for most everything, as those guidelines
do, is calling for trouble.
The standard Apache voting process [1] specifies vetoes for commits only.
My recommendation would be to make those guidelin
On Wed, Nov 26, 2014 at 10:06 AM, Bertrand Delacretaz
wrote:
> ...I'm intentionally not subscribing to your private list at the moment...
FWIW, I have also subscribed to that list now, as I felt I didn't have
the complete picture.
-Bertrand
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything, as those guidelines
> do, is calling for trouble.
We recently voted to change the default vote type from Consensus to
Majority Approval.
The only Consensus votes remaining
Hi,
A friendly reminder that we're nearing another milestone towards the
4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12
09:00), to be precise, I'll cut the release branch. This marks the
last opportunity for any features or 'normal' bug fixes to be
committed to the repo and be
Reducing the types of votes available would make getting my head around
them easier, certainly.
I think the 'lazy consensus' we have listed on our Wiki also conflicts
with the Apache version because of the -1 veto, which should certainly
be corrected; we should just link to the Apache page there
On Thu, Dec 4, 2014 at 9:24 AM, Erik de Bruin wrote:
> ...The only Consensus votes remaining in our guidelines (that I can find)
> are for the addition or removal of people in 'official' Apache
> positions (Committers and PMC members)
FWIW I am even suggesting that you guys drop this "consens
Hello again Darrell, and sorry for bothering one more time,
I've been browsing the MXMLC source looking for IFactory info, but I
couldn't find what I need. How do I determine the type of class/interface
expected by an IFactory? is it posible or must I add it case by case? I've
seen that when the
FWIW, I do not think we’re going to have TLF in release shape in a week.
I’ve fixed a couple of bugs this week, but it’s slow going and I know of at
least two more that need to be fixed. There’s probably more than that. I’ll
only know after I get more of the tests to run.
I’m fine with pulling
Hey everyone,
Thanks Bertrand for the info. At some point I think we should change the
wording to be more of what we intend. Mainly
because Bertrand makes a good point by pointing out a "burden of defining
your own variants" is being made. I actually registered to change agreement
to "majority ap
On Thu, Dec 4, 2014 at 10:48 AM, Tom Chiverton wrote:
> ...I'm sure if we got
> to the point of voting on something, and there were a large fraction of -1
> (but more +1) we'd still take that as a signal to evaluate whatever it was
> more strongly...
That would be great, yes. And even a single -1
Hi,
I want to make sure that the SDK documentation (README, RELEASE_NOTES,
NOTICE, LICENSE and CONTRIBUTORS) is in order BEFORE we enter the
release cycle. This will avoid discussion and delay, so please
contribute if you can!
There were considerable changes to each of these documents, so please
Hi Bertrand,
Sounds good and easy, let's see how it will work...
Thanks for your time digging into that :-)
Frédéric THOMAS
> Date: Thu, 4 Dec 2014 00:23:10 +0100
> Subject: [TTH] How to agree on International vs. US English...or similar
> things
> From: bdelacre...@apache.org
> To: dev@flex.apa
No need to get TLF in shape in a week. There will be plenty of time to
stabilise it during the release cycles. I really want TLF to be part
of this release, and will give it every chance to make it.
If at some point TLF stabilisation will turn out to be impossible for
this release, we'll point the
I agree with Alex, I think we should address confusion when confusion
arises. Also I don't feel we want to foster a feeling of apprehension in
the community when writing out an English sentence. We are all fairly
global now, so I feel that I (being from the US) can read and understand UK
English j
I commented earlier about porting the flash runtime + flex to
typescript/javascript and was asked to send an email to this list with more
info plus my progress. In terms of progress, I'd say that I have somewhere
north of 250K lines of doc comments and code done, with a lot to fill in.
The entire F
On Dec 4, 2014, at 10:05 AM, Bertrand Delacretaz wrote:
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything
Really?
I thought the only votes where vetoes are allowed are for voting in new
committers/PMC members/PMC Chair.
As a PMC I'm very much aware of the Apache voting rules, as a project
we have codified them in our guidelines. I very much resent the
implication from Justin that I am not familiar with them :-(
On the article: Justin has really taken this whole discussion way out
of context, as the paragraph he k
You should take a look at FalconJX (same repo as Falcon): it is
designed specifically to be a cross-compiler that can compile to
various output languages. It sounds to me you are trying to re-invent
the wheel by starting from Falcon. FalconJX currently has code
branches that handle the various flav
>Anyone else? Or can I just delete any branch that is not master, develop,
>FDBWorkers or an old release branch? My guess would be:
>"no!", but it would sure be nice if you left a note saying you are still
>working on a branch ;-)
Erik,
I believe I still have mine out there and, if time ever pe
On 04/12/14 08:14, Harbs wrote:
I just readhttps://cwiki.apache.org/confluence/display/FLEX/Guidelines
>and I think allowing vetoes for most everything
Really?
I thought the only votes where vetoes are allowed are for voting in new
committers/PMC members/PMC Chair.
Code change is 'lazy' which
No worries. If you intend to work on them at any point, the branches
have a reason to exist. There is no need to remove them. Just trying
to clear out the actual dead wood :-)
Thanks,
EdB
On Thu, Dec 4, 2014 at 6:07 AM, Michael A. Labriola
wrote:
>>Anyone else? Or can I just delete any branch
Hi,
> Cool - so it looks like there's no need to discuss this further, until
> Justin makes those edits and reports here that he's happy with the
> result.
Done. I've also marked up what I think the issues are with this approach.
If we are going to introduce a new release procedure, we need to m
Hi,
Thanks for your time and analysis Bertrand.
I'd just like it add that it only come up as an issue as some PMC members
considered spelling issues a "blocker" for release candidates. I'm not sure if
they still consider that to be the case.
Thanks,
Justin
Any objections if I add a section in the flex.apache.org home page pointing
to my slides from the HTML5 Dev Conf presentation [1] ?
The slides already have more than 1800 views and adding it to our site
might get more views.
Thanks,
Om
[1] http://www.slideshare.net/bigosmallm/flexjs-an-introduct
Harbs,
I can't help with this, but I'm thinking that maybe posting question related
to this on Dev users list could help.
Maybe you will find someone there who have some experience in that matter.
Just my thoughts.
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message i
On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> ...If you feel it should be changed anyway, I have no objections to that...
I havent checked if allowing vetoes for many things has caused
problems or not so far but I see a potential for creating blocking
problems, so fixing that now is probably a g
You are actively discouraging non-PMC members to participate in the
release process by repeatedly explaining how their votes are worth
nothing.
You have edited the paragraph that talks about the 'old' release
process to read as if it were part of the new proposal. It is not. The
text you have edit
+1
Time we start giving the FlexJS effort some visibility on the website anyway.
EdB
On Wed, Dec 3, 2014 at 9:13 PM, OmPrakash Muppirala
wrote:
> Any objections if I add a section in the flex.apache.org home page pointing
> to my slides from the HTML5 Dev Conf presentation [1] ?
>
> The slide
On Thu, Dec 4, 2014 at 2:03 AM, Justin Mclean wrote:
> ...I'd just like it add that it only come up as an issue as some PMC members
> considered spelling
> issues a "blocker" for release candidates. I'm not sure if they still
> consider that to be the case
Based on http://www.apache.org/fou
The way I see the decision for this works similar to how we code in the SDK.
Follow the style and format of the existing file. So if you're modifying the
SDK you would normally mimic the code style / format that is present in that
file. Better to be consistent than have split styles.
-Mark
On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz"
wrote:
>
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > ...If you feel it should be changed anyway, I have no objections to
that...
>
> I havent checked if allowing vetoes for many things has caused
> problems or not so far but I see a potential f
BTW, what does the TTH in the subject line strands for?
Thanks,
Om
On Dec 4, 2014 7:14 AM, "OmPrakash Muppirala" wrote:
>
> On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz"
> wrote:
> >
> > On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > > ...If you feel it should be changed anyway, I have no ob
I'm on board with this. I like the idea of taking "the edge off" a -1 vote
On Thu, Dec 4, 2014 at 6:47 AM, Bertrand Delacretaz
wrote:
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > ...If you feel it should be changed anyway, I have no objections to
> that...
>
> I havent checked if allowin
On Thursday, December 4, 2014, OmPrakash Muppirala
wrote:
> BTW, what does the TTH in the subject line strands for?
Trying To Help - I made that up a few days ago,
http://flex.markmail.org/thread/re2q3mxlzws76x26
-Bertrand
On Dec 4, 2014 7:19 AM, "Bertrand Delacretaz"
wrote:
>
> On Thursday, December 4, 2014, OmPrakash Muppirala
> wrote:
>
> > BTW, what does the TTH in the subject line strands for?
>
> Trying To Help - I made that up a few days ago,
> http://flex.markmail.org/thread/re2q3mxlzws76x26
Ah, I missed t
On 12/4/14, 5:51 AM, "Bertrand Delacretaz" wrote:
>On Thu, Dec 4, 2014 at 2:03 AM, Justin Mclean
>wrote:
>> ...I'd just like it add that it only come up as an issue as some PMC
>>members considered spelling
>> issues a "blocker" for release candidates. I'm not sure if they still
>>consider tha
On 12/4/14, 5:47 AM, "Bertrand Delacretaz" wrote:
>On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
>> ...If you feel it should be changed anyway, I have no objections to
>>that...
>
>I havent checked if allowing vetoes for many things has caused
>problems or not so far but I see a potential for c
Question: Can you “un-delete” a deleted branch in case we find later there
is something in one of them that we need? Also, other than a smaller list
of branches, what else does it save us? Does it make the repo smaller?
-Alex
On 12/4/14, 5:11 AM, "Erik de Bruin" wrote:
>No worries. If you int
On 12/4/14, 5:08 AM, "Erik de Bruin" wrote:
>You should take a look at FalconJX (same repo as Falcon): it is
>designed specifically to be a cross-compiler that can compile to
>various output languages. It sounds to me you are trying to re-invent
>the wheel by starting from Falcon. FalconJX curr
BTW is there any plans to support things like Margin in the Flex SDK since they
can't be native in the JS anyways?
-Mark
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Thursday, December 04, 2014 1:06 PM
To: dev@flex.apache.org
Subject: Re: Porting To Typescript/Java
I want to make sure that I bug I raised in tlf is reproducible in the
nightly source. I've never tried making the source sdk the current sdk
before, and it's proving much more difficult than I thought. Here's
what I did:
>ant release (in main sdk folder)
after finally figuring out that I need a cf
Not really, I'm afraid. I did just rewrite the README to make the
process feel a bit more logical and structured. Have you looked at
that? Or is that what's causing your troubles? In which case I'd be
interested to know which steps led to the issues you see, and how you
solved them.
Thanks,
EdB
On 12/4/14, 10:25 AM, "Kessler CTR Mark J"
wrote:
>BTW is there any plans to support things like Margin in the Flex SDK
>since they can't be native in the JS anyways?
FlexJS containers do support both margin and padding, although I’ll bet
there are bugs in the current code. That’s part of my
Mihai, are you working from a source release artifact or from the repos?
While it is informative if you are having trouble following the
instructions to work from a source release, since you are a committer, it
would be best if you are working from the repos as then you can just check
in a fix.
-A
The best way I know of is to point FB to a version of the SDK created by
the Flex Installer. Then, add flex-sdk\frameworks\projects\ as Flex
library projects in the same workspace. Then, in your test application,
add the library projects as a 'Project dependency'. This way, you can
continue
Cool, thanks! SVN is down right now. I will work on it after INFRA give
us a go ahead.
Thanks,
Om
On Thu, Dec 4, 2014 at 5:48 AM, Erik de Bruin wrote:
> +1
>
> Time we start giving the FlexJS effort some visibility on the website
> anyway.
>
> EdB
>
>
>
> On Wed, Dec 3, 2014 at 9:13 PM, OmPra
Sounds good, thanks Alex. Sounds like a new namespace down the road of more
aligned / streamlined components.
-Mark
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Thursday, December 04, 2014 1:33 PM
To: dev@flex.apache.org
Subject: Re: Porting To Typescript/Javascri
Thanks for the promptitude guys.
Alex, I am working from the repos indeed.
Erik, thanks for the pointer. I'm just running ant
-Dbuild.number=20141204 -Dbuild.noprompt=release, and then following
the next steps; let's see if that helps.
Om, I think I tried that a while ago and got int
On 12/4/14, 10:47 AM, "Kessler CTR Mark J"
wrote:
>Sounds good, thanks Alex. Sounds like a new namespace down the road of
>more aligned / streamlined components.
Yes, actually, many namespaces. FlexJS doesn’t want to have one component
library or even two (like Spark and MX). It hopes to be
>
> Om, I think I tried that a while ago and got into a lot of trouble
> because those projects in the 'frameworks/projects' folder had so many
> dependencies and custom compilation flags, etc. I'm glad you could get
> it to run, but I'd like to make the current source a working SDK for
> the IDE.
On Thu, Dec 4, 2014 at 10:56 AM, Alex Harui wrote:
>
>
> On 12/4/14, 10:47 AM, "Kessler CTR Mark J"
> wrote:
>
> >Sounds good, thanks Alex. Sounds like a new namespace down the road of
> >more aligned / streamlined components.
>
> Yes, actually, many namespaces. FlexJS doesn’t want to have one
>Question: Can you “un-delete” a deleted branch in case we find later there is
>something in one of them that we need? Also, other than a smaller list of
>branches, what else does it save us? Does it make the repo >smaller?
Alex-
Branches are really just a pointer to a commit in the repo. So
Almost all the projects there have the .actionScriptProperties and
.flexLibProperties. So, just importing it as an existing project into FB
will ensure that the correct config files and compiler directives are
added.
Thanks,
Om
On Thu, Dec 4, 2014 at 10:58 AM, OmPrakash Muppirala
wrote:
> Om,
Update: running ant -Dbuild.number=20141204 -Dbuild.noprompt=release
failed at the PackageMXP target in
frameworks\projects\flash-integration\build.xml:159 with this as the
only information:
___
FlashMXP:
[echo] ADOBE_EXTENSION_MANAGER is c:\Program Files
Dbuild.number=20141204 -Dbuild.noprompt=release
>failed at the PackageMXP target in
>frameworks\projects\flash-integration\build.xml:159 with this as the
>only information:
>
>___
>FlashMXP:
> [echo] ADOBE_EXTENSION_MANAGER is c:\Program Fi
FWIW, The way I work, is by adding textLayout as a library project to FB. I
take care to never actually build it in FB. I always build it using ant. I’ve
found without adding lextLayout to Flash Builder, I cannot use the features
like jumping to code, and the like.
I then add the binary in the
Update: after commenting out the PackageMXP target, the "ant
-Dbuild.number=20141204 -Dbuild.noprompt=release" command worked, but
the compilation fails with the same error: "The definition of base
class Error was not found."
Alex, after that I also did an "ant main&qu
On 4 December 2014 at 20:12, Mihai Chira wrote:
> Update: after commenting out the PackageMXP target, the "ant
> -Dbuild.number=20141204 -Dbuild.noprompt=release" command worked, but
> the compilation fails with the same error: "The definition of base
> class Error was not fou
task. But now that the AIR sdk seems to be all right
>too, I still get the same error when compiling with IntelliJ.
>
>So is everyone doing it the import projects way, then?
>
>On 4 December 2014 at 20:12, Mihai Chira wrote:
>> Update: after commenting out the Packag
Hi,
> So is everyone doing it the import projects way, then?
I don't. I import the whole SDK as a general project (under new project) and
just use ant to compile.
Justin
> Done. I've also marked up what I think the issues are with this approach.
I’ve responded to all the issues with my point of view.
Thanks,
Harbs
I think I’ve edited the page to take care of Justin’s concerns without it being
too “in your face”…
On Dec 4, 2014, at 3:47 PM, Erik de Bruin wrote:
> You are actively discouraging non-PMC members to participate in the
> release process by repeatedly explaining how their votes are worth
> nothi
Hi,
> I think I’ve edited the page to take care of Justin’s concerns without it
> being too “in your face”…
I'm not sure of removal of any reference to the PMC is correct, only PMC
members votes are binding on releases.
Thanks,
Justin
That’s the “small print” on the bottom. If someone does not know what a vote
is, they can read the link. It’s all explained in detail.
On Dec 4, 2014, at 11:00 PM, Justin Mclean wrote:
> Hi,
>
>> I think I’ve edited the page to take care of Justin’s concerns without it
>> being too “in your f
On Thu, Dec 4, 2014 at 1:00 PM, Justin Mclean
wrote:
> Hi,
>
> > I think I’ve edited the page to take care of Justin’s concerns without
> it being too “in your face”…
>
> I'm not sure of removal of any reference to the PMC is correct, only PMC
> members votes are binding on releases.
>
>
There is
Hi,
> You are actively discouraging non-PMC members to participate in the
> release process by repeatedly explaining how their votes are worth
> nothing.
Really? I had added "although others are also encouraged to vote." and only PMC
votes are binding on releases, we shouldn't state otherwise.
Well I would like to have Apache Flex BlazeDS instead of the Adobe version, but
I doubt that we would be able to ship that prior to Flex 4.14 :-(
Could anyone here specify what's actually preventing us? From Alex' last post I
was in the impression that the objections he had were actually more th
Hi,
> There is a link to
> http://www.apache.org/foundation/glossary.html#MajorityApproval which has
> the correct definitions.
It exmplain what "Majority Approval" is but not that only PMC vote are binding.
Perhaps a solution is to add a link to our own guidelines with a link to voting
on rele
Justin, it is not clear whose email you are responding to. Can you please
clarify?
Thanks,
Om
On Thu, Dec 4, 2014 at 1:12 PM, Justin Mclean
wrote:
> Hi,
>
> > You are actively discouraging non-PMC members to participate in the
> > release process by repeatedly explaining how their votes are w
On Thu, Dec 4, 2014 at 1:14 PM, Justin Mclean
wrote:
> Hi,
>
> > There is a link to
> > http://www.apache.org/foundation/glossary.html#MajorityApproval which
> has
> > the correct definitions.
>
> It exmplain what "Majority Approval" is but not that only PMC vote are
> binding. Perhaps a solution
Hi,
> For some context, the reason our guidelines require consensus for adding
> people is because of this document [1]
And also was inline with other project Guidelines we looked at.[1]
We actually relaxed some of the HTTP projects guidelines ie only PMC members
can veto code changes (we allow
+1
On 4 December 2014 at 18:39, OmPrakash Muppirala wrote:
> Cool, thanks! SVN is down right now. I will work on it after INFRA give
> us a go ahead.
>
> Thanks,
> Om
>
> On Thu, Dec 4, 2014 at 5:48 AM, Erik de Bruin wrote:
>
>> +1
>>
>> Time we start giving the FlexJS effort some visibility o
Hi,
> No need for a solution since there is no problem. What exactly is the
> issue you are trying to solve? Who do you think needs this clarification?
Currently as it reads is that votes on release are "Majority Approval", that's
correct/good but not the whole picture. If a committer or user
On Dec 5, 2014, at 12:43 AM, Justin Mclean wrote:
> IMO would be a good idea to make it clear.
What’s not clear about the following?
The Small Print
All votes mentioned on this page are as defined on the official voting page
here[1].
[1]http://www.apache.org/foundation/voting.html
On 12/4/14, 2:43 PM, "Justin Mclean" wrote:
>Hi,
>
>> No need for a solution since there is no problem. What exactly is the
>> issue you are trying to solve? Who do you think needs this
>>clarification?
>
>Currently as it reads is that votes on release are "Majority Approval",
>that's correct
Hey everyone,
I made a minor edit to the small print to include a note that PMC votes are
counted as binding. Hopefully that completes the definition of "Majority
Approval" for our group.
I welcome any edits to the above, as I'm still the new guy here ;)
Also made my replies to the numbered iss
> I made a minor edit to the small print to include a note that PMC votes
are counted as binding. Hopefully
> that completes the definition of "Majority Approval" for our group.
Well that was fast. Hehe, so I thought the "here" link was pointing to the
definition of "Majority Approval", not the
Hi,
> Are you referring to this post? [1]
Yes.
> The poster just thought that non-binding meant he voted against the
> release, not whether his vote counted or not.
My reading of that post was that he assumed his +1 counted and was surprised
when it didn't and was saying "but I voted for it wh
On Thu, Dec 4, 2014 at 4:19 PM, Justin Mclean
wrote:
> Hi,
>
> > Are you referring to this post? [1]
>
> Yes.
>
> > The poster just thought that non-binding meant he voted against the
> > release, not whether his vote counted or not.
>
> My reading of that post was that he assumed his +1 counted
Hi,
> You interpreted it wrong. That voter thought non-binding meant a -1 vote.
> Please read that email carefully.
I don't think so, but either way, it shows the need for clarity around who's
votes are binding. I notice the link was edited in the Wiki to include all the
content and not just l
On Thu, Dec 4, 2014 at 4:52 PM, Justin Mclean wrote:
> Hi,
>
> > You interpreted it wrong. That voter thought non-binding meant a -1
> vote.
> > Please read that email carefully.
>
> I don't think so, but either way, it shows the need for clarity around
> who's votes are binding. I notice the li
I've been meaning to donate more projects that I use to help with Flex /
AIR development so to do that I'd like to make people aware of Command Line
User Interface or CLUI. It's an AIR application that takes a command line
statement and creates a user interface / form out of it. This makes it
easie
Hi,
On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui wrote:
> ...the reason our guidelines require consensus for adding
> people is because of this document [1] and some advice from other
> experienced non-Flex Apache people that having consensus for adding folks
> is important...
I agree if consensus
On Thu, Dec 4, 2014 at 6:12 PM, Alex Harui wrote:
> ...we decided to add a new “all caps” file called
> “CONTRIBUTING" to our release packages. In examining the package, I found
> the file was misspelled as “CONTRIBITING” and felt that because it was in
> the top-level listing it would be worth s
Hi,
> That's why I recommend following the standard Apache rules and
> recommendations. at [1] And also, as I said, because Flex is a
> relatively small PMC that can save energy by just sticking to the ASF
> standard things, without having to spend much time discussing its own
> variants.
I'm int
Hi Bertrand,
> So it's back to the discussion about vetoes being harmful.
I don’t understand why you keep coming back to this point. No one (besides
Justin) ever suggested that releases could be vetoed.
On Dec 5, 2014, at 8:50 AM, Bertrand Delacretaz wrote:
> On Thu, Dec 4, 2014 at 6:12 PM, A
Justin,
Could you please show us where this “standard release process” is documented,
and explain how we are somehow deferring from this “standard”?
Thanks,
Harbs
On Dec 5, 2014, at 9:12 AM, Justin Mclean wrote:
> Hi,
>
>> That's why I recommend following the standard Apache rules and
>> rec
Hi,
On Fri, Dec 5, 2014 at 8:15 AM, Harbs wrote:
>> ...So it's back to the discussion about vetoes being harmful.
>
> I don’t understand why you keep coming back to this point. No one (besides
> Justin)
> ever suggested that releases could be vetoed...
Ah sorry, I seemed to recollect
https://cw
88 matches
Mail list logo
