You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2014/02/05 22:46:10 UTC
JIRA bugs raised on the rise
Hi,
Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
https://issues.apache.org/jira/browse/FLEX-34070
Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
For more info on have to how to fix bugs see [4].
Thanks,
Justin
1. http://www.apache.org/dev/committers.html#committer-responsibilities
2. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyTest
3. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyFix
4. https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
Re: JIRA bugs raised on the rise
Posted by Justin Mclean <ju...@me.com>.
Hi,
> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
> Is that ok ?
Yep as they need to be committed and tagged with each build.
> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
Perhaps go with 11.7 [1]? However in the past I've keep it as it was as there are still a lot of people using older version of the flash player.
As most people install with the installer it's probably not an issue if it was updated.
Justin
1. http://blogs.adobe.com/flashplayer/2013/05/extended-support-release-updated-to-flash-player-11-7.html
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
Every time I build, I get four changed files. The 3 -config.xml files and
flex-sdk-description.xml. I'd prefer that doesn't happen but I don't know
if there is some reason they aren't in .gitignore already.
-Alex
On 2/5/14 2:59 PM, "Maurice Amsellem" <ma...@systar.com> wrote:
>Agree, but let's see what others will say.
>
>Maurice
>
>-----Message d'origine-----
>De : Lee Burrows [mailto:subscriptions@leeburrows.com]
>Envoyé : mercredi 5 février 2014 23:57
>À : dev@flex.apache.org
>Objet : Re: FLEX-34070
>
>My feeling is that the non-template versions should be ignored; seems odd
>to include them only for them to be overwritten by the build
>
>On 05/02/2014 22:43, Maurice Amsellem wrote:
>> I have reviewed and committed FLEX-34070 patch
>>
>> Little question:
>> flex-config.xml, air-config.xml and airmobile-config.xml are not in
>>.gitignore, although they are generated by the build, from template
>>files.
>> Is that ok ?
>>
>> If it's ok, then maybe I should update them with more recent version of
>>FP (eg 11.9) and recommit ?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
>> on the rise
>>
>> Hi,
>>
>> Over the last couple of months bugs are being raised twice as fast as
>>they being fixed and there's only a few committers who are actively
>>fixing bugs. While everyone is free to do what they want to do on a
>>project (including nothing) being a committer does mean you have a
>>responsibility to the current users of the software.[1] If all of the
>>current committer fixed only a single bug a month we would outstrip the
>>number of bugs being raised.
>>
>> There are some bugs with patches that would be simple to apply and test
>>- for instance this one re the new installer script:
>> https://issues.apache.org/jira/browse/FLEX-34070
>>
>> Also remember we need help from users as well - confirming that a bug
>>exits is helpful and would get the bug noticed. Supplying patches to
>>bugs is also one way to become a committer.
>>
>> If you're looking for something to fix and don't know where to start
>>the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to
>>solve bugs.
>>
>> For more info on have to how to fix bugs see [4].
>>
>> Thanks,
>> Justin
>>
>> 1.
>> http://www.apache.org/dev/committers.html#committer-responsibilities
>> 2.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>> 20labels%20%3D%20EasyTest 3.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>> 20labels%20%3D%20EasyFix 4.
>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>
>
>
>--
>Lee Burrows
>ActionScripter
>
RE: FLEX-34070
Posted by Maurice Amsellem <ma...@systar.com>.
In the other thread, Justin says that these files " need to be committed and tagged with each build."
So that's why they can't be in .gitignore.
So maybe we could commit and tag the *-template.xml files instead.
I am not too familiar with the installer script, but probably it's excepting *-config.xml files to be present in the download.
So maybe these scripts could be changed to use the *-config-template.xml instead, and instanciate them to generate the *-config.xml, on the fly.
WDYT?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 6 février 2014 00:18
À : dev@flex.apache.org
Objet : Re: FLEX-34070
Interesting. Why does flex-config.xml have to be in the source release if it is generated by the build. It isn't source if it is generated, IMO.
-Alex
On 2/5/14 3:08 PM, "Lee Burrows" <su...@leeburrows.com> wrote:
>Indeed; i have my interested-user hat on rather than my thats-my-patch
>hat ;)
>
>Looks like Justin added flex-config.xml with the reasoning: "File in
>source release should be under version control", so a precedent has
>been set.
>
>
>On 05/02/2014 22:59, Maurice Amsellem wrote:
>> Agree, but let's see what others will say.
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
>> Envoyé : mercredi 5 février 2014 23:57 À : dev@flex.apache.org Objet
>> : Re: FLEX-34070
>>
>> My feeling is that the non-template versions should be ignored; seems
>>odd to include them only for them to be overwritten by the build
>>
>> On 05/02/2014 22:43, Maurice Amsellem wrote:
>>> I have reviewed and committed FLEX-34070 patch
>>>
>>> Little question:
>>> flex-config.xml, air-config.xml and airmobile-config.xml are not in
>>>.gitignore, although they are generated by the build, from template
>>>files.
>>> Is that ok ?
>>>
>>> If it's ok, then maybe I should update them with more recent version
>>>of FP (eg 11.9) and recommit ?
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé :
>>> mercredi
>>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs
>>> raised on the rise
>>>
>>> Hi,
>>>
>>> Over the last couple of months bugs are being raised twice as fast
>>>as they being fixed and there's only a few committers who are
>>>actively fixing bugs. While everyone is free to do what they want to
>>>do on a project (including nothing) being a committer does mean you
>>>have a responsibility to the current users of the software.[1] If
>>>all of the current committer fixed only a single bug a month we would
>>>outstrip the number of bugs being raised.
>>>
>>> There are some bugs with patches that would be simple to apply and
>>>test - for instance this one re the new installer script:
>>> https://issues.apache.org/jira/browse/FLEX-34070
>>>
>>> Also remember we need help from users as well - confirming that a
>>>bug exits is helpful and would get the bug noticed. Supplying patches
>>>to bugs is also one way to become a committer.
>>>
>>> If you're looking for something to fix and don't know where to start
>>>the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy
>>>to solve bugs.
>>>
>>> For more info on have to how to fix bugs see [4].
>>>
>>> Thanks,
>>> Justin
>>>
>>> 1.
>>> http://www.apache.org/dev/committers.html#committer-responsibilities
>>> 2.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AN
>>> D%
>>> 20labels%20%3D%20EasyTest 3.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AN
>>> D%
>>> 20labels%20%3D%20EasyFix 4.
>>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>>
>>
>> --
>> Lee Burrows
>> ActionScripter
>>
>>
>
>
>--
>Lee Burrows
>ActionScripter
>
RE: FLEX-34070
Posted by Maurice Amsellem <ma...@systar.com>.
>IMO any non binary item in the source release should be under version control so we have a history of how it how changed - just because it's generated doesn't mean >you don't want to know how it changed from release to release - it may not always be directly obvious from the generating template and build scripts.
I don't agree with that.
Flex-config.xml changes = flex-config-template.xml changes + player version changes.
So it's rather obvious, it's just that we are not used to that.
Really, I can't see any good reason why a generated file (which is redundant in essence) would be under version control.
Note for Alex: you can use $git auf <filename> to exclude a file from git checkout even if not in .gitignore (thanks to Fred for the tip).
Maurice
-----Message d'origine-----
De : Justin Mclean [mailto:justin@classsoftware.com]
Envoyé : jeudi 6 février 2014 08:24
À : dev@flex.apache.org
Objet : Re: FLEX-34070
Hi,
> Aren't all four generated? If so, I'm still not understanding why we
> call them source and have them under version control if
They are part of the source and binary release zips/tar. I guess another option is to not have these files at all in the releases then there also no chance they will be incorrect.
IMO any non binary item in the source release should be under version control so we have a history of how it how changed - just because it's generated doesn't mean you don't want to know how it changed from release to release - it may not always be directly obvious from the generating template and build scripts.
> The diff on these four files shows an updated build number in
> flex-sdk-description. How is it that you don't also show this file as
> modified?
Because it gets checked in before the release is tagged.
Again you could accidentally make a release with "0" as the build number (quite easy to do/seen quite a few time - not 100% why it happens) so best IMO to have this file under version control.
Thanks,
Justin
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> OK, but in daily bug fixing, every time I run ant main, I have to clean up
> those files before committing, pulling, etc. Why is that not happening
> for others?
No idea sorry. I've made 100's of commits with no issues with this.
> Can we just put a Fail condition if build number is 0?
Provide a patch and I'll review but I can't see anyway you can do as part of the submission of the build artefacts.
Thanks,
Justin
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
Definitely not trying to make more work for the RM. Can you remind me of
the details of what went wrong with the -config.xml that one time?
On 2/6/14 2:33 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Sorry - but seriously why are we trying to make things more difficult for
>a release manager and increase the change a release candidate may be
>rejected/have to be redone?
>
>Again this issue caused a release candidate to be rejected with all that
>wasted time and effort involved - why are people even considering this
>change?
>
>If anyone can come up with a fool-proof way to know that the config files
>are 100% correct without comparing them with what's in VC please suggest
>so - otherwise I suggest we make no changes.
>
>Thanks,
>Justin
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Sorry - but seriously why are we trying to make things more difficult for a release manager and increase the change a release candidate may be rejected/have to be redone?
Again this issue caused a release candidate to be rejected with all that wasted time and effort involved - why are people even considering this change?
If anyone can come up with a fool-proof way to know that the config files are 100% correct without comparing them with what's in VC please suggest so - otherwise I suggest we make no changes.
Thanks,
Justin
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
On 2/5/14 11:23 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Aren't all four generated? If so, I'm still not understanding why we
>>call
>> them source and have them under version control if
>They are part of the source and binary release zips/tar. I guess another
>option is to not have these files at all in the releases then there also
>no chance they will be incorrect.
>
>IMO any non binary item in the source release should be under version
>control so we have a history of how it how changed - just because it's
>generated doesn't mean you don't want to know how it changed from release
>to release - it may not always be directly obvious from the generating
>template and build scripts.
Ant and the installer can do token replacement. Do we really need
-template files or just check them in with the final name and require
replacement?
>
>> The diff on these four files shows an updated build number in
>> flex-sdk-description. How is it that you don't also show this file as
>> modified?
>Because it gets checked in before the release is tagged.
OK, but in daily bug fixing, every time I run ant main, I have to clean up
those files before committing, pulling, etc. Why is that not happening
for others?
>
>Again you could accidentally make a release with "0" as the build number
>(quite easy to do/seen quite a few time - not 100% why it happens) so
>best IMO to have this file under version control.
Can we just put a Fail condition if build number is 0?
-Alex
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Aren't all four generated? If so, I'm still not understanding why we call
> them source and have them under version control if
They are part of the source and binary release zips/tar. I guess another option is to not have these files at all in the releases then there also no chance they will be incorrect.
IMO any non binary item in the source release should be under version control so we have a history of how it how changed - just because it's generated doesn't mean you don't want to know how it changed from release to release - it may not always be directly obvious from the generating template and build scripts.
> The diff on these four files shows an updated build number in
> flex-sdk-description. How is it that you don't also show this file as
> modified?
Because it gets checked in before the release is tagged.
Again you could accidentally make a release with "0" as the build number (quite easy to do/seen quite a few time - not 100% why it happens) so best IMO to have this file under version control.
Thanks,
Justin
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
On 2/5/14 5:53 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I find myself doing 'git checkout' on these four files pretty often.
>Not sure why you need to do that - but perhaps having untokenised
>versions of these files checked in would solve that?
>
>They are generated from the templates not themselves right?
I ran ant main again. The four files are:
# modified: flex-sdk-description.xml
# modified: ide/flashbuilder/config/air-config.xml
# modified: ide/flashbuilder/config/airmobile-config.xml
# modified: ide/flashbuilder/config/flex-config.xml
Aren't all four generated? If so, I'm still not understanding why we call
them source and have them under version control if, in order to use the
repo or the source or binary release packages, you have to run ant or the
installer and it will generate the right -config.xml for you. I do have a
recollection that you got burned once, but I don't remember the details
and maybe there is a way to solve the problem without checking in
generated files.
The diff on these four files shows an updated build number in
flex-sdk-description. How is it that you don't also show this file as
modified?
The diff on the -config.xml files shows different target-player and
swf-version tags because I'm not using the latest players. The version
number for the RSLs is also different.
I think we want to have tokenized versions and generate the -config.xml
files from templates because we allow folks to use different player
versions.
-Alex
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I find myself doing 'git checkout' on these four files pretty often.
Not sure why you need to do that - but perhaps having untokenised versions of these files checked in would solve that?
They are generated from the templates not themselves right?
Thanks,
Justin
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
I'm sorry I don't remember the actual history. I'm trying to understand
how making a mistake in the -template files is more likely to happen or
less likely to be caught when making the RC. When you make a full RC, at
least the flex-config.xml is used to compile the binary release.
I find myself doing 'git checkout' on these four files pretty often. I
would much prefer to save that time and try to somehow validate the config
files.
-Alex
On 2/5/14 3:59 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>OK I believe the issue was than between making a build and zipping it up
>for a release it's possible that something else can change those files
>(ide scripts for instance). If the files are in git ignore you have no
>way of knowing that they have been changed and then release something
>that is not correct.
>
>May or may not be an issue for the source release (as they would be
>regenerated if ant was run but the files don't represent what would be
>generated but may match what has been tagged) but it would certainly be
>an issue for the binary release (which the installer uses).
>
>If you make a mistake with the template files and didn't notice it and it
>produces a bad config file you could also create a RC thinking it was OK.
>
>This has bitten up once before and caused an entire release candidate to
>be scrapped - that's a lot of wasted effort and time. Please don't add
>them to git ignore.
>
>Thanks,
>Justin
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
OK I believe the issue was than between making a build and zipping it up for a release it's possible that something else can change those files (ide scripts for instance). If the files are in git ignore you have no way of knowing that they have been changed and then release something that is not correct.
May or may not be an issue for the source release (as they would be regenerated if ant was run but the files don't represent what would be generated but may match what has been tagged) but it would certainly be an issue for the binary release (which the installer uses).
If you make a mistake with the template files and didn't notice it and it produces a bad config file you could also create a RC thinking it was OK.
This has bitten up once before and caused an entire release candidate to be scrapped - that's a lot of wasted effort and time. Please don't add them to git ignore.
Thanks,
Justin
Re: FLEX-34070
Posted by Lee Burrows <su...@leeburrows.com>.
Config files are generated by the basic build (frameworks/build.xml
target=main)
On 05/02/2014 23:34, Justin Mclean wrote:
> I think (but not 100% sure) the config files may only be generated with a full release build not an ordinary build.
>
> Justin
--
Lee Burrows
ActionScripter
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Interesting. Why does flex-config.xml have to be in the source release if
> it is generated by the build. It isn't source if it is generated, IMO.
Because then you don't how it was changed which can be dangerous, I said we had to scrap an entire RC because of this. I think (but not 100% sure) the config files may only be generated with a full release build not an ordinary build.
Justin
Re: FLEX-34070
Posted by Alex Harui <ah...@adobe.com>.
Interesting. Why does flex-config.xml have to be in the source release if
it is generated by the build. It isn't source if it is generated, IMO.
-Alex
On 2/5/14 3:08 PM, "Lee Burrows" <su...@leeburrows.com> wrote:
>Indeed; i have my interested-user hat on rather than my thats-my-patch
>hat ;)
>
>Looks like Justin added flex-config.xml with the reasoning: "File in
>source release should be under version control", so a precedent has been
>set.
>
>
>On 05/02/2014 22:59, Maurice Amsellem wrote:
>> Agree, but let's see what others will say.
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
>> Envoyé : mercredi 5 février 2014 23:57
>> À : dev@flex.apache.org
>> Objet : Re: FLEX-34070
>>
>> My feeling is that the non-template versions should be ignored; seems
>>odd to include them only for them to be overwritten by the build
>>
>> On 05/02/2014 22:43, Maurice Amsellem wrote:
>>> I have reviewed and committed FLEX-34070 patch
>>>
>>> Little question:
>>> flex-config.xml, air-config.xml and airmobile-config.xml are not in
>>>.gitignore, although they are generated by the build, from template
>>>files.
>>> Is that ok ?
>>>
>>> If it's ok, then maybe I should update them with more recent version
>>>of FP (eg 11.9) and recommit ?
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
>>> on the rise
>>>
>>> Hi,
>>>
>>> Over the last couple of months bugs are being raised twice as fast as
>>>they being fixed and there's only a few committers who are actively
>>>fixing bugs. While everyone is free to do what they want to do on a
>>>project (including nothing) being a committer does mean you have a
>>>responsibility to the current users of the software.[1] If all of the
>>>current committer fixed only a single bug a month we would outstrip the
>>>number of bugs being raised.
>>>
>>> There are some bugs with patches that would be simple to apply and
>>>test - for instance this one re the new installer script:
>>> https://issues.apache.org/jira/browse/FLEX-34070
>>>
>>> Also remember we need help from users as well - confirming that a bug
>>>exits is helpful and would get the bug noticed. Supplying patches to
>>>bugs is also one way to become a committer.
>>>
>>> If you're looking for something to fix and don't know where to start
>>>the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy
>>>to solve bugs.
>>>
>>> For more info on have to how to fix bugs see [4].
>>>
>>> Thanks,
>>> Justin
>>>
>>> 1.
>>> http://www.apache.org/dev/committers.html#committer-responsibilities
>>> 2.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>>> 20labels%20%3D%20EasyTest 3.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>>> 20labels%20%3D%20EasyFix 4.
>>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>>
>>
>> --
>> Lee Burrows
>> ActionScripter
>>
>>
>
>
>--
>Lee Burrows
>ActionScripter
>
Re: FLEX-34070
Posted by Lee Burrows <su...@leeburrows.com>.
I meant a precedent has already been set to include them
On 05/02/2014 23:10, Maurice Amsellem wrote:
>> Looks like Justin added flex-config.xml with the reasoning: "File in source release should be under version control", so a precedent has been set.
> I don't get you. Flex-config.xml is not in .gitignore
>
> Maurice
>
> -----Message d'origine-----
> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
> Envoyé : jeudi 6 février 2014 00:08
> À : dev@flex.apache.org
> Objet : Re: FLEX-34070
>
> Indeed; i have my interested-user hat on rather than my thats-my-patch hat ;)
>
> Looks like Justin added flex-config.xml with the reasoning: "File in source release should be under version control", so a precedent has been set.
>
>
> On 05/02/2014 22:59, Maurice Amsellem wrote:
>> Agree, but let's see what others will say.
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
>> Envoyé : mercredi 5 février 2014 23:57 À : dev@flex.apache.org Objet :
>> Re: FLEX-34070
>>
>> My feeling is that the non-template versions should be ignored; seems
>> odd to include them only for them to be overwritten by the build
>>
>> On 05/02/2014 22:43, Maurice Amsellem wrote:
>>> I have reviewed and committed FLEX-34070 patch
>>>
>>> Little question:
>>> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
>>> Is that ok ?
>>>
>>> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé :
>>> mercredi
>>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
>>> on the rise
>>>
>>> Hi,
>>>
>>> Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
>>>
>>> There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
>>> https://issues.apache.org/jira/browse/FLEX-34070
>>>
>>> Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
>>>
>>> If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
>>>
>>> For more info on have to how to fix bugs see [4].
>>>
>>> Thanks,
>>> Justin
>>>
>>> 1.
>>> http://www.apache.org/dev/committers.html#committer-responsibilities
>>> 2.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND
>>> %
>>> 20labels%20%3D%20EasyTest 3.
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND
>>> %
>>> 20labels%20%3D%20EasyFix 4.
>>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>>
>> --
>> Lee Burrows
>> ActionScripter
>>
>>
>
> --
> Lee Burrows
> ActionScripter
>
>
--
Lee Burrows
ActionScripter
RE: FLEX-34070
Posted by Maurice Amsellem <ma...@systar.com>.
>Looks like Justin added flex-config.xml with the reasoning: "File in source release should be under version control", so a precedent has been set.
I don't get you. Flex-config.xml is not in .gitignore
Maurice
-----Message d'origine-----
De : Lee Burrows [mailto:subscriptions@leeburrows.com]
Envoyé : jeudi 6 février 2014 00:08
À : dev@flex.apache.org
Objet : Re: FLEX-34070
Indeed; i have my interested-user hat on rather than my thats-my-patch hat ;)
Looks like Justin added flex-config.xml with the reasoning: "File in source release should be under version control", so a precedent has been set.
On 05/02/2014 22:59, Maurice Amsellem wrote:
> Agree, but let's see what others will say.
>
> Maurice
>
> -----Message d'origine-----
> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
> Envoyé : mercredi 5 février 2014 23:57 À : dev@flex.apache.org Objet :
> Re: FLEX-34070
>
> My feeling is that the non-template versions should be ignored; seems
> odd to include them only for them to be overwritten by the build
>
> On 05/02/2014 22:43, Maurice Amsellem wrote:
>> I have reviewed and committed FLEX-34070 patch
>>
>> Little question:
>> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
>> Is that ok ?
>>
>> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé :
>> mercredi
>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
>> on the rise
>>
>> Hi,
>>
>> Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
>>
>> There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
>> https://issues.apache.org/jira/browse/FLEX-34070
>>
>> Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
>>
>> If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
>>
>> For more info on have to how to fix bugs see [4].
>>
>> Thanks,
>> Justin
>>
>> 1.
>> http://www.apache.org/dev/committers.html#committer-responsibilities
>> 2.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND
>> %
>> 20labels%20%3D%20EasyTest 3.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND
>> %
>> 20labels%20%3D%20EasyFix 4.
>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>
>
> --
> Lee Burrows
> ActionScripter
>
>
--
Lee Burrows
ActionScripter
Re: FLEX-34070
Posted by Lee Burrows <su...@leeburrows.com>.
Indeed; i have my interested-user hat on rather than my thats-my-patch
hat ;)
Looks like Justin added flex-config.xml with the reasoning: "File in
source release should be under version control", so a precedent has been
set.
On 05/02/2014 22:59, Maurice Amsellem wrote:
> Agree, but let's see what others will say.
>
> Maurice
>
> -----Message d'origine-----
> De : Lee Burrows [mailto:subscriptions@leeburrows.com]
> Envoyé : mercredi 5 février 2014 23:57
> À : dev@flex.apache.org
> Objet : Re: FLEX-34070
>
> My feeling is that the non-template versions should be ignored; seems odd to include them only for them to be overwritten by the build
>
> On 05/02/2014 22:43, Maurice Amsellem wrote:
>> I have reviewed and committed FLEX-34070 patch
>>
>> Little question:
>> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
>> Is that ok ?
>>
>> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
>> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
>> on the rise
>>
>> Hi,
>>
>> Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
>>
>> There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
>> https://issues.apache.org/jira/browse/FLEX-34070
>>
>> Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
>>
>> If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
>>
>> For more info on have to how to fix bugs see [4].
>>
>> Thanks,
>> Justin
>>
>> 1.
>> http://www.apache.org/dev/committers.html#committer-responsibilities
>> 2.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>> 20labels%20%3D%20EasyTest 3.
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
>> 20labels%20%3D%20EasyFix 4.
>> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>>
>
> --
> Lee Burrows
> ActionScripter
>
>
--
Lee Burrows
ActionScripter
RE: FLEX-34070
Posted by Maurice Amsellem <ma...@systar.com>.
Agree, but let's see what others will say.
Maurice
-----Message d'origine-----
De : Lee Burrows [mailto:subscriptions@leeburrows.com]
Envoyé : mercredi 5 février 2014 23:57
À : dev@flex.apache.org
Objet : Re: FLEX-34070
My feeling is that the non-template versions should be ignored; seems odd to include them only for them to be overwritten by the build
On 05/02/2014 22:43, Maurice Amsellem wrote:
> I have reviewed and committed FLEX-34070 patch
>
> Little question:
> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
> Is that ok ?
>
> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
>
> Maurice
>
> -----Message d'origine-----
> De : Justin Mclean [mailto:justin@classsoftware.com] Envoyé : mercredi
> 5 février 2014 22:46 À : dev@flex.apache.org Objet : JIRA bugs raised
> on the rise
>
> Hi,
>
> Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
>
> There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
> https://issues.apache.org/jira/browse/FLEX-34070
>
> Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
>
> If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
>
> For more info on have to how to fix bugs see [4].
>
> Thanks,
> Justin
>
> 1.
> http://www.apache.org/dev/committers.html#committer-responsibilities
> 2.
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
> 20labels%20%3D%20EasyTest 3.
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%
> 20labels%20%3D%20EasyFix 4.
> https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>
--
Lee Burrows
ActionScripter
Re: FLEX-34070
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
>> Is that ok ?
BTW I believe they were in .gitignore at one point which caused a release candidate to be incorrect/have issues - so please don't add them to .gitignore.
Justin
Re: FLEX-34070
Posted by Lee Burrows <su...@leeburrows.com>.
My feeling is that the non-template versions should be ignored; seems
odd to include them only for them to be overwritten by the build
On 05/02/2014 22:43, Maurice Amsellem wrote:
> I have reviewed and committed FLEX-34070 patch
>
> Little question:
> flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
> Is that ok ?
>
> If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
>
> Maurice
>
> -----Message d'origine-----
> De : Justin Mclean [mailto:justin@classsoftware.com]
> Envoyé : mercredi 5 février 2014 22:46
> À : dev@flex.apache.org
> Objet : JIRA bugs raised on the rise
>
> Hi,
>
> Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
>
> There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
> https://issues.apache.org/jira/browse/FLEX-34070
>
> Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
>
> If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
>
> For more info on have to how to fix bugs see [4].
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/committers.html#committer-responsibilities
> 2. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyTest
> 3. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyFix
> 4. https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>
--
Lee Burrows
ActionScripter
RE: JIRA bugs raised on the rise
Posted by Maurice Amsellem <ma...@systar.com>.
I have reviewed and committed FLEX-34070 patch
Little question:
flex-config.xml, air-config.xml and airmobile-config.xml are not in .gitignore, although they are generated by the build, from template files.
Is that ok ?
If it's ok, then maybe I should update them with more recent version of FP (eg 11.9) and recommit ?
Maurice
-----Message d'origine-----
De : Justin Mclean [mailto:justin@classsoftware.com]
Envoyé : mercredi 5 février 2014 22:46
À : dev@flex.apache.org
Objet : JIRA bugs raised on the rise
Hi,
Over the last couple of months bugs are being raised twice as fast as they being fixed and there's only a few committers who are actively fixing bugs. While everyone is free to do what they want to do on a project (including nothing) being a committer does mean you have a responsibility to the current users of the software.[1] If all of the current committer fixed only a single bug a month we would outstrip the number of bugs being raised.
There are some bugs with patches that would be simple to apply and test - for instance this one re the new installer script:
https://issues.apache.org/jira/browse/FLEX-34070
Also remember we need help from users as well - confirming that a bug exits is helpful and would get the bug noticed. Supplying patches to bugs is also one way to become a committer.
If you're looking for something to fix and don't know where to start the "easytest"[2] or "easyfix"[3] bugs are a good place to find easy to solve bugs.
For more info on have to how to fix bugs see [4].
Thanks,
Justin
1. http://www.apache.org/dev/committers.html#committer-responsibilities
2. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyTest
3. https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLEX%20AND%20labels%20%3D%20EasyFix
4. https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing