Hi,
> This is again a case of misleading characterization of the issue in hand.
Sorry I don't believe it is.
The board requires oversight on releases and that means Majority Approval (ie 3
binding +1 votes) the release only had 2 +1 binding votes. In this case it
could be called into question
On Dec 5, 2014 8:36 AM, "Michael A. Labriola"
wrote:
>
> >In case you want to dig into (what I didn't do), this is the code [1],
indeed, an explanation from M.Labriola or Roland would be welcome :-)
>
> Happy to answer questions as they come up.
Thanks, Mike!
A couple of questions to start with:
Jesse,
The one thing that really terrifies me is that potential contributors like
you stay away from the project for reasons like these. I hope we did not
make a terrible first impression and that you would stick to us and see
where we all land up. Hopefully in a good place :-)
Thanks,
Om
On F
> In fact, I did take the time to properly examine the artifacts and vote on
> that RC. One of the reasons I did that was to make it more likely that
> folks like Om who may not have the time to re-examine the artifacts would
> feel more comfortable allowing a carryover of their vote. The only tw
On 12/5/14, 11:22 AM, "OmPrakash Muppirala" wrote:
>On Fri, Dec 5, 2014 at 11:11 AM, Rich Bowen wrote:
>
>>
>>
>> On 12/05/2014 07:59 AM, Justin Mclean wrote:
>>
>>> Being the RM and making a release has a legal responsibility. I don't
>>> think we should be forcing the RM to be doing anything
> release scripts before releasing the SDK. My latest idea was that we
> could avoid the logistics of a BlazeDS release simply by bundling enough
> BlazeDS source and the jar the way we do for TLF.
+1 on trying the "TLF" style option first. That seems "doable" in a
reasonalble timeframe...
EdB
On Fri, Dec 5, 2014 at 11:11 AM, Rich Bowen wrote:
>
>
> On 12/05/2014 07:59 AM, Justin Mclean wrote:
>
>> Being the RM and making a release has a legal responsibility. I don't
>> think we should be forcing the RM to be doing anything that has potential
>> legal issues. The incident that this VO
Hi Om,
Thanks for letting me know that IBM is controlling flex. Lol, kidding :)
Thanks for the very detailed response. It seems I missed some information
on the site and will have to review. I suppose its just a general mistrust
of adobe. No offence to anyone. Yes adobe open sourced it, that's gr
On 12/05/2014 07:59 AM, Justin Mclean wrote:
Being the RM and making a release has a legal responsibility. I don't think we
should be forcing the RM to be doing anything that has potential legal issues.
The incident that this VOTE has arisen from was about changing NOTICE and then
making a
Thanks for your comments on this. Speaking of joining in, Ill come back
when I'm finished my own project to see if it can be put to use for flex js.
On 5 Dec 2014 13:28, "Alex Harui" wrote:
> I changed the subject. It is interesting to hear your view point, and
> warrants addressing in case othe
Jesse,
You are indeed raising very valid questions. I am moving this to a
separate thread so we don't continue to pollute that other vote thread.
The question you are raising is something that we have assumed to have been
answered and put to rest. So, I will try to respond to it from your
persp
I changed the subject. It is interesting to hear your view point, and
warrants addressing in case others have the same impression.
On 12/5/14, 10:04 AM, "Jesse Nicholson" wrote:
>>
>> Anyway yes I do have genuine concerns about corporate independence. Your
>> profile says that you work for Adob
On 12/5/14, 8:54 AM, "Jason Moore" wrote:
>
>Is there something special about the WindowedApplication.as ... is it
>overridden somewhere in the build?
Can you provide more details on your workflow? Are you using an IDE or
Ant? You change WindowedApplication.as in what folder? How do you poin
If I understand you, we still have to go through a full release cycle so
that the Maven artifacts are in Maven Central and not in some staging
repo? I’m concerned that the BlazeDS release cycle may take longer that
we’d like. But definitely, keep moving forward on a BlazeDS release.
If we can g
I'll stop emailing on this thread, my apologize to people for the unrelated
messages that have come through.
On Fri, Dec 5, 2014 at 12:58 PM, Jesse Nicholson wrote:
> My intention wasn't to hurt anyone. As a grown up, I'm open to
> conversations where subject matter isn't all sunshine and lolipo
My intention wasn't to hurt anyone. As a grown up, I'm open to
conversations where subject matter isn't all sunshine and lolipops without
taking it personally. :) I was just giving my first impressions, which I
think were legitimate since 90% of the messages coming in so far was
arguing over the re
This code works for me (by scaling a group). I leave it you to determine
a suitable calculation for newScale value. Custom runtimeDPIprovider not
needed as default returns 160 (which is fine)
http://ns.adobe.com/mxml/2009";
xmlns:s="library://ns.adobe.com/flex/spark"
xml
One of the reasons Justin may think we have trouble getting enough votes
is because of another interesting dynamic in Flex. When someone votes -1
on an RC because they found what they think is an important bug, folks
tend to stop testing and voting. I’ve actually tried not voting -1 and
simply as
I havent tested it but a possible workaround would be to avoid flex
scaling completely and write your own... either set stage.scaleX/Y as
appropriate (or maybe you will need to put all your content inside a
group and scale the group).
Having said that, the more i think about it, i'm not sure s
On Fri, Dec 5, 2014 at 5:25 PM, Jesse Nicholson
wrote:
> ...many of the leads here seem to double as adobe
> employees... which makes me feel that this is still very heavily controlled
> and owned by adobe for their own corporate interests
I suppose you did not realize how that kind of statem
Before you cut the release branch, I (or someone) does need to update the
install config. I think making the BlazeDS code usage like the TLF
pattern is not hard, but also will affect the install config.
If nobody else is willing to take on those tasks, I’ll do them, but before
I get to that, I wa
Yeah, I think having the proposed language would help me cast a vote. I
feel Justin brings up a good thought. Maybe we'd say that PMC votes cannot
carry over their votes since there was a severe issue with the previous RC?
Here's a suggested change block to the 'less-RC' [1] wiki page in the "RC
+1 binding
On Dec 5, 2014 4:58 AM, "Frédéric THOMAS" wrote:
> +1 (Binding)
> Frédéric THOMAS
Thank you for your feedback. Always good to get an community opinion with an
outside perspective.
-Mark
-Original Message-
From: Jesse Nicholson [mailto:ascensionsyst...@gmail.com]
Sent: Friday, December 05, 2014 11:25 AM
To: dev@flex.apache.org
Subject: Re: [VOTE] Allow RC votes to car
Hi All,
I submitted a bug to the Jira system around how the application scaling using
applicationDPI for desktop Air Apps seems to be broken. I've included
screenshots, example code etc.. so I won't go into detail here, if you're
interested and can help please do have a look.
https://issues.ap
Bertrand was referring to the previous language on the guidelines wiki
page. After him bringing it up and many of us saw the problem with that as
well, Erik adjusted the page [1] on Dec 1 to switch from "Consensus" to
"Majority Approval".
[1]
https://cwiki.apache.org/confluence/pages/diffpagesbyv
>In case you want to dig into (what I didn't do), this is the code [1], indeed,
>an explanation from M.Labriola or Roland would be welcome :-)
Happy to answer questions as they come up.
Mike
I just have to say as a new member here looking to possibly get involved,
that all of this back and forth arguing over the release process and all
the terror of the legality of changing things really makes for a terrible
first impression. I'm pretty discouraged about any participation. Between
the
I'll have some time this weekend to look at this a bit.
-Darrell
On Thu, Dec 4, 2014 at 3:29 AM, Héctor A wrote:
> 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 determ
Please remove me from this maillist
2014-12-05 14:10 GMT+00:00 Oleg Konovalov :
> Hi,
>
> Is there an easy way of showing tooltip on "folder" level
> when you use ADG with GroupingCollection2.
>
> if I use tooltip="{myGC.field1}" in ADG,
> getting error 1119: access to possibly undefined propert
Hi,
Is there an easy way of showing tooltip on "folder" level
when you use ADG with GroupingCollection2.
if I use tooltip="{myGC.field1}" in ADG,
getting error 1119: access to possibly undefined property field1 through
reference with static
type GroupingCollection2.
Using Flex 4.5.1
--
Thank
> ... without much discussion ...
LOL
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Hi,
-1 (binding)
To change the guidelines it would be better to propose a vote with actual word
changes to the guidelines, but that's not why I'm voting -1.
Being the RM and making a release has a legal responsibility. I don't think we
should be forcing the RM to be doing anything that has pot
+1 (Binding)
Frédéric THOMAS
On 05/12/14 12:29, Erik de Bruin wrote:
As a side note: PMC members should really add " (binding)" to their
votes. That will save the vote caller the trouble of having to look up
each individual's status when calling the result.
I didn't know this and I'm on the PMC :-)
I've noted it on as this
That's true for me. If it's got enough votes to pass, by people I trust,
and I'm really busy, then I wont test it myself, or it I do it wont be
formally enough to be worth a +1
Tom
On 05/12/14 12:14, Erik de Bruin wrote:
I think what we've seen is that all VOTEs get just enough votes to
pass
Valdemar,
Send an email to [1] to remove yourself from this list. There is a better
description here of the lists and their subscriptions [2].
[1] dev-unsubscr...@flex.apache.org
[2] http://flex.apache.org/community-mailinglists.html
-Mark
-Original Message-
From: Valdemar Lopes [m
You can remove yourself from the list:
Subscribe: dev-subscr...@flex.apache.org
Post (after subscription): dev@flex.apache.org
Unsubscribe: dev-unsubscr...@flex.apache.org
Subscribe to digest: dev-digest-subscr...@flex.apache.org
Unsubscribe to digest: dev-digest-unsubscr...@flex.apache.org
On De
+1 (Binding)
Redone for clarity in vote counting.
-Mark
-Original Message-
From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil]
Sent: Friday, December 05, 2014 7:22 AM
To: dev@flex.apache.org
Subject: RE: [VOTE] Allow RC votes to carry over at any point in the release
process
+1
Please remove me from this list
2014-12-05 12:21 GMT+00:00 Kessler CTR Mark J :
> +1
>
> I like the idea. Barring we do not allow new features to be added in
> between RC's.
>
> -Mark
>
> -Original Message-
> From: Harbs [mailto:harbs.li...@gmail.com]
> Sent: Friday, December 05, 2014 5:
As a side note: PMC members should really add " (binding)" to their
votes. That will save the vote caller the trouble of having to look up
each individual's status when calling the result.
Thanks,
EdB
On Fri, Dec 5, 2014 at 1:24 PM, Erik de Bruin wrote:
>> I like the idea. Barring we do not
> I like the idea. Barring we do not allow new features to be added in between
> RC's.
The 'less-RC' proposal is very explicit about this: no new features in
the RCs, to be more specific: no new features in the release after the
release branch has been cut.
EdB
--
Ix Multimedia Software
Ja
+1
I like the idea. Barring we do not allow new features to be added in between
RC's.
-Mark
-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com]
Sent: Friday, December 05, 2014 5:56 AM
To: dev@flex.apache.org
Subject: [VOTE] Allow RC votes to carry over at any point in the rel
I think what we've seen is that all VOTEs get just enough votes to
pass because once enough passing votes are in, people choose to spend
the little time they have available for the projects on something
else.
3 votes are enough for a release, and I don't think we have to be
afraid of not reaching
Please remove me from this list.
2014-12-05 12:00 GMT+00:00 Bertrand Delacretaz :
> On Friday, December 5, 2014, Jeffry Houser wrote:
>
> > ...Could part of the problem we have too many projects under the Apache
> Flex banner?
> > Do other Apache projects have 9+ completely separated, but relate
+1
If I've checked that something is OK, I generally don't want to check it
again just because it was re-rolled to fix something I didn't notice the
first time.
Sometimes it is hard enough getting time to test one release, never mind
essentially the same one several times a week.
Tom
On 0
On Friday, December 5, 2014, Jeffry Houser wrote:
> ...Could part of the problem we have too many projects under the Apache
Flex banner?
> Do other Apache projects have 9+ completely separated, but related,
projects?...
The key is not how many modules you are managing but whether those belong
to
Actually as soon as the maven artifacts are out the change would be to change
the ulr for the jar and evtl. remove some license ant stuff, cause then we
don't need to ask anyone anymore ... Hopefully resolving one problematic
download for the installer :-)
Chris
Gesendet mit meinem HTC
-
On 12/5/2014 4:18 AM, Justin Mclean wrote:
most of the recent (last 6 months) Squiggly, Tour De Flex, FlexJS, Falcon
releases have only have 3 or 4 votes each. (If you need links just ask).
Could part of the problem we have too many projects under the Apache
Flex banner?
Do other Apache pro
It does get to be quite a few emails some times. Send an email to [1] to
remove yourself from this list. There is a better description here of the
lists and their subscriptions [2].
[1] dev-unsubscr...@flex.apache.org
[2] http://flex.apache.org/community-mailinglists.html
-Mark
-Original
+1 (binding)
The RM should treat an explicit statement indicating the wish to carry
over a vote the same as voting again.
EdB
On Fri, Dec 5, 2014 at 11:55 AM, Harbs wrote:
> I suggest that at any point in the release process a vote should be carried
> over if the person voting indicates they
I suggest that at any point in the release process a vote should be carried
over if the person voting indicates they wish the vote should carry over.
+1
Harbs
Agreed.
I think this discussion has gone on long enough. Time to stop trying
to convince each other, as that obviously is not going to happen.
Is there something here that can be resolved by a vote? If so, please
start a VOTE thread.
Otherwise let's end this discussion and move on.
Thanks,
EdB
On Fr
Again, you seem to have a different definition of “should”[1]. Nowhere does it
state that if you do not mention it when you start the thread, the votes can
not carry over.
Of course it’s the RM’s choice. No one has stated that Om’s vote was valid if
you refused to carry it over. You said you CO
Please remove me from this list.
2014-12-05 10:39 GMT+00:00 Harbs :
> On Dec 5, 2014, at 11:18 AM, Justin Mclean
> wrote:
>
> > Being the release manager many time I can say that getting 3 or 4 vote
> is hard.
>
> The point of the “less RC” process it to try to make it easier on everyone
> to pa
Hi,
>> As per our guidelines the votes need to be carried other in the VOTE for the
>> RC and I didn't do that.
>
> That’s simply not true.
Yes it is: [1]
"When voting on release candidates the release manager at their discretion can
carry over votes from the previous release candidate if ther
On Dec 5, 2014, at 11:18 AM, Justin Mclean wrote:
> Being the release manager many time I can say that getting 3 or 4 vote is
> hard.
The point of the “less RC” process it to try to make it easier on everyone to
participate, so the hope is that this will improve over time. If getting votes
is
On Dec 5, 2014, at 11:28 AM, Justin Mclean wrote:
> As per our guidelines the votes need to be carried other in the VOTE for the
> RC and I didn't do that.
That’s simply not true.
A vote can be carried over if the person who voted requested it should be
carried over. It was stated by numerou
Hi,
> Om did ask his vote to be carried over, repeatedly and explicitly.
As per our guidelines the votes need to be carried other in the VOTE for the RC
and I didn't do that. I would of had to cancel that RC and make another one in
order to carry over votes. If it was a change to a read me or s
> Ok, I didn't study the details but I agree that you cannot carry over
> votes from one release candidate to the next, for example, without
> voters individually and explicitly indicating that you can do so. This
Om did ask his vote to be carried over, repeatedly and explicitly.
http://markmail.
HI,
> In this particular instance, Justin decided to discard 2 votes instead of
> carrying them over
As I (not unreasonably IMO) thought that changes to a NOTICE file required PMC
overview before making a release. But even with those 2 votes were counted
there were only 4 votes. The final rele
On Fri, Dec 5, 2014 at 10:07 AM, Justin Mclean wrote:
>> ...Does this PMC have trouble getting 4 people voting on a release?
> Yes, sometimes it hard to get 3 or 4 votes
Ok, so that's something that this PMC should eventually fix - either
by electing more deserving PMC members, or convincing
On Fri, Dec 5, 2014 at 10:01 AM, Erik de Bruin wrote:
> ...In this particular instance, Justin decided to discard 2 votes instead
> of carrying them over, which the majority of the participating PMC
> members were advocating...
Ok, I didn't study the details but I agree that you cannot carry over
Hi,
> Does this PMC have trouble getting 4 people voting on a release?
Yes, sometimes it hard to get 3 or 4 votes.
> Either there's not enough active PMC members
That's certainly part of it.
Justin
> If you guys have trouble getting 4 voters, something's wrong. Either
In this particular instance, Justin decided to discard 2 votes instead
of carrying them over, which the majority of the participating PMC
members were advocating. He put himself in the position he's now
complaining about.
EdB
Hi,
On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean wrote:
> ...The process is described here [1] which references [2] and
> best practise described here [3]...
Apart from not having vetoes on release votes, the only things that
the ASF requires about releases are captured in this excerpt from [1]
Or better yet (sorry for not grokking the rest of your email, Alex),
how long would it take to have the SDK build use the parts of BlazeDS
in a similar fashion to what is already in place for TLF?
EdB
On Fri, Dec 5, 2014 at 9:45 AM, Erik de Bruin wrote:
> I would love to delay the release, hav
I would love to delay the release, having Apache Flex BlazeDS is an
excellent addition. How much time will we need to make a BlazeDS
release happen?
EdB
On Fri, Dec 5, 2014 at 9:25 AM, Alex Harui wrote:
> I’m all set to try to release Apache Flex BlazeDS. Some customer
> complained about Blaz
Justin,
This shows you do not understand the 'less-RC' process. The major
difference between current and 'less-RC' is in the period leading up
to the creation of the first RC. The process once the first RC has
been posted and a vote has been started is the same and therefore
remains in accordance
In case you want to dig into (what I didn't do), this is the code [1], indeed,
an explanation from M.Labriola or Roland would be welcome :-)
Frédéric THOMAS
[1] https://github.com/RandoriAS/randori-tools
> From: bigosma...@gmail.com
> Date: Thu, 4 Dec 2014 11:00:27 -0800
> Subject: Re: Porting T
None of the links you provided describe anything to do with how a progression
towards a release should work. It only described the release process itself.
Nor do they describe how discussions should work. (Not should they.)
I’m not sure what these “several bits” that you refer to are. The one th
I’m all set to try to release Apache Flex BlazeDS. Some customer
complained about BlazeDS not working with more recent Tomcat versions, but
I’d say we make the first BlazeDS release more about parity with the Adobe
version and save handling newer Tomcat versions for later.
The main issue I think
Hi,
> Could you please show us where this “standard release process” is documented,
> and explain how we are somehow deferring from this “standard”?
The process is described here [1] which references [2] and best practise
described here [3] and there is a work in progress with clearer MUSTs and
The wiki page had become annotated with issue discussions. I just rewrote
the entire document, trying to make it shorter, removing history and
rationale and just describing the steps, but addressing/clarifing issues
raised. I left the original document below so you can compare and make
sure your
75 matches
Mail list logo
