Hi,
> What in your mind is the difference between requesting to carry your vote and
> voting +1 (again)?
Requesting your previous vote is carried on may or may not mean you've checked
changes from the previous RC as described in the VOTE email (and if not IMO
there may be some doubt that it's
On Dec 6, 2014 9:13 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > You are doing it again :-)
>
> IMO It was a fairly accurate representation of the state of affairs. You
do realise when I write "PMC" I'm including myself? For instance look at
the amount of feedback from the the "test" RC of TourDeFlex
Hi,
I'm using a new 'tag': [RP] for Release Process related thread, to
make filtering easier.
I want to ask for ideas about the criteria for starting a release.
Everyone can be a Release Manager (RM) and start a release. A release
takes a significant amount of time from the community, and this
co
Hi Justin,
You only answered half my question. Sorry for asking again, but I’m really
trying to clarify if there’s even a difference of opinion here.
What in your mind is the difference between requesting to carry your vote and
voting +1 (again)?
Thanks,
Harbs
On Dec 7, 2014, at 12:58 AM, Jus
I would want Rich and/or Bertrand to confirm that you can in fact vote +1
without checking sigs and running the build and doing some sort of test,
but I would be surprised if anyone felt that you had to run the same tests
on RCN that you ran on RCN-1 if no code changed. On TDF, I doubt if any
vote
Hi,
> You are doing it again :-)
IMO It was a fairly accurate representation of the state of affairs. You do
realise when I write "PMC" I'm including myself? For instance look at the
amount of feedback from the the "test" RC of TourDeFlex (RC0) and then the
issues found in RC1 and RC2. Other r
Setting the itemRenderer goes thru the same error checking as any other
assignment statement so that why there is no special case error checking
code for IFactory. There is special handling for IFactory. For the inline
MXML assignment to itemRenderer the compiler generates a "new
ClassFactory()" an
On Dec 6, 2014 4:08 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > Here's my suggested release (non-) process.
>
> As far as I can see we been doing all of that with the old process [1]
with the exception that we usually make multiple RCs. Here's an example
JIRA for the 4.12 release. [2]
>
> So why mult
Hi,
> Here's my suggested release (non-) process.
As far as I can see we been doing all of that with the old process [1] with the
exception that we usually make multiple RCs. Here's an example JIRA for the
4.12 release. [2]
So why multiple RCs? The PMC usually puts off testing / checking thing
Hi,
> If the guidelines are clear, where does the need for RM's discretion arise?
The term non code change could be open to interpretation (and I recall has
been) so I'd prefer if that was left in. For instance is changing an xml config
file, a html file, or a build script considered a code cha
HI,
> Do I understand your position correctly? (i.e. you believe carried votes do
> not indicate that the voter is aware of the changes and affirms their vote
> still applies, and you believe one can (re)vote on a new RC without checking
> all artifacts)
You would only need to check what has c
Before we discuss what the guidelines say, I think we need to get our
definitions in sync.
Two really simple questions:
1) When someone asks to have their vote carried over, are they stating that
they know their previous vote is still valid? Yes or no?
2) When someone votes +1 on RC #1 and then
On Dec 6, 2014 2:04 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > When voting on release candidates the release manager at their
discretion
> > can carry over votes from the previous release candidate if there are
*non-code
> > related* changes between release candidates.
>
> I'd suggest going one step
Hi Justin,
It seems to me that the vote might just be the result of different
interpretations of carrying votes and we all agree on procedure but are using
different terminology.
Do I understand your position correctly? (i.e. you believe carried votes do not
indicate that the voter is aware of
Hi,
> When voting on release candidates the release manager at their discretion
> can carry over votes from the previous release candidate if there are
> *non-code
> related* changes between release candidates.
I'd suggest going one step further:
When voting on release candidates the release ma
On Sat, Dec 6, 2014 at 12:32 PM, Harbs wrote:
> If we’re wrong on the second point, then I think the entire discussion of
> carrying votes became moot, and we’ve spent an awful lot of time and energy
> on a non-issue.
>
> We can simply state that to vote on a new RC one either needs to recheck
>
If we’re wrong on the second point, then I think the entire discussion of
carrying votes became moot, and we’ve spent an awful lot of time and energy on
a non-issue.
We can simply state that to vote on a new RC one either needs to recheck all
artifacts of the RC or be confident that their origi
Me too, but something Bertrand said about typing +1 is quicker than typing
carryover made me wonder if we are correct. I'm hoping when Bertrand catches up
on these threads he'll see my question to him about this and clarify.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Erik de Bruin
I understood the issue the same way.
EdB
On Saturday, December 6, 2014, Harbs wrote:
> I don’t want to prolong discussion, but I think there’s one point which
> needs to be clarified:
>
> Discussion in the VOTE thread made me realize that there might be a
> differing of understanding in what
I don’t want to prolong discussion, but I think there’s one point which needs
to be clarified:
Discussion in the VOTE thread made me realize that there might be a differing
of understanding in what it means to vote and have votes carry over.
My understanding and apparently the understanding of
Thanks Darrell for pointing me to the codegen.
On 6 Dec 2014 10:06, "Darrell Loverin" wrote:
> >used to convert from MXML to Actionscript and then to ABC. Does anyone
> know
> >anything about this and if so, can they point me to it? Thanks and all the
> >best.
>
> For a prime example of generatin
Yes that's what I was referring to. I've considered expanding flashdevelops
capabilities to include a design view and other such things required for a
truly complete ide and so have many others. But, they gave up, as did I.
Flashdevelop has become an all in one ide and frankly in comparison to
othe
>
> > Well, we all know
> > > that people who used flex before are stuck with Adobe Flex IDE
> dependent
> > > project files, so yeah.
> >
>
> Not sure what you mean. Please clarify?
>
I'd say Jesse talks about Adobe Flash Builder projects. I don't know about
other IDEs, but FlashDevelop allows
>used to convert from MXML to Actionscript and then to ABC. Does anyone know
>anything about this and if so, can they point me to it? Thanks and all the
>best.
For a prime example of generating AS code look in the PreLink class in the
MXML compiler (in the sdk repo). Look at methods that start wit
We don't mention it explicitly in the 'less-RC' article (since it's a
long time and good practice Justin set up way back when), but we also
use your suggested method of using JIRA tickets to track the release
progress [1].
EdB
1: https://issues.apache.org/jira/browse/FLEX-34560
On Sat, Dec 6,
On Sat, Dec 6, 2014 at 10:13 AM, Erik de Bruin wrote:
> ...that is a very accurate summary of the 'less-RC' process [1]
> we've been working on for our future releases...
Oh cool! For some reason that felt more complicated when I looked at
it - I'll have another look after the week-end!
-Bertran
Bertrand, that is a very accurate summary of the 'less-RC' process [1]
we've been working on for our future releases.
Thanks,
EdB
1: https://cwiki.apache.org/confluence/x/2oH0Ag
On Sat, Dec 6, 2014 at 10:05 AM, Bertrand Delacretaz
wrote:
> Hi Flex team,
>
> Reviewing your activities to try a
Hi Flex team,
Reviewing your activities to try and help this community run in a
smoother way, I'm wondering why you need release candidates.
Those were useful during your Apache incubation, to allow "total
strangers" who don't have the right tools for example to review your
releases, but in a sma
Hi,
> Everyone had the opportunity to review the commit that changed the NOTICE,
The error was in the previous 2 RCs and also in the 1.1 release [1] which also
went though a couple of RCs. IMO that points to that we need more PMC members
checking releases. Which I guess ties into the thread on
On Dec 5, 2014 11:51 PM, "Justin Mclean" wrote:
>
> 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 b
30 matches
Mail list logo
