[
https://issues.apache.org/jira/browse/FLEX-33164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
João Fernandes updated FLEX-33164:
--
Attachment: buildForPt_PTLocale
Patch to add pt_PT to build.xml in multiple projects.
On 8/8/12 4:15 PM, "Dave Fisher" wrote:
>
> The community should be perfectly capable of deciding when trunk should be
> made stable for an upcoming release and stop making ill considered changes.
>
I would love for that to be true, but historically it hasn't. We've taken
several community
On 8/8/12 4:30 PM, "Igor Costa" wrote:
> Hi there Joao
>
>
> On every ticket you just need to submit a patch and a committer will
> analyze the patch and see if it's address to the bug.
>
But yes, you may have to bug people on the list to take a look at it.
Now if you can get a series of g
On 8/8/12 11:04 PM, "Gordon Smith" wrote:
> The solution for that is test-driven development. Apache doesn't have a QA
> team like Adobe. If developers write new stuff and don't write any tests, how
> are you ever going to trust anything new?
>
Absolutely correct, but I don't want to hold off
The solution for that is test-driven development. Apache doesn't have a QA team
like Adobe. If developers write new stuff and don't write any tests, how are
you ever going to trust anything new?
Sent from my iPad
On Aug 8, 2012, at 10:11 PM, "Alex Harui" wrote:
>
>
>
> On 8/8/12 10:00 PM,
On 8/8/12 7:03 PM, "Omar Gonzalez" wrote:
> On Wed, Aug 8, 2012 at 7:00 PM, Justin Mclean wrote:
>
>> Hi,
>>
>>> It would be more like option two, the always branch system. Features,
>>> fixes, releases, are always done off branches.
>> I would not be against that, I don't like the overhead
On 8/8/12 10:00 PM, "Gordon Smith" wrote:
> Why all the focus on branching strategies? It makes more sense to focus on a
> testing strategy. We need an 'ant tests' and a requirement that it pass for
> all changes to trunk.
>
> Didn't the mustella tests get submitted? What more do we need othe
Why all the focus on branching strategies? It makes more sense to focus on a
testing strategy. We need an 'ant tests' and a requirement that it pass for all
changes to trunk.
Didn't the mustella tests get submitted? What more do we need other than an
easy way to run them?
- Gordon
Sent from m
On Wed, Aug 8, 2012 at 6:40 PM, Justin Mclean wrote:
> Hi,
>
> > I would use the name "alt-trunk" instead of "unstable" for the other
> > branch. Every rule that applies to trunk would apply to the alt-trunk
> > branch.
> The issue I see is having one single branch not the name. You would be
> fi
On Wed, Aug 8, 2012 at 7:00 PM, Justin Mclean wrote:
> Hi,
>
> > It would be more like option two, the always branch system. Features,
> > fixes, releases, are always done off branches.
> I would not be against that, I don't like the overhead and complexity it
> brings compared to working in trunk
Hi,
> It would be more like option two, the always branch system. Features,
> fixes, releases, are always done off branches.
I would not be against that, I don't like the overhead and complexity it brings
compared to working in trunk, but it doesn't have the issues that a single
unstable branch
On Wed, Aug 8, 2012 at 6:42 PM, Justin Mclean wrote:
> Hi,
>
> > This is an example of a good branching model:
> > http://nvie.com/posts/a-successful-git-branching-model/
>
> Yep and it uses multiple branches (ie equiv to option 3 in the SVN link I
> posted earlier) not a single branch as suggeste
>
> t saying it is worth it in order to protect the integrity of trunk.
>
> If it's possible, yes, I really do think Git would help. The reason is
> that dealing with merge issues in Git are infinitely easier and, at least
> 95% of the time, keeps us out of the merge-hell that I think Justin
> legi
>
> t saying it is worth it in order to protect the integrity of trunk.
>
> If it's possible, yes, I really do think Git would help. The reason is
> that dealing with merge issues in Git are infinitely easier and, at least
> 95% of the time, keeps us out of the merge-hell that I think Justin
> legi
Hi,
> This is an example of a good branching model:
> http://nvie.com/posts/a-successful-git-branching-model/
Yep and it uses multiple branches (ie equiv to option 3 in the SVN link I
posted earlier) not a single branch as suggested we use for Flex.
Justin
>
>
> The author of the article seemed to want to make a release branch so that
> whatever hits the trunk is essentially a snapshot of a release. I'm not
> quite sure that is worth it if at the point there is a group of us
> dedicated
> to making a release and fixing things that are broken.
The
Hi,
> I would use the name "alt-trunk" instead of "unstable" for the other
> branch. Every rule that applies to trunk would apply to the alt-trunk
> branch.
The issue I see is having one single branch not the name. You would be fine
with the multi step step check in process (with unresolved issu
On Wed, Aug 8, 2012 at 3:50 PM, Alex Harui wrote:
>
>
>
> On 8/8/12 3:19 PM, "Justin Mclean" wrote:
>
> > No one has yet answered this:
> > How can you merge from unstable to trunk persons A changes when the
> unstable
> > branch contains persons A, B, C, D, E and F changes and each person may
>
Right now, very few people in this list have an idea of how complicated
the Flex codebase in trunk is. We dont even know how to run a single test
if we make a change a simple component. As a group, we are not ready to
start throwing code into trunk.
I would use the name "alt-trunk" instead of "
Hi,
> For those using eclipse, has anyone ever tried CollabNet eclipse plugin?
> It's from the same guys that created subclipse. Their interface makes all
> this merge process smoother and can even prevent you from merging if you
> don't follow SVN best practices.
If we go with a single unstable b
Hi,
>> How can you merge from unstable to trunk persons A changes when the unstable
>> branch contains persons A, B, C, D, E and F changes and each person may of
>> made multiple check ins at different (overlapping) times?
> You specify the revision number in the merge command.
And if they made mu
Hi there Joao
On every ticket you just need to submit a patch and a committer will
analyze the patch and see if it's address to the bug.
Best Regards
Igor Costa
www.igorcosta.com
www.igorcosta.org
On Wed, Aug 8, 2012 at 8:04 PM, João Fernandes <
joaopedromartinsfe
On Aug 6, 2012, at 8:38 PM, Justin Mclean wrote:
> Hi,
>
> JFYI there may be less issue with more recent versions of SVN and branching.
>
> In that you can keep branches up to date like so:
> svn merge pathtotrunk
>
> And then merging via:
> svn merge --reintegrate pathtobranch
>
> Any tired
On Aug 7, 2012, at 1:23 AM, Bertrand Delacretaz wrote:
> On Tue, Aug 7, 2012 at 9:08 AM, Alex Harui wrote:
>> ...IIRC, merging worked pretty well for us. I am currently not afraid of it,
>> especially since we are using SVN 1.6
>
> From the community standpoint, I think working in the same
For those using eclipse, has anyone ever tried CollabNet eclipse plugin?
It's from the same guys that created subclipse. Their interface makes all
this merge process smoother and can even prevent you from merging if you
don't follow SVN best practices. Regarding merging between different
branches,
Hi,
I'm no committer so my contributions will go through JIRA tickets by
commenting on a existing ticket or creating a new one but what I need to
know is what else should I do? Should I raise a thread here? Should I wait
that someone might take a look into my comment/ new ticket?
--
João Fernan
On 8/8/12 3:19 PM, "Justin Mclean" wrote:
> No one has yet answered this:
> How can you merge from unstable to trunk persons A changes when the unstable
> branch contains persons A, B, C, D, E and F changes and each person may of
> made multiple check ins at different (overlapping) times?
>
>
On Aug 8, 2012, at 12:51 PM, Igor Costa wrote:
> Alex
>
> Can't control it in any layouts, developers should have common sense to
> commit only what it's apply to sdk. Mentors should watching on svn code.
The project should be watching the svn tree. This Mentor will only be looking
at the next
Hi,
Anything but option 1 from me.
Option 1 as suggested by Alex to use a single unstable branch is not considered
best practice.
Apache's SVN own docs
(http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html)
give three options:
1. Never branch and work in trunk
2.
https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+(incubating)+Wiki
-Original Message-
From: Filippo Di Pisa [mailto:fili...@dipisa.net]
Sent: Wednesday, August 08, 2012 1:57 PM
To: flex-dev@incubator.apache.org
Subject: Re: Falcon update
Hi Gordon,
don t worry I misunderstoo
Hi Gordon,
don t worry I misunderstood.
Can you give me the wiki url please?
Filippo
On 8 Aug 2012, at 18:06, Gordon Smith wrote:
> Hi, Filippo.
>
> I was requesting write access. I don't have the power to grant write access.
>
> - Gordon
>
> -Original Message-
> From: Filippo Di Pis
[
https://issues.apache.org/jira/browse/FLEX-33164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
João Fernandes updated FLEX-33164:
--
Attachment: frameworks.zip
> Support for Locale pt_PT
>
>
>
João Fernandes created FLEX-33164:
-
Summary: Support for Locale pt_PT
Key: FLEX-33164
URL: https://issues.apache.org/jira/browse/FLEX-33164
Project: Apache Flex
Issue Type: Improvement
On 8/8/12 11:36 AM, "labri...@digitalprimates.net"
wrote:
>
> The one nice thing about the release and feature branches is that it allows
> people to start working toward future releases and grand visions while a
> current release is being stabilized. For example the code many had in
> whiteb
Alex
Can't control it in any layouts, developers should have common sense to
commit only what it's apply to sdk. Mentors should watching on svn code.
A guide like "Things to do before submit", may help .
Igor Costa
www.igorcosta.com
www.igorcosta.org
On Wed, Aug 8
I feel it's a good reason to go with Twitter Bootstrap + HTML5 + JQuery for
mobile web browsers.
On Thu, Aug 9, 2012 at 12:39 AM, Richard Oren wrote:
> We use AIR for all our Mobile Dev work and have been quite successful
> building large scale SASS applications with the Flex SDK and AIR for bot
On Wed, Aug 8, 2012 at 12:14 PM, Nicholas Kwiatkowski wrote:
> Om,
>
> I was working on this early last week (sorry I haven't touched it in the
> last week -- I've had a few personal things I had to take care of this
> week), and I was getting the same thing. It has something to do with the
> way
Om,
I was working on this early last week (sorry I haven't touched it in the
last week -- I've had a few personal things I had to take care of this
week), and I was getting the same thing. It has something to do with the
way the CMS is transferring the content to the production server.
I do know
On Tue, Aug 7, 2012 at 10:33 PM, Erik de Bruin wrote:
> >> I suggest we implement the CGI solution I've been promoting since I
> >> started... This is only 2 lines of CGI code, and one word in an HTML
> >> file. To me this sounds like the simplest and therefore most fool
> >> proof method.
> >
>
That url should be up now.
Om
On Tue, Aug 7, 2012 at 11:48 PM, Erik de Bruin wrote:
> Om,
>
> > http://incubator.apache.org/flex/single-mirror-url.html is there as
> well,
> > but is showing only the word [preferred]. What am I doing wrong?
>
> I don't see anything at that URL... I get a 404 (
1
I love the idea of having the trunk always available to ship. Makes the
testing and QA process a lot smoother, IMHO.
-Nick
On Wed, Aug 8, 2012 at 11:33 AM, Alex Harui wrote:
> Hi Folks,
>
> I have proposed using an interim unstable branch for changes, reserving
> trunk for stuff we’re sure
>Interesting read. Are you also pushing to make Git the default SCM?
>
>I'm not sure how far away we are from this model in some respects. We have
>whiteboards which sort of decentralize new development, and I am proposing an
>"unstable" branch that maps to the "develop" >branch in the article
On 8/8/12 10:58 AM, "Carol Frampton" wrote:
>
>
> On 8/8/12 1 :53PM, "Jason Moore" wrote:
>
>> The way I've used SVN before is to make the trunk the "unstable"
>> development and then branch off "stable" versions. Means you always
>> have a latest stable branch you can maintain / apply pa
On 8/8/12 11:04 AM, "Om" wrote:
> What exactly does 'for now' mean in the option 1?
>
> Is it in terms of time or releases? If we are not clear about this, we are
> only creating conflicts and confusions for us down the road.
I meant that we will use unstable until enough of us can be convinc
What exactly does 'for now' mean in the option 1?
Is it in terms of time or releases? If we are not clear about this, we are
only creating conflicts and confusions for us down the road.
I want to support option 1 until everyone has a reasonable understanding
of the complexity of the codebase.
O
1.
And I think it's very important to get to the point where we have a test suite
that we can use to ensure that trunk is ready-to-ship at all times.
- Gordon
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Wednesday, August 08, 2012 8:33 AM
To: flex-dev@incubator.
On 8/8/12 1 :53PM, "Jason Moore" wrote:
>The way I've used SVN before is to make the trunk the "unstable"
>development and then branch off "stable" versions. Means you always
>have a latest stable branch you can maintain / apply patches, while the
>trunk forges ahead. Branch another version of
The way I've used SVN before is to make the trunk the "unstable"
development and then branch off "stable" versions. Means you always
have a latest stable branch you can maintain / apply patches, while the
trunk forges ahead. Branch another version off the trunk when it has
progressed, then work on
On Wed, Aug 8, 2012 at 5:25 PM, Alex Harui wrote:
> OK, I will start a POLL. But what good will it do if others refuse to
> abide
> by it? I can't veto his commit on technical basis, he just has a different
> approach he wants to use...
Once the PPMC makes a decision, people have to abide
On Wed, Aug 8, 2012 at 7:10 PM, Om wrote:
Alex wrote:
>> ...Are you also pushing to make Git the default SCM?
>>...
> Is that an option available to us? If yes, I think moving to Git would
> make a lot of sense. If it is not, please forget that I asked...
Some Apache projects are working with G
Yet another (albeit a bit roundabout) approach would be to use the GitHub
mirror here: https://github.com/apache/flex
You can fork a new GitHub project for each patch you are planning to
create. Each one forks off of the main flex github. You can create
patches individually and attach them to co
On 8/8/12 12:34 AM, "Bertrand Delacretaz" wrote:
> On Wed, Aug 8, 2012 at 7:32 AM, Alex Harui wrote:
>> ...If you are 100% sure your change is safe, I won't veto it if you
>> commit it to both branches at the same time. If you're wrong, we will
>> resort to public humiliation like other proj
1
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
P.S. I would like everybody to know that as of this morning I broke my
personal record for days lived.
1 (no binding)
João Fernandes
>
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Just ponder it. It does work in practice.
> >
> > Mike
> >
> Interesting read. Are you also pushing to make Git the default SCM?
>
> >
Is that an option available to us? If yes, I think moving to Git would
make a lot of sense.
Hi, Filippo.
I was requesting write access. I don't have the power to grant write access.
- Gordon
-Original Message-
From: Filippo Di Pisa [mailto:fili...@dipisa.net]
Sent: Tuesday, August 07, 2012 1:28 PM
To: flex-dev@incubator.apache.org
Cc: flex-dev@incubator.apache.org
Subject: Re:
On Wed, Aug 8, 2012 at 10:47 AM, Peter Elst wrote:
> 1
>
> IMHO seems like a better practice and make it a more formal workflow for
> getting things into the trunk.
>
version 1
--
Jonathan Campos
On 8/8/12 9:14 AM, "labri...@digitalprimates.net"
wrote:
>> So again I ask. How do you intend you merge from unstable to trunk persons A
>> changes when the unstable branch containts persons A, B, C, D, E and F
>> changes and each may of made multiple check ins at different times. As far
>> >
We use AIR for all our Mobile Dev work and have been quite successful
building large scale SASS applications with the Flex SDK and AIR for both
Android and IOS. We did have to write our own Touch components that were
overlooked or abandoned by Adobe but it has not stopped us from moving
forward wit
Sehr geehrte Damen und Herren,
vielen Dank für Ihre Mail. Ich bin bis einschließlich 31.08.2012 im Urlaub. Ab
03.09.2012 erreichen Sie mich wieder in meinem Büro. Ihre Anfrage werde ich
gerne beantworten, sobald ich zurückgekehrt bin.
Bei dringenden Anfragen wenden Sie sich in der Zwischenzeit
>So again I ask. How do you intend you merge from unstable to trunk persons A
>changes when the unstable branch containts persons A, B, C, D, E and F changes
>and each may of made multiple check ins at different times. As far >as I'm
>aware there's no easy way to do it (even if you look up exac
1
IMHO seems like a better practice and make it a more formal workflow for
getting things into the trunk.
- Peter
1 (non binding)
On Wed, Aug 8, 2012 at 5:40 PM, Kéven Boily wrote:
> The way I see it branches should be used by a dedicated dev (or group) for
> one new feature/bugfix that's still in developpement or not completely
> implemented (incomplete). When they are done they are merged into the
> (uns
1
A thousand times: 1
On Wednesday, August 8, 2012, Alex Harui wrote:
>
>
>
> On 8/8/12 12:33 AM, "Bertrand Delacretaz"
> >
> wrote:
>
> > On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean
> >
> >
> > wrote:
> > Alex wrote:
> >>> Let's use the unstable branch until we prove we don't need it.
> >
> >> You want to work th
The way I see it branches should be used by a dedicated dev (or group) for
one new feature/bugfix that's still in developpement or not completely
implemented (incomplete). When they are done they are merged into the
(unstable, untested) trunk. Any released version outside the trunk (not
necessarely
1
[I've been following the thread w/o having a solution to offer; at
some point I guess we'll want to document what we consider releasable code]
On 8/8/2012 11:33 AM, Alex Harui wrote:
Hi Folks,
I have proposed using an interim unstable branch for changes, reserving trunk
for stuff we’re
2
On Wed, Aug 8, 2012 at 10:33 AM, Alex Harui wrote:
> Hi Folks,
>
> I have proposed using an interim unstable branch for changes, reserving trunk
> for stuff we’re sure we want to ship, and keeping trunk “ready-to-ship” at
> all times. Others (and other projects at Apache) prefer working dire
Hi Folks,
I have proposed using an interim unstable branch for changes, reserving trunk
for stuff we’re sure we want to ship, and keeping trunk “ready-to-ship” at all
times. Others (and other projects at Apache) prefer working directly in trunk.
I don’t think we have the testing infrastructur
On 8/8/12 12:33 AM, "Bertrand Delacretaz" wrote:
> On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean
> wrote:
> Alex wrote:
>>> Let's use the unstable branch until we prove we don't need it.
>
>> You want to work that way go ahead I will not be using it.
>
> This is a typical case were consensu
On 8/8/12 5:54 AM, "Justin Mclean" wrote:
> Hi,
>
> Interesting issue and probably not one correct answer.
>
> I'd go with generating patches against the latest SVN head as they can be
> easily applied.
>
> I'd try and keep in sync with the trunk (ie svn update) but no need to revert
> to
[
https://issues.apache.org/jira/browse/FLEX-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431103#comment-13431103
]
João Fernandes commented on FLEX-13994:
---
Could we fix this issue?
Clearly the fix
[
https://issues.apache.org/jira/browse/FLEX-33163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giles Roadnight updated FLEX-33163:
---
Attachment: IntegrationTestModule.mxml
Demonstration of the problem click a change list butto
[
https://issues.apache.org/jira/browse/FLEX-33162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik de Bruin updated FLEX-33162:
-
Attachment: InstallApacheFlex_Patch_FLEX-33162_2012-08-08.txt
> InstallApacheFlex: proposed u
Giles Roadnight created FLEX-33163:
--
Summary: When a collection reset event is received by List
selectedItem is not always cleared
Key: FLEX-33163
URL: https://issues.apache.org/jira/browse/FLEX-33163
Erik de Bruin created FLEX-33162:
Summary: InstallApacheFlex: proposed update to the localisation
scheme
Key: FLEX-33162
URL: https://issues.apache.org/jira/browse/FLEX-33162
Project: Apache Flex
Hi,
Interesting issue and probably not one correct answer.
I'd go with generating patches against the latest SVN head as they can be
easily applied.
I'd try and keep in sync with the trunk (ie svn update) but no need to revert
to it as that would mean more work for you.
Thanks,
Justin
Hi,
Any help you can give me with the following is very much appreciated:
I'm currently helping Om with the InstallApacheFlex app. I'm have a
basic knowledge of how patches are created and applied in SVN. I have
even submitted several patches already, which Om was kind enough to
commit to the rep
On Tue, Aug 7, 2012 at 9:55 PM, Greg Reddin wrote:
> On Tue, Aug 7, 2012 at 2:48 PM, Carol Frampton wrote:
>> ..."svn status" is always your friend.
>
> Yes, but to rely on that is to rely on humans always doing the right
> thing, which fails often :-)...
An svn commit hook could also be used to
On Wed, Aug 8, 2012 at 5:30 AM, jude wrote:
> ...I'd love to see a live or frequently updated status sheet / page / app that
> shows what's being worked on (general topics or Jira issues) , progress,
> participation count and so on if some how we can gather and show this
> information...
I'm sure
On Wed, Aug 8, 2012 at 7:32 AM, Alex Harui wrote:
> ...If you are 100% sure your change is safe, I won't veto it if you
> commit it to both branches at the same time. If you're wrong, we will
> resort to public humiliation like other projects do
There's no need to humiliate people who do som
On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean wrote:
Alex wrote:
>> Let's use the unstable branch until we prove we don't need it.
> You want to work that way go ahead I will not be using it.
This is a typical case were consensus is hard to reach - I suggest
exposing both options as concisely as
HI,
> I think I misspoke. We were merging by revision numbers not changelists.
So again I ask. How do you intend you merge from unstable to trunk persons A
changes when the unstable branch containts persons A, B, C, D, E and F changes
and each may of made multiple check ins at different times.
On 8/7/12 11:57 PM, "Justin Mclean" wrote:
> Hi,
>
> From my experience I'd not recommend using changelists. IMO they are can be
> confusing, have limited GUI tool support, are only client side (ie can't be
> shared or checked in), only work with files (not directories) and have issues
> with
84 matches
Mail list logo
