Re: [TLF] merge 'tables' into 'develop'

On Nov 26, 2014 11:42 PM, "Harbs" wrote: > > You can feel free to do the merge. > > I’ll switch to develop once you do. It would be a good idea to first merge develop into tables and make sure everything compiles fine. And then merge tables into develop. Thanks, Om Thanks, Om > > On Nov 27, 2

Re: [TLF] merge 'tables' into 'develop'

You can feel free to do the merge. I’ll switch to develop once you do. On Nov 27, 2014, at 8:34 AM, piotrz wrote: > Erik, Harbs I've changed my mind and I think we shouldn't bother about this > one failing test for now and merge everything into the develop branch. > > Harbs will you do this or

Re: [TLF] merge 'tables' into 'develop'

Erik, Harbs I've changed my mind and I think we shouldn't bother about this one failing test for now and merge everything into the develop branch. Harbs will you do this or do you want me to do this ? Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http:

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

Justin, This discussion is about the particular change that is explained in the vote. Any discussion about other changes should be in another thread, so we don't cloud the issue at hand and needlessly drag out this discussion. Both sides gave laid out their arguments. It is now time to vote. EdB

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

Hi, >> This message [1] from you appears to say that the default is consensus. Because it is what is specified on most non release votes we have taken ie appointing committers or PMC members. A couple of votes were specified differently eg voting in the guidelines (2/3rds Majority Approval) and

Re: [VOTE] modify project bylaws: default to Majority Approval for votes

+1 On 11/26/14, 2:22 AM, "Harbs" wrote: >+1 >

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

On 11/26/2014 04:24 PM, Alex Harui wrote: On 11/26/14, 12:37 PM, "Justin Mclean" wrote: Hi, https://cwiki.apache.org/confluence/display/FLEX/Guidelines says the default is "consensus" It's not the default as such but more a safety net to what is used if the type of vote isn't specified i

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

On 11/26/14, 12:37 PM, "Justin Mclean" wrote: >Hi, > >> https://cwiki.apache.org/confluence/display/FLEX/Guidelines says the >>default is "consensus" > >It's not the default as such but more a safety net to what is used if the >type of vote isn't specified in the VOTE email or covered by any of t

Re: [TTH] on the "international English" issue

Hi, > What, in your opinion, would adequately resolve this apparent catch-22? Well the ideal solution would to have more PMC involvement on release votes, but I've no good ideas how to encourage PMC members to vote on releases. Thanks, Justin

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

Hi, > https://cwiki.apache.org/confluence/display/FLEX/Guidelines says the default > is "consensus" It's not the default as such but more a safety net to what is used if the type of vote isn't specified in the VOTE email or covered by any of the other guidelines (ie very rarely). It's only be

Re: [VOTE] TourDeFlex 1.2 Release Candidate 2

+1 Package https://dist.apache.org/repos/dist/dev/flex/TourDeFlex/1.2/rc2/apache-flex- tour-de-flex-component-explorer-1.2-src.zip Java 1.6 OS: Windows Vista x86 6.1 Source kit signatures match: y Source kit builds: y README is ok: y RELEASE_NOTES is ok: y NOTICE is ok: y LICENSE is ok: y No unapp

Re: [TTH] on the "international English" issue

On 11/26/14, 2:57 AM, "Justin Mclean" wrote: >Hi, > >> Nowhere in the bylaws (that I can find) does it say that spelling >> issues in documentation are release blockers. > >!00% correct and I'm against it. > >> If someone said they should be, that would be an opinion. > >Also correct , but: >a)

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

... and we're already 4 emails in a thread that shouldn't even exist :-( For the people (especially PMCs) not keeping up with the other conversations currently going on, I'll summarize (summarise?) what prompted this VOTE: Bertrand Delacretaz, one of our former mentors and a Apache Board member,

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

On Wed, Nov 26, 2014 at 2:35 PM, Erik de Bruin wrote: > "As per Apache best practices and Bertrand's suggestion, I propose we > change the following line in our bylaws [...]"... IIUC this is based on my remark in another thread that http://www.apache.org/foundation/voting.html specifies that -1 o

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

"As per Apache best practices and Bertrand's suggestion, I propose we change the following line in our bylaws [...]" What is unclear about that? EdB On Wed, Nov 26, 2014 at 2:15 PM, Jeffry Houser wrote: > >> I think the introduction in the VOTE >> clearly states my reason for calling it. > >

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

I think the introduction in the VOTE clearly states my reason for calling it. I just reread your vote request and do not understand, nor see any reason for the change. I am left unsure what the issue is that brought this topic up; or what the implications are of the change are. Can yo

Re: [TTH] on the "international English" issue

What, in your opinion, would adequately resolve this apparent catch-22? EdB On Wed, Nov 26, 2014 at 11:57 AM, Justin Mclean wrote: > Hi, > >> Nowhere in the bylaws (that I can find) does it say that spelling >> issues in documentation are release blockers. > > !00% correct and I'm against it.

Re: [TTH] on the "international English" issue

Hi, > Nowhere in the bylaws (that I can find) does it say that spelling > issues in documentation are release blockers. !00% correct and I'm against it. > If someone said they should be, that would be an opinion. Also correct , but: a) With the new no RC process, (which IMO basically require co

Re: [DISCUSS] modify project bylaws: default to Majority Approval for votes

I intentionally didn't start a DISCUSS, given the whole discussion about long discussions ... I think the introduction in the VOTE clearly states my reason for calling it. EdB On Wed, Nov 26, 2014 at 11:44 AM, Justin Mclean wrote: > Hi, > > It is customary to call for a discussion before votin

Re: [TTH] on the "international English" issue

On Wed, Nov 26, 2014 at 11:43 AM, Erik de Bruin wrote: > ...That opinion might translate into > a -1 vote, but I just checked and that wouldn't amount to a veto for a > release I agree that releases cannot be vetoed. OTOH someone can technically veto a commit that introduces a spelling error

Re: [TTH] on the "international English" issue

Justin, > Most of the SDK (error messages and the like) are localised so there's > nothing that needs to be done there - other than keep it up to date and add > new locales where people can contribute. The current area of disagreement is > actually very small and if the spelling issues in READ

[DISCUSS] modify project bylaws: default to Majority Approval for votes

Hi, It is customary to call for a discussion before voting. Can I ask what you are trying at achieve here? This would only effect VOTES where the voting method is not specified, and that's quite rare. Off the top of my head I think it's only happened once in this project (and that was an acci

Re: [TTH] on the "international English" issue

Hi, Thanks for stepping to to helping out Bertrand, sorry you need to spend time on this. > My recommendation would be to find a technical solution to what is a rightful > community issue Most of the SDK (error messages and the like) are localised so there's nothing that needs to be done ther

Re: [VOTE] modify project bylaws: default to Majority Approval for votes

+1

[VOTE] modify project bylaws: default to Majority Approval for votes

Hi, As per Apache best practices and Bertrand's suggestion, I propose we change the following line in our bylaws [1] (under the heading 'Voting', 4th paragraph) from: "If the voting approval type is not specified and is not covered by these guidelines it defaults to Consensus." to "If the votin

Re: [TTH] on the "international English" issue

On Wed, Nov 26, 2014 at 10:30 AM, Erik de Bruin wrote: > ...can a vote also be (to > put it bluntly): "[VOTE] stop being pains in the project's buttocks > and leave the spelling/grammar issue well enough alone!"... A PMC can make their own rules on such things, but IMO the best way to end discuss

Re: [TTH] on the "international English" issue

Personally, I’m more comfortable with broader consistency (in website, etc.), but I’m fine with this. Since user facing text is all localized already, based on your suggestions, we can drop this whole discussion. Thanks, Harbs On Nov 26, 2014, at 11:45 AM, Bertrand Delacretaz wrote: > Hi, >

Re: [TTH] on the "international English" issue

Hi, On Wed, Nov 26, 2014 at 10:28 AM, Harbs wrote: > ...The way I understand your suggestion is like this: > We agree on variant “X” I would only care about localizing text that is visible when people run a Flex application - dialogs, error messages etc. As for everything else, that's eithe

Re: [TTH] on the "international English" issue

Very good question. I see having an agreed upon method of killing discussions as a very positive move. On Nov 26, 2014, at 11:30 AM, Erik de Bruin wrote: > A second question: would it be OK to call a vote to end a discussion? > In other words: does a vote always have to be about something tang

Re: [TTH] on the "international English" issue

A second question: would it be OK to call a vote to end a discussion? In other words: does a vote always have to be about something tangible - a paragraph in the Wiki, a release, etc. Or can a vote also be (to put it bluntly): "[VOTE] stop being pains in the project's buttocks and leave the spellin

Re: [TTH] on the "international English" issue

Just to use Alex’s division of items in an attempt to make things clear: 1) Release package documents: README, RELEASE_NOTES, LICENSE, NOTICE, CONTRIBUTING, etc. 2) API names (classes, properties, styles, etc) 3) ASDoc and JavaDoc comments (really, any comments that end up in user documentation) 4

Re: [TTH] on the "international English" issue

What is the Apache Way (tm) to 'agree to disagree'? When there are two opposing positions that are both right, but different enough not to be able to reach a compromise, what action might break the deadlock? A vote would result in one side 'losing', something we have been trying to avoid in this p

Re: [TTH] The old fart is back, aka let's fix this community ;-)

I second that. On Nov 26, 2014, at 11:17 AM, Erik de Bruin wrote: > "Thank you for helping out!"

Re: [TTH] The old fart is back, aka let's fix this community ;-)

Bertand, The situation has been getting out of hand a bit, and the project certainly can use some guidance and arbitration at the moment. Having said that, I'm sorry you have to spend time on this and hope that soon we'll have a consensus on how to handle the various situations/issues that seem t

Re: Build failed in Jenkins: flex-tlf #209

I see in the Flex Unit report this stack trace: Anyone know is this failure is the result of some latest changes pushed to TLF develop branch ? Thanks, Piotr 2014-11-26 7:51 GMT+01:00 : > See > >

[TTH] on the "international English" issue

Hi, I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a IMO that's a typical example where it's impossible to come up with a "right" solution...people have various levels of concern for that issue, ranging from exactly zero to "my customers say our stuff is crap when they see that"

[TTH] The old fart is back, aka let's fix this community ;-)

Hi Flex community, I had private discussions with both Justin and Alex in the last few days, and as a former incubation mentor of this project it saddens me to hear that you're having difficulties agreeing on things, so I'm back here to try and help. It's not uncommon in Apache projects to disagr