You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@flex.apache.org by Frédéric THOMAS <we...@hotmail.com> on 2013/03/27 09:47:47 UTC

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Hi Carlos,

This merge you did make me think I didn't talk about this case on the wiki 
[1], so I updated it, in short, while it is good to start a branch as you 
did for a new jira ticket and as you may don't know the final number of 
commits you will have at the end, once it is the time to merge, you know the 
number of commits you did, if you realize you've got only one, it is better 
to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff 
<my_branch>, the reason behind that is that you can avoid the extra merge 
commit, practically nothing change, except you will have a flat history 
which is what we want for only one commit and it could be reverse/reset the 
same if needed.

Thanks,
-Fred

[1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage

-----Message d'origine----- 
From: carlosrovira@apache.org
Sent: Wednesday, March 27, 2013 3:12 AM
To: commits@flex.apache.org
Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Merge branch 'FLEX-33349' into develop

* FLEX-33349:
  Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after 
refreshing the dataProvider of Combobox.


Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa
Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa
Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa

Branch: refs/heads/develop
Commit: 39fdf7fa81329fa60eb95efc374375a901c34d3d
Parents: 6282657 5ca083e
Author: Carlos Rovira <ca...@gmail.com>
Authored: Wed Mar 27 03:12:08 2013 +0100
Committer: Carlos Rovira <ca...@gmail.com>
Committed: Wed Mar 27 03:12:08 2013 +0100

----------------------------------------------------------------------
.../projects/spark/src/spark/components/List.as    |   23 +++++++++++----
1 files changed, 17 insertions(+), 6 deletions(-)
----------------------------------------------------------------------

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

Correction: "Why should I do" instead of "What should I do".

Finally, you was one of the more talkative person about Git before the 
migration, I would have supposed you wrote something for Git on the wiki, 
good practices, etc... but it didn't happen and from what I read from you 
now, I'm realizing that's finally not as bad as that.

But, that's only my point of you, maybe people here will like to see you 
take the bull by the horns and drive us with Git.

Thanks,
-Fred

-----Message d'origine----- 
From: Frédéric THOMAS
Sent: Wednesday, March 27, 2013 5:36 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Another point Carlos,

> this is really a matter of tastes. Each one should be happy with his way 
> of proceed

What should I do a git wiki with the good practices if at the end everyone
does what he wants, I guess we can try as written in the wiki for one month
and if it doesn't fit we can change it (but really, I think everyone will be
happy with it).

Thanks,
-Fred

-----Message d'origine----- 
From: Frédéric THOMAS
Sent: Wednesday, March 27, 2013 5:22 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Yeah, for sure, it's your point of view and happily everyone's got one and
not everyone the same, but from what I see from the current graph on the
develop branch or the one gave by Jose plus the explanations you gave, I
have the impression to see and hear "Why should I do simple when I can do
complicated".

If you look closely to the ASCII graph I wrote, you might have noticed there
are no crossed lines, it's really linear, one commit/jira at time, I really
maintain it is more readable and reflect more what the people really
develops, there's no artificial forced merge.

Thanks,
-Fred

-----Message d'origine----- 
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

IMHO this is hard to see, and even more for people outside or coming some
time later in time, but that's only my opinion... I think we should not
stand too much on these topics and going forward since this is really a
matter of tastes. Each one should be happy with his way of proceed while
making things properly since both ways are right. This is much more like
trying to realize how to format code, each developer will do in its own
way....put the bracket in the same line? in the next line?. I think we
should be more interested in the overall GIT workflow that ensure that we
all can share our contributions and make the repo safe of problems.



2013/3/27 Frédéric THOMAS <we...@hotmail.com>

>   It should have been like that even:
>
> *     Merge branch ‘FLEX-33451’ into develop [Fred]
>   *   FLEX-33451: Fixed .gitignore                      [Fred]
>   *   FLEX-33451: Tempora...                              [Fred]
>   *   FLEX-33451: Fix TLF                                     [Fred]
> *     FLEX-33349: Fix type error                          [Carlos]
> *     removed copy of empty.bundles...            [Justin]
> *     FLEX-28946 committed patch...                  [Cyrill]
> *     Merge branch ‘FLEX-21066’ into develop  [Carlos]
>   *   FLEX-21066: implemented remove item... [Carlos]
>   *   FLEX-21066: add removeItemError...          [Carlos]
>   *   FLEX-21066: add removeItem to list...        [Carlos]
> *     Merge branch ‘FLEX-33408’ into develop   [Carlos]
>   *     ...
>
> I hope that will be display well.
>
> -Fred
>
>  *From:* Jose Barragan <jo...@codeoscopic.com>
> *Sent:* Wednesday, March 27, 2013 1:26 PM
> *To:* dev@flex.apache.org
> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
>  Here's how it would Develop, after merging the branches of Charles and
> Fred, as you can see, thereby properly appreciate the content of the two
> applied Tickets.
> However, Justin's commit b5da14a, is visually hidden under the branch of
> Cyrill.
>
> Thanks,
>     --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
>  On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
> wrote:
>
> Having the rule of one commit doesn't generated an extra merge commit and
> makes the log history more readable and because you know that corresponds
> to 1 single task/jira/file, it's still easy to find it back without the
> visual pollution of the extra useless merge commit.
>
> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
> one day, in between I wouldn't like to introduce hierarchy in an apache
> model where it doesn't fit, anyway, look at what I said for the bugfix I
> just shared, "I'll do the merge at the end" which means I'll re-write
> commits in order, clean up what has to be clean if any, etc.., it's not 
> the
> dictator-lieutenant model but a collaborative one which say as a lazy
> consensus someone will merge/ clean up at the end, as you can see at the
> end, no needs for a dictator model to do the same things as it is useless
> to use a gun to kill a fly.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 10:24 AM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Hi Frederic,
>
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
>
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the 
> same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
>
>
>
>
>
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>
> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset 
> the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
>
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

Jose,

It is not a big deal to do in a way or another, I'm just saying it is more 
readable rebasing than forcing a merge commit, it makes 2 commits instead of 
1 when there's only 1 commit of real work, and for what ?


Thanks,
-Fred

-----Message d'origine----- 
From: Jose Barragan
Sent: Wednesday, March 27, 2013 6:06 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

That's the point Alex...

Any  solve can resolve as a single commit or in a change set, and this 
decision, under what criterial it does?
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92.
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:

> At minimum, if we can't decide on one particular practice, can we get a
> better understanding of what problem is solved by a single commit in a
> branch?  Then those who are trying to decide what to do can make a better
> decision.
>
>
> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
>> Another point Carlos,
>>
>>> this is really a matter of tastes. Each one should be happy with his way
>>> of proceed
>>
>> What should I do a git wiki with the good practices if at the end 
>> everyone
>> does what he wants, I guess we can try as written in the wiki for one 
>> month
>> and if it doesn't fit we can change it (but really, I think everyone will 
>> be
>> happy with it).
>>
>> Thanks,
>> -Fred
>>
>> -----Message d'origine-----
>> From: Frédéric THOMAS
>> Sent: Wednesday, March 27, 2013 5:22 PM
>> To: dev@flex.apache.org
>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>
>> Yeah, for sure, it's your point of view and happily everyone's got one 
>> and
>> not everyone the same, but from what I see from the current graph on the
>> develop branch or the one gave by Jose plus the explanations you gave, I
>> have the impression to see and hear "Why should I do simple when I can do
>> complicated".
>>
>> If you look closely to the ASCII graph I wrote, you might have noticed 
>> there
>> are no crossed lines, it's really linear, one commit/jira at time, I 
>> really
>> maintain it is more readable and reflect more what the people really
>> develops, there's no artificial forced merge.
>>
>> Thanks,
>> -Fred
>>
>> -----Message d'origine-----
>> From: Carlos Rovira
>> Sent: Wednesday, March 27, 2013 4:03 PM
>> To: dev@flex.apache.org
>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>
>> IMHO this is hard to see, and even more for people outside or coming some
>> time later in time, but that's only my opinion... I think we should not
>> stand too much on these topics and going forward since this is really a
>> matter of tastes. Each one should be happy with his way of proceed while
>> making things properly since both ways are right. This is much more like
>> trying to realize how to format code, each developer will do in its own
>> way....put the bracket in the same line? in the next line?. I think we
>> should be more interested in the overall GIT workflow that ensure that we
>> all can share our contributions and make the repo safe of problems.
>>
>>
>>
>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>
>>>  It should have been like that even:
>>>
>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>>>  *   FLEX-33451: Tempora...                              [Fred]
>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>>> *     FLEX-33349: Fix type error                          [Carlos]
>>> *     removed copy of empty.bundles...            [Justin]
>>> *     FLEX-28946 committed patch...                  [Cyrill]
>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>>  *   FLEX-21066: implemented remove item... [Carlos]
>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>>  *     ...
>>>
>>> I hope that will be display well.
>>>
>>> -Fred
>>>
>>> *From:* Jose Barragan <jo...@codeoscopic.com>
>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>>> *To:* dev@flex.apache.org
>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>
>>> Here's how it would Develop, after merging the branches of Charles and
>>> Fred, as you can see, thereby properly appreciate the content of the two
>>> applied Tickets.
>>> However, Justin's commit b5da14a, is visually hidden under the branch of
>>> Cyrill.
>>>
>>> Thanks,
>>>    --
>>> *Jose Barragan*
>>> *Chief **Software Architect*
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>>
>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
>>> wrote:
>>>
>>> Having the rule of one commit doesn't generated an extra merge commit 
>>> and
>>> makes the log history more readable and because you know that 
>>> corresponds
>>> to 1 single task/jira/file, it's still easy to find it back without the
>>> visual pollution of the extra useless merge commit.
>>>
>>> For the dictator-lieutenant model, we're not as big as linux kernel, 
>>> maybe
>>> one day, in between I wouldn't like to introduce hierarchy in an apache
>>> model where it doesn't fit, anyway, look at what I said for the bugfix I
>>> just shared, "I'll do the merge at the end" which means I'll re-write
>>> commits in order, clean up what has to be clean if any, etc.., it's not
>>> the
>>> dictator-lieutenant model but a collaborative one which say as a lazy
>>> consensus someone will merge/ clean up at the end, as you can see at the
>>> end, no needs for a dictator model to do the same things as it is 
>>> useless
>>> to use a gun to kill a fly.
>>>
>>> Thanks,
>>> -Fred
>>>
>>> -----Message d'origine----- From: Carlos Rovira
>>> Sent: Wednesday, March 27, 2013 10:24 AM
>>> To: dev@flex.apache.org
>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>
>>> Hi Frederic,
>>>
>>> in our experience working with GIT we saw that was extremely helpful to
>>> have visual track of each set of commits that are a single fix,
>>> functionality, feature or whatever, since you can always operate and 
>>> have
>>> much control as branches grow and ramifies. In the particular case you
>>> point (single commit - flat history) it's a matter of tastes but making 
>>> it
>>> flat for this particular case makes you lost visibility as GIT workflow
>>> evolve over time. Right now we could make it flat (at this point of
>>> simplicity), but I recommend not to do it since in few months we should
>>> expect more complex GIT graphs and this kind of loops will help to see
>>> others what historically happen.
>>>
>>> Apache Flex is so huge and modular and over time we should organize in a
>>> way that make us possible to plan huge releases with lots of modules,
>>> changes and consistence between pieces. We are right now at the very
>>> beginning trying to get the basic management and functionality but as
>>> people will understand the full potential of the tool and the kind of
>>> thinks we can now do, things will complicate. As we discussed in other
>>> thread some weeks ago, I suspect that we will end in an
>>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>>> part is that decisions must be consolidated in this list to adopt such
>>> model), since it's what I see in other big open source projects where 
>>> sub
>>> teams are organized in repositories and they commit in such repositories
>>> while the "lieutenant" assemble the final "module" (this happen in the
>>> same
>>> way all the way to root until reach the "dictator"). As we said, if we 
>>> end
>>> in this model, the apache way will be less restricted in repo 
>>> permissions
>>> and more conducted by the list where people will assign the tasks to a
>>> single person.
>>>
>>>
>>>
>>>
>>>
>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>>
>>> Hi Carlos,
>>>
>>> This merge you did make me think I didn't talk about this case on the 
>>> wiki
>>> [1], so I updated it, in short, while it is good to start a branch as 
>>> you
>>> did for a new jira ticket and as you may don't know the final number of
>>> commits you will have at the end, once it is the time to merge, you know
>>> the number of commits you did, if you realize you've got only one, it is
>>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>>> <my_branch>, the reason behind that is that you can avoid the extra 
>>> merge
>>> commit, practically nothing change, except you will have a flat history
>>> which is what we want for only one commit and it could be reverse/reset
>>> the
>>> same if needed.
>>>
>>> Thanks,
>>> -Fred
>>>
>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>> vs+Bad+Git+usage<
>>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>>
>>> -----Message d'origine----- From: carlosrovira@apache.org
>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>> To: commits@flex.apache.org
>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>
>>> Merge branch 'FLEX-33349' into develop
>>>
>>> * FLEX-33349:
>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as 
>>> after
>>> refreshing the dataProvider of Combobox.
>>>
>>>
>>> Project:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apac
>>> he.org/repos/asf/flex-sdk/repo>
>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>> 39fdf7fa 
>>> <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>> Tree:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-
>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>> Diff:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-
>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>>
>>> Branch: refs/heads/develop
>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>> Parents: 6282657 5ca083e
>>> Author: Carlos Rovira <ca...@gmail.com>
>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>> Committer: Carlos Rovira <ca...@gmail.com>
>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>>
>>> ------------------------------**------------------------------**----------
>>> .../projects/spark/src/spark/**components/List.as    |   23
>>> +++++++++++----
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>> ------------------------------**------------------------------**----------
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> Director de Tecnología
>>> M: +34 607 22 60 05
>>> F:  +34 912 94 80 80
>>> http://www.codeoscopic.com
>>> http://www.directwriter.es
>>> http://www.avant2.es
>>>
>>>
>>>
>>
>>
>
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragan <jo...@codeoscopic.com>.

Hi Alex,

Once we start accept pull-requests, we will need to view and easily find where it is, in case you need to touch or reverse, whether one or more commits.

When we need to move, the resolution of a particular ticket between fork's, or between branches disconnected, it will be very useful to be able to jump to the branch associated with it, and be assured that the contents thereof, is complete and that no commit was out.

When a ticket is complicated, or reopens, or wide, if we have been committing in the main branch individual over time, we could revise the delta changes, when this is necessary.
I could ramble more examples, but although this can not be imposed, it should not abridged the use of this process, since over time the Git tree is to help maintain the contributions, not to limit ourselves to a flat line as SVN and lose that advantage.

The criterion would be that a ticket, a bug, an experiment, functionality, etc. should be associated with a local branch (minimum) and a public if necessary more than one developer working on it at the same time as to the branch main "Develop", should always be in a stable state, and the mixes contain individual developments, thus "Develop" is always available to open a branch of release.

But as said, is primarily a visual aid and indexed for whoever has to move things, or mount a version output.

Finally, as Carlos said, it's hard to sell the idea or motivation
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 6:59 PM, Frédéric THOMAS <we...@hotmail.com> wrote:

>> without taking care if a branch is 1 commit or 10, since this make you gain
> control of revert something if you need at some point in time
> 
> Are you saying it is easier to revert a set of one commit + the merge commit than only one commit ?
> Because to revert one commit is as easy as 'git revert <myCommit>'
> 
> Thanks,
> -Fred
> 
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 6:47 PM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> 
> Hi Alex,
> 
> as I said this is a matter of taste, but we are using git with huge
> projects for months and when we are merging and generating releases and we
> end wanting to easily see *all* branches to quickly see what we want to do,
> without taking care if a branch is 1 commit or 10, since this make you gain
> control of revert something if you need at some point in time. You end
> having more control and people not involved in a particular development can
> easily see what happened.
> 
> Right now I think is difficult to see since we are starting in GIT, but as
> GIT graph evolve we will see more complex representations and will be
> difficult to see quickly the GIT history. As I pass for that *problem*
> before, I already adopted the way to make always a branch although I have
> only one commit, but again, I recognized that it's a matter of tastes and
> it's difficult to sell the idea if you like not do it.
> 
> 
> 
> 2013/3/27 Alex Harui <ah...@adobe.com>
> 
>> I"m used to SVN's linear history. I like the fact that Git can show branch
>> history, and like the idea that I can do multiple commits before pushing
>> and
>> each of those commits is clearly shown in the history.
>> 
>> But if I don't want to show those multiple commits or I don't have multiple
>> commits, my instinct would be to just make it a linear entry.  I think
>> Carlos is saying there is some advantage to not doing that, and I want to
>> know what that advantage is.
>> 
>> 
>> On 3/27/13 10:06 AM, "Jose Barragan" <jo...@codeoscopic.com>
>> wrote:
>> 
>> > That's the point Alex...
>> >
>> > Any  solve can resolve as a single commit or in a change set, and this
>> > decision, under what criterial it does?
>> > --
>> > Jose Barragan
>> > Chief Software Architect
>> > Codeoscopic Madrid
>> > C/. Infanta Mercedes, 92.
>> > Planta 5.  505.
>> > 28020 Madrid.
>> > Tel.: +34 912 94 80 80
>> >
>> > On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> At minimum, if we can't decide on one particular practice, can we get a
>> >> better understanding of what problem is solved by a single commit in a
>> >> branch?  Then those who are trying to decide what to do can make a
>> better
>> >> decision.
>> >>
>> >>
>> >> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>> >>
>> >>> Another point Carlos,
>> >>>
>> >>>> this is really a matter of tastes. Each one should be happy with his
>> way
>> >>>> of proceed
>> >>>
>> >>> What should I do a git wiki with the good practices if at the end
>> everyone
>> >>> does what he wants, I guess we can try as written in the wiki for one
>> month
>> >>> and if it doesn't fit we can change it (but really, I think everyone
>> will be
>> >>> happy with it).
>> >>>
>> >>> Thanks,
>> >>> -Fred
>> >>>
>> >>> -----Message d'origine-----
>> >>> From: Frédéric THOMAS
>> >>> Sent: Wednesday, March 27, 2013 5:22 PM
>> >>> To: dev@flex.apache.org
>> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> >>>
>> >>> Yeah, for sure, it's your point of view and happily everyone's got one
>> and
>> >>> not everyone the same, but from what I see from the current graph on
>> the
>> >>> develop branch or the one gave by Jose plus the explanations you gave,
>> I
>> >>> have the impression to see and hear "Why should I do simple when I can
>> do
>> >>> complicated".
>> >>>
>> >>> If you look closely to the ASCII graph I wrote, you might have noticed
>> there
>> >>> are no crossed lines, it's really linear, one commit/jira at time, I
>> really
>> >>> maintain it is more readable and reflect more what the people really
>> >>> develops, there's no artificial forced merge.
>> >>>
>> >>> Thanks,
>> >>> -Fred
>> >>>
>> >>> -----Message d'origine-----
>> >>> From: Carlos Rovira
>> >>> Sent: Wednesday, March 27, 2013 4:03 PM
>> >>> To: dev@flex.apache.org
>> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> >>>
>> >>> IMHO this is hard to see, and even more for people outside or coming
>> some
>> >>> time later in time, but that's only my opinion... I think we should >>> not
>> >>> stand too much on these topics and going forward since this is really >>> a
>> >>> matter of tastes. Each one should be happy with his way of proceed
>> while
>> >>> making things properly since both ways are right. This is much more
>> like
>> >>> trying to realize how to format code, each developer will do in its >>> own
>> >>> way....put the bracket in the same line? in the next line?. I think we
>> >>> should be more interested in the overall GIT workflow that ensure that
>> we
>> >>> all can share our contributions and make the repo safe of problems.
>> >>>
>> >>>
>> >>>
>> >>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>> >>>
>> >>>>  It should have been like that even:
>> >>>>
>> >>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>> >>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>> >>>>  *   FLEX-33451: Tempora...                              [Fred]
>> >>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>> >>>> *     FLEX-33349: Fix type error                          [Carlos]
>> >>>> *     removed copy of empty.bundles...            [Justin]
>> >>>> *     FLEX-28946 committed patch...                  [Cyrill]
>> >>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>> >>>>  *   FLEX-21066: implemented remove item... [Carlos]
>> >>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>> >>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>> >>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>> >>>>  *     ...
>> >>>>
>> >>>> I hope that will be display well.
>> >>>>
>> >>>> -Fred
>> >>>>
>> >>>> *From:* Jose Barragan <jo...@codeoscopic.com>
>> >>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>> >>>> *To:* dev@flex.apache.org
>> >>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into
>> develop
>> >>>>
>> >>>> Here's how it would Develop, after merging the branches of Charles >>>> and
>> >>>> Fred, as you can see, thereby properly appreciate the content of the
>> two
>> >>>> applied Tickets.
>> >>>> However, Justin's commit b5da14a, is visually hidden under the branch
>> of
>> >>>> Cyrill.
>> >>>>
>> >>>> Thanks,
>> >>>>    --
>> >>>> *Jose Barragan*
>> >>>> *Chief **Software Architect*
>> >>>> Codeoscopic Madrid
>> >>>> C/. Infanta Mercedes, 92.
>> >>>> Planta 5.  505.
>> >>>> 28020 Madrid.
>> >>>> Tel.: +34 912 94 80 80
>> >>>>
>> >>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <
>> webdoublefx@hotmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> Having the rule of one commit doesn't generated an extra merge commit
>> and
>> >>>> makes the log history more readable and because you know that
>> corresponds
>> >>>> to 1 single task/jira/file, it's still easy to find it back without
>> the
>> >>>> visual pollution of the extra useless merge commit.
>> >>>>
>> >>>> For the dictator-lieutenant model, we're not as big as linux kernel,
>> maybe
>> >>>> one day, in between I wouldn't like to introduce hierarchy in an
>> apache
>> >>>> model where it doesn't fit, anyway, look at what I said for the
>> bugfix I
>> >>>> just shared, "I'll do the merge at the end" which means I'll re-write
>> >>>> commits in order, clean up what has to be clean if any, etc.., it's
>> not
>> >>>> the
>> >>>> dictator-lieutenant model but a collaborative one which say as a lazy
>> >>>> consensus someone will merge/ clean up at the end, as you can see at
>> the
>> >>>> end, no needs for a dictator model to do the same things as it is
>> useless
>> >>>> to use a gun to kill a fly.
>> >>>>
>> >>>> Thanks,
>> >>>> -Fred
>> >>>>
>> >>>> -----Message d'origine----- From: Carlos Rovira
>> >>>> Sent: Wednesday, March 27, 2013 10:24 AM
>> >>>> To: dev@flex.apache.org
>> >>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> >>>>
>> >>>> Hi Frederic,
>> >>>>
>> >>>> in our experience working with GIT we saw that was extremely helpful
>> to
>> >>>> have visual track of each set of commits that are a single fix,
>> >>>> functionality, feature or whatever, since you can always operate and
>> have
>> >>>> much control as branches grow and ramifies. In the particular case >>>> you
>> >>>> point (single commit - flat history) it's a matter of tastes but
>> making it
>> >>>> flat for this particular case makes you lost visibility as GIT
>> workflow
>> >>>> evolve over time. Right now we could make it flat (at this point of
>> >>>> simplicity), but I recommend not to do it since in few months we
>> should
>> >>>> expect more complex GIT graphs and this kind of loops will help to >>>> see
>> >>>> others what historically happen.
>> >>>>
>> >>>> Apache Flex is so huge and modular and over time we should organize
>> in a
>> >>>> way that make us possible to plan huge releases with lots of modules,
>> >>>> changes and consistence between pieces. We are right now at the very
>> >>>> beginning trying to get the basic management and functionality but as
>> >>>> people will understand the full potential of the tool and the kind of
>> >>>> thinks we can now do, things will complicate. As we discussed in >>>> other
>> >>>> thread some weeks ago, I suspect that we will end in an
>> >>>> "dictator-lieutenant-apache" model (as we talked with Beltran the
>> apache
>> >>>> part is that decisions must be consolidated in this list to adopt >>>> such
>> >>>> model), since it's what I see in other big open source projects where
>> sub
>> >>>> teams are organized in repositories and they commit in such
>> repositories
>> >>>> while the "lieutenant" assemble the final "module" (this happen in >>>> the
>> >>>> same
>> >>>> way all the way to root until reach the "dictator"). As we said, if
>> we end
>> >>>> in this model, the apache way will be less restricted in repo
>> permissions
>> >>>> and more conducted by the list where people will assign the tasks to >>>> a
>> >>>> single person.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>> >>>>
>> >>>> Hi Carlos,
>> >>>>
>> >>>> This merge you did make me think I didn't talk about this case on the
>> wiki
>> >>>> [1], so I updated it, in short, while it is good to start a branch as
>> you
>> >>>> did for a new jira ticket and as you may don't know the final number
>> of
>> >>>> commits you will have at the end, once it is the time to merge, you
>> know
>> >>>> the number of commits you did, if you realize you've got only one, it
>> is
>> >>>> better to do a 'git rebase <my_branch>' instead of a 'git merge
>> --no-ff
>> >>>> <my_branch>, the reason behind that is that you can avoid the extra
>> merge
>> >>>> commit, practically nothing change, except you will have a flat
>> history
>> >>>> which is what we want for only one commit and it could be
>> reverse/reset
>> >>>> the
>> >>>> same if needed.
>> >>>>
>> >>>> Thanks,
>> >>>> -Fred
>> >>>>
>> >>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>> >>>> vs+Bad+Git+usage<
>> >>>>
>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>> >>>>
>> >>>> -----Message d'origine----- From: carlosrovira@apache.org
>> >>>> Sent: Wednesday, March 27, 2013 3:12 AM
>> >>>> To: commits@flex.apache.org
>> >>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> >>>>
>> >>>> Merge branch 'FLEX-33349' into develop
>> >>>>
>> >>>> * FLEX-33349:
>> >>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as
>> after
>> >>>> refreshing the dataProvider of Combobox.
>> >>>>
>> >>>>
>> >>>> Project:
>> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
>> http://git-wip-us.ap
>> >>>> ac
>> >>>> he.org/repos/asf/flex-sdk/repo>
>> >>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>> >>>> 39fdf7fa <
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>> >>>> Tree:
>> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
>> http://gi
>> >>>> t-
>> >>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>> >>>> Diff:
>> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
>> http://gi
>> >>>> t-
>> >>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>> >>>>
>> >>>> Branch: refs/heads/develop
>> >>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>> >>>> Parents: 6282657 5ca083e
>> >>>> Author: Carlos Rovira <ca...@gmail.com>
>> >>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>> >>>> Committer: Carlos Rovira <ca...@gmail.com>
>> >>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>> >>>>
>> >>>>
>> ------------------------------**------------------------------**----------
>> >>>> .../projects/spark/src/spark/**components/List.as    |   23
>> >>>> +++++++++++----
>> >>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>> >>>>
>> ------------------------------**------------------------------**----------
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Carlos Rovira
>> >>>> Director de Tecnología
>> >>>> M: +34 607 22 60 05
>> >>>> F:  +34 912 94 80 80
>> >>>> http://www.codeoscopic.com
>> >>>> http://www.directwriter.es
>> >>>> http://www.avant2.es
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Alex Harui
>> >> Flex SDK Team
>> >> Adobe Systems, Inc.
>> >> http://blogs.adobe.com/aharui
>> >>
>> >
>> 
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

> without taking care if a branch is 1 commit or 10, since this make you 
> gain
control of revert something if you need at some point in time

Are you saying it is easier to revert a set of one commit + the merge commit 
than only one commit ?
Because to revert one commit is as easy as 'git revert <myCommit>'

Thanks,
-Fred

-----Message d'origine----- 
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 6:47 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Hi Alex,

as I said this is a matter of taste, but we are using git with huge
projects for months and when we are merging and generating releases and we
end wanting to easily see *all* branches to quickly see what we want to do,
without taking care if a branch is 1 commit or 10, since this make you gain
control of revert something if you need at some point in time. You end
having more control and people not involved in a particular development can
easily see what happened.

Right now I think is difficult to see since we are starting in GIT, but as
GIT graph evolve we will see more complex representations and will be
difficult to see quickly the GIT history. As I pass for that *problem*
before, I already adopted the way to make always a branch although I have
only one commit, but again, I recognized that it's a matter of tastes and
it's difficult to sell the idea if you like not do it.



2013/3/27 Alex Harui <ah...@adobe.com>

> I"m used to SVN's linear history. I like the fact that Git can show branch
> history, and like the idea that I can do multiple commits before pushing
> and
> each of those commits is clearly shown in the history.
>
> But if I don't want to show those multiple commits or I don't have 
> multiple
> commits, my instinct would be to just make it a linear entry.  I think
> Carlos is saying there is some advantage to not doing that, and I want to
> know what that advantage is.
>
>
> On 3/27/13 10:06 AM, "Jose Barragan" <jo...@codeoscopic.com>
> wrote:
>
> > That's the point Alex...
> >
> > Any  solve can resolve as a single commit or in a change set, and this
> > decision, under what criterial it does?
> > --
> > Jose Barragan
> > Chief Software Architect
> > Codeoscopic Madrid
> > C/. Infanta Mercedes, 92.
> > Planta 5.  505.
> > 28020 Madrid.
> > Tel.: +34 912 94 80 80
> >
> > On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> At minimum, if we can't decide on one particular practice, can we get a
> >> better understanding of what problem is solved by a single commit in a
> >> branch?  Then those who are trying to decide what to do can make a
> better
> >> decision.
> >>
> >>
> >> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> >>
> >>> Another point Carlos,
> >>>
> >>>> this is really a matter of tastes. Each one should be happy with his
> way
> >>>> of proceed
> >>>
> >>> What should I do a git wiki with the good practices if at the end
> everyone
> >>> does what he wants, I guess we can try as written in the wiki for one
> month
> >>> and if it doesn't fit we can change it (but really, I think everyone
> will be
> >>> happy with it).
> >>>
> >>> Thanks,
> >>> -Fred
> >>>
> >>> -----Message d'origine-----
> >>> From: Frédéric THOMAS
> >>> Sent: Wednesday, March 27, 2013 5:22 PM
> >>> To: dev@flex.apache.org
> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>
> >>> Yeah, for sure, it's your point of view and happily everyone's got one
> and
> >>> not everyone the same, but from what I see from the current graph on
> the
> >>> develop branch or the one gave by Jose plus the explanations you gave,
> I
> >>> have the impression to see and hear "Why should I do simple when I can
> do
> >>> complicated".
> >>>
> >>> If you look closely to the ASCII graph I wrote, you might have noticed
> there
> >>> are no crossed lines, it's really linear, one commit/jira at time, I
> really
> >>> maintain it is more readable and reflect more what the people really
> >>> develops, there's no artificial forced merge.
> >>>
> >>> Thanks,
> >>> -Fred
> >>>
> >>> -----Message d'origine-----
> >>> From: Carlos Rovira
> >>> Sent: Wednesday, March 27, 2013 4:03 PM
> >>> To: dev@flex.apache.org
> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>
> >>> IMHO this is hard to see, and even more for people outside or coming
> some
> >>> time later in time, but that's only my opinion... I think we should 
> >>> not
> >>> stand too much on these topics and going forward since this is really 
> >>> a
> >>> matter of tastes. Each one should be happy with his way of proceed
> while
> >>> making things properly since both ways are right. This is much more
> like
> >>> trying to realize how to format code, each developer will do in its 
> >>> own
> >>> way....put the bracket in the same line? in the next line?. I think we
> >>> should be more interested in the overall GIT workflow that ensure that
> we
> >>> all can share our contributions and make the repo safe of problems.
> >>>
> >>>
> >>>
> >>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> >>>
> >>>>  It should have been like that even:
> >>>>
> >>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
> >>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
> >>>>  *   FLEX-33451: Tempora...                              [Fred]
> >>>>  *   FLEX-33451: Fix TLF                                     [Fred]
> >>>> *     FLEX-33349: Fix type error                          [Carlos]
> >>>> *     removed copy of empty.bundles...            [Justin]
> >>>> *     FLEX-28946 committed patch...                  [Cyrill]
> >>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
> >>>>  *   FLEX-21066: implemented remove item... [Carlos]
> >>>>  *   FLEX-21066: add removeItemError...          [Carlos]
> >>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
> >>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
> >>>>  *     ...
> >>>>
> >>>> I hope that will be display well.
> >>>>
> >>>> -Fred
> >>>>
> >>>> *From:* Jose Barragan <jo...@codeoscopic.com>
> >>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
> >>>> *To:* dev@flex.apache.org
> >>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into
> develop
> >>>>
> >>>> Here's how it would Develop, after merging the branches of Charles 
> >>>> and
> >>>> Fred, as you can see, thereby properly appreciate the content of the
> two
> >>>> applied Tickets.
> >>>> However, Justin's commit b5da14a, is visually hidden under the branch
> of
> >>>> Cyrill.
> >>>>
> >>>> Thanks,
> >>>>    --
> >>>> *Jose Barragan*
> >>>> *Chief **Software Architect*
> >>>> Codeoscopic Madrid
> >>>> C/. Infanta Mercedes, 92.
> >>>> Planta 5.  505.
> >>>> 28020 Madrid.
> >>>> Tel.: +34 912 94 80 80
> >>>>
> >>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <
> webdoublefx@hotmail.com>
> >>>> wrote:
> >>>>
> >>>> Having the rule of one commit doesn't generated an extra merge commit
> and
> >>>> makes the log history more readable and because you know that
> corresponds
> >>>> to 1 single task/jira/file, it's still easy to find it back without
> the
> >>>> visual pollution of the extra useless merge commit.
> >>>>
> >>>> For the dictator-lieutenant model, we're not as big as linux kernel,
> maybe
> >>>> one day, in between I wouldn't like to introduce hierarchy in an
> apache
> >>>> model where it doesn't fit, anyway, look at what I said for the
> bugfix I
> >>>> just shared, "I'll do the merge at the end" which means I'll re-write
> >>>> commits in order, clean up what has to be clean if any, etc.., it's
> not
> >>>> the
> >>>> dictator-lieutenant model but a collaborative one which say as a lazy
> >>>> consensus someone will merge/ clean up at the end, as you can see at
> the
> >>>> end, no needs for a dictator model to do the same things as it is
> useless
> >>>> to use a gun to kill a fly.
> >>>>
> >>>> Thanks,
> >>>> -Fred
> >>>>
> >>>> -----Message d'origine----- From: Carlos Rovira
> >>>> Sent: Wednesday, March 27, 2013 10:24 AM
> >>>> To: dev@flex.apache.org
> >>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> Hi Frederic,
> >>>>
> >>>> in our experience working with GIT we saw that was extremely helpful
> to
> >>>> have visual track of each set of commits that are a single fix,
> >>>> functionality, feature or whatever, since you can always operate and
> have
> >>>> much control as branches grow and ramifies. In the particular case 
> >>>> you
> >>>> point (single commit - flat history) it's a matter of tastes but
> making it
> >>>> flat for this particular case makes you lost visibility as GIT
> workflow
> >>>> evolve over time. Right now we could make it flat (at this point of
> >>>> simplicity), but I recommend not to do it since in few months we
> should
> >>>> expect more complex GIT graphs and this kind of loops will help to 
> >>>> see
> >>>> others what historically happen.
> >>>>
> >>>> Apache Flex is so huge and modular and over time we should organize
> in a
> >>>> way that make us possible to plan huge releases with lots of modules,
> >>>> changes and consistence between pieces. We are right now at the very
> >>>> beginning trying to get the basic management and functionality but as
> >>>> people will understand the full potential of the tool and the kind of
> >>>> thinks we can now do, things will complicate. As we discussed in 
> >>>> other
> >>>> thread some weeks ago, I suspect that we will end in an
> >>>> "dictator-lieutenant-apache" model (as we talked with Beltran the
> apache
> >>>> part is that decisions must be consolidated in this list to adopt 
> >>>> such
> >>>> model), since it's what I see in other big open source projects where
> sub
> >>>> teams are organized in repositories and they commit in such
> repositories
> >>>> while the "lieutenant" assemble the final "module" (this happen in 
> >>>> the
> >>>> same
> >>>> way all the way to root until reach the "dictator"). As we said, if
> we end
> >>>> in this model, the apache way will be less restricted in repo
> permissions
> >>>> and more conducted by the list where people will assign the tasks to 
> >>>> a
> >>>> single person.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> >>>>
> >>>> Hi Carlos,
> >>>>
> >>>> This merge you did make me think I didn't talk about this case on the
> wiki
> >>>> [1], so I updated it, in short, while it is good to start a branch as
> you
> >>>> did for a new jira ticket and as you may don't know the final number
> of
> >>>> commits you will have at the end, once it is the time to merge, you
> know
> >>>> the number of commits you did, if you realize you've got only one, it
> is
> >>>> better to do a 'git rebase <my_branch>' instead of a 'git merge
> --no-ff
> >>>> <my_branch>, the reason behind that is that you can avoid the extra
> merge
> >>>> commit, practically nothing change, except you will have a flat
> history
> >>>> which is what we want for only one commit and it could be
> reverse/reset
> >>>> the
> >>>> same if needed.
> >>>>
> >>>> Thanks,
> >>>> -Fred
> >>>>
> >>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> >>>> vs+Bad+Git+usage<
> >>>>
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
> >>>>
> >>>> -----Message d'origine----- From: carlosrovira@apache.org
> >>>> Sent: Wednesday, March 27, 2013 3:12 AM
> >>>> To: commits@flex.apache.org
> >>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> * FLEX-33349:
> >>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as
> after
> >>>> refreshing the dataProvider of Combobox.
> >>>>
> >>>>
> >>>> Project:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
> http://git-wip-us.ap
> >>>> ac
> >>>> he.org/repos/asf/flex-sdk/repo>
> >>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> >>>> 39fdf7fa <
> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> >>>> Tree:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
> http://gi
> >>>> t-
> >>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> >>>> Diff:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
> http://gi
> >>>> t-
> >>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
> >>>>
> >>>> Branch: refs/heads/develop
> >>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> >>>> Parents: 6282657 5ca083e
> >>>> Author: Carlos Rovira <ca...@gmail.com>
> >>>> Authored: Wed Mar 27 03:12:08 2013 +0100
> >>>> Committer: Carlos Rovira <ca...@gmail.com>
> >>>> Committed: Wed Mar 27 03:12:08 2013 +0100
> >>>>
> >>>>
> ------------------------------**------------------------------**----------
> >>>> .../projects/spark/src/spark/**components/List.as    |   23
> >>>> +++++++++++----
> >>>> 1 files changed, 17 insertions(+), 6 deletions(-)
> >>>>
> ------------------------------**------------------------------**----------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> Director de Tecnología
> >>>> M: +34 607 22 60 05
> >>>> F:  +34 912 94 80 80
> >>>> http://www.codeoscopic.com
> >>>> http://www.directwriter.es
> >>>> http://www.avant2.es
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Alex Harui <ah...@adobe.com>.

Hi Carlos,

If you could take the time to show an example where having a 1 commit branch
helped you "gain control" that would help me and probably others understand
the tradeoffs.


On 3/27/13 10:47 AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:

> Hi Alex,
> 
> as I said this is a matter of taste, but we are using git with huge
> projects for months and when we are merging and generating releases and we
> end wanting to easily see *all* branches to quickly see what we want to do,
> without taking care if a branch is 1 commit or 10, since this make you gain
> control of revert something if you need at some point in time. You end
> having more control and people not involved in a particular development can
> easily see what happened.
> 
> Right now I think is difficult to see since we are starting in GIT, but as
> GIT graph evolve we will see more complex representations and will be
> difficult to see quickly the GIT history. As I pass for that *problem*
> before, I already adopted the way to make always a branch although I have
> only one commit, but again, I recognized that it's a matter of tastes and
> it's difficult to sell the idea if you like not do it.
> 
> 
> 
> 2013/3/27 Alex Harui <ah...@adobe.com>
> 
>> I"m used to SVN's linear history. I like the fact that Git can show branch
>> history, and like the idea that I can do multiple commits before pushing
>> and
>> each of those commits is clearly shown in the history.
>> 
>> But if I don't want to show those multiple commits or I don't have multiple
>> commits, my instinct would be to just make it a linear entry.  I think
>> Carlos is saying there is some advantage to not doing that, and I want to
>> know what that advantage is.
>> 
>> 
>> On 3/27/13 10:06 AM, "Jose Barragan" <jo...@codeoscopic.com>
>> wrote:
>> 
>>> That's the point Alex...
>>> 
>>> Any  solve can resolve as a single commit or in a change set, and this
>>> decision, under what criterial it does?
>>> --
>>> Jose Barragan
>>> Chief Software Architect
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>> 
>>> On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> At minimum, if we can't decide on one particular practice, can we get a
>>>> better understanding of what problem is solved by a single commit in a
>>>> branch?  Then those who are trying to decide what to do can make a
>> better
>>>> decision.
>>>> 
>>>> 
>>>> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>>>> 
>>>>> Another point Carlos,
>>>>> 
>>>>>> this is really a matter of tastes. Each one should be happy with his
>> way
>>>>>> of proceed
>>>>> 
>>>>> What should I do a git wiki with the good practices if at the end
>> everyone
>>>>> does what he wants, I guess we can try as written in the wiki for one
>> month
>>>>> and if it doesn't fit we can change it (but really, I think everyone
>> will be
>>>>> happy with it).
>>>>> 
>>>>> Thanks,
>>>>> -Fred
>>>>> 
>>>>> -----Message d'origine-----
>>>>> From: Frédéric THOMAS
>>>>> Sent: Wednesday, March 27, 2013 5:22 PM
>>>>> To: dev@flex.apache.org
>>>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>>> 
>>>>> Yeah, for sure, it's your point of view and happily everyone's got one
>> and
>>>>> not everyone the same, but from what I see from the current graph on
>> the
>>>>> develop branch or the one gave by Jose plus the explanations you gave,
>> I
>>>>> have the impression to see and hear "Why should I do simple when I can
>> do
>>>>> complicated".
>>>>> 
>>>>> If you look closely to the ASCII graph I wrote, you might have noticed
>> there
>>>>> are no crossed lines, it's really linear, one commit/jira at time, I
>> really
>>>>> maintain it is more readable and reflect more what the people really
>>>>> develops, there's no artificial forced merge.
>>>>> 
>>>>> Thanks,
>>>>> -Fred
>>>>> 
>>>>> -----Message d'origine-----
>>>>> From: Carlos Rovira
>>>>> Sent: Wednesday, March 27, 2013 4:03 PM
>>>>> To: dev@flex.apache.org
>>>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>>> 
>>>>> IMHO this is hard to see, and even more for people outside or coming
>> some
>>>>> time later in time, but that's only my opinion... I think we should not
>>>>> stand too much on these topics and going forward since this is really a
>>>>> matter of tastes. Each one should be happy with his way of proceed
>> while
>>>>> making things properly since both ways are right. This is much more
>> like
>>>>> trying to realize how to format code, each developer will do in its own
>>>>> way....put the bracket in the same line? in the next line?. I think we
>>>>> should be more interested in the overall GIT workflow that ensure that
>> we
>>>>> all can share our contributions and make the repo safe of problems.
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>>>> 
>>>>>>  It should have been like that even:
>>>>>> 
>>>>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>>>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>>>>>>  *   FLEX-33451: Tempora...                              [Fred]
>>>>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>>>>>> *     FLEX-33349: Fix type error                          [Carlos]
>>>>>> *     removed copy of empty.bundles...            [Justin]
>>>>>> *     FLEX-28946 committed patch...                  [Cyrill]
>>>>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>>>>>  *   FLEX-21066: implemented remove item... [Carlos]
>>>>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>>>>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>>>>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>>>>>  *     ...
>>>>>> 
>>>>>> I hope that will be display well.
>>>>>> 
>>>>>> -Fred
>>>>>> 
>>>>>> *From:* Jose Barragan <jo...@codeoscopic.com>
>>>>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>>>>>> *To:* dev@flex.apache.org
>>>>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into
>> develop
>>>>>> 
>>>>>> Here's how it would Develop, after merging the branches of Charles and
>>>>>> Fred, as you can see, thereby properly appreciate the content of the
>> two
>>>>>> applied Tickets.
>>>>>> However, Justin's commit b5da14a, is visually hidden under the branch
>> of
>>>>>> Cyrill.
>>>>>> 
>>>>>> Thanks,
>>>>>>    --
>>>>>> *Jose Barragan*
>>>>>> *Chief **Software Architect*
>>>>>> Codeoscopic Madrid
>>>>>> C/. Infanta Mercedes, 92.
>>>>>> Planta 5.  505.
>>>>>> 28020 Madrid.
>>>>>> Tel.: +34 912 94 80 80
>>>>>> 
>>>>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <
>> webdoublefx@hotmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> Having the rule of one commit doesn't generated an extra merge commit
>> and
>>>>>> makes the log history more readable and because you know that
>> corresponds
>>>>>> to 1 single task/jira/file, it's still easy to find it back without
>> the
>>>>>> visual pollution of the extra useless merge commit.
>>>>>> 
>>>>>> For the dictator-lieutenant model, we're not as big as linux kernel,
>> maybe
>>>>>> one day, in between I wouldn't like to introduce hierarchy in an
>> apache
>>>>>> model where it doesn't fit, anyway, look at what I said for the
>> bugfix I
>>>>>> just shared, "I'll do the merge at the end" which means I'll re-write
>>>>>> commits in order, clean up what has to be clean if any, etc.., it's
>> not
>>>>>> the
>>>>>> dictator-lieutenant model but a collaborative one which say as a lazy
>>>>>> consensus someone will merge/ clean up at the end, as you can see at
>> the
>>>>>> end, no needs for a dictator model to do the same things as it is
>> useless
>>>>>> to use a gun to kill a fly.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Fred
>>>>>> 
>>>>>> -----Message d'origine----- From: Carlos Rovira
>>>>>> Sent: Wednesday, March 27, 2013 10:24 AM
>>>>>> To: dev@flex.apache.org
>>>>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>>>> 
>>>>>> Hi Frederic,
>>>>>> 
>>>>>> in our experience working with GIT we saw that was extremely helpful
>> to
>>>>>> have visual track of each set of commits that are a single fix,
>>>>>> functionality, feature or whatever, since you can always operate and
>> have
>>>>>> much control as branches grow and ramifies. In the particular case you
>>>>>> point (single commit - flat history) it's a matter of tastes but
>> making it
>>>>>> flat for this particular case makes you lost visibility as GIT
>> workflow
>>>>>> evolve over time. Right now we could make it flat (at this point of
>>>>>> simplicity), but I recommend not to do it since in few months we
>> should
>>>>>> expect more complex GIT graphs and this kind of loops will help to see
>>>>>> others what historically happen.
>>>>>> 
>>>>>> Apache Flex is so huge and modular and over time we should organize
>> in a
>>>>>> way that make us possible to plan huge releases with lots of modules,
>>>>>> changes and consistence between pieces. We are right now at the very
>>>>>> beginning trying to get the basic management and functionality but as
>>>>>> people will understand the full potential of the tool and the kind of
>>>>>> thinks we can now do, things will complicate. As we discussed in other
>>>>>> thread some weeks ago, I suspect that we will end in an
>>>>>> "dictator-lieutenant-apache" model (as we talked with Beltran the
>> apache
>>>>>> part is that decisions must be consolidated in this list to adopt such
>>>>>> model), since it's what I see in other big open source projects where
>> sub
>>>>>> teams are organized in repositories and they commit in such
>> repositories
>>>>>> while the "lieutenant" assemble the final "module" (this happen in the
>>>>>> same
>>>>>> way all the way to root until reach the "dictator"). As we said, if
>> we end
>>>>>> in this model, the apache way will be less restricted in repo
>> permissions
>>>>>> and more conducted by the list where people will assign the tasks to a
>>>>>> single person.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>>>>> 
>>>>>> Hi Carlos,
>>>>>> 
>>>>>> This merge you did make me think I didn't talk about this case on the
>> wiki
>>>>>> [1], so I updated it, in short, while it is good to start a branch as
>> you
>>>>>> did for a new jira ticket and as you may don't know the final number
>> of
>>>>>> commits you will have at the end, once it is the time to merge, you
>> know
>>>>>> the number of commits you did, if you realize you've got only one, it
>> is
>>>>>> better to do a 'git rebase <my_branch>' instead of a 'git merge
>> --no-ff
>>>>>> <my_branch>, the reason behind that is that you can avoid the extra
>> merge
>>>>>> commit, practically nothing change, except you will have a flat
>> history
>>>>>> which is what we want for only one commit and it could be
>> reverse/reset
>>>>>> the
>>>>>> same if needed.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Fred
>>>>>> 
>>>>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>>>>> vs+Bad+Git+usage<
>>>>>> 
>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>>>>> 
>>>>>> -----Message d'origine----- From: carlosrovira@apache.org
>>>>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>>>>> To: commits@flex.apache.org
>>>>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>>>> 
>>>>>> Merge branch 'FLEX-33349' into develop
>>>>>> 
>>>>>> * FLEX-33349:
>>>>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as
>> after
>>>>>> refreshing the dataProvider of Combobox.
>>>>>> 
>>>>>> 
>>>>>> Project:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
>> http://git-wip-us.ap
>>>>>> ac
>>>>>> he.org/repos/asf/flex-sdk/repo>
>>>>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>>>>> 39fdf7fa <
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>>>>> Tree:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
>> http://gi
>>>>>> t-
>>>>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>>>>> Diff:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
>> http://gi
>>>>>> t-
>>>>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>>>>> 
>>>>>> Branch: refs/heads/develop
>>>>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>>>>> Parents: 6282657 5ca083e
>>>>>> Author: Carlos Rovira <ca...@gmail.com>
>>>>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>>>>> Committer: Carlos Rovira <ca...@gmail.com>
>>>>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>>>>> 
>>>>>> 
>> ------------------------------**------------------------------**----------
>>>>>> .../projects/spark/src/spark/**components/List.as    |   23
>>>>>> +++++++++++----
>>>>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>>>> 
>> ------------------------------**------------------------------**----------
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> Director de Tecnología
>>>>>> M: +34 607 22 60 05
>>>>>> F:  +34 912 94 80 80
>>>>>> http://www.codeoscopic.com
>>>>>> http://www.directwriter.es
>>>>>> http://www.avant2.es
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>> 
>>> 
>> 
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
>> 
> 
> 
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Carlos Rovira <ca...@codeoscopic.com>.

Hi Alex,

as I said this is a matter of taste, but we are using git with huge
projects for months and when we are merging and generating releases and we
end wanting to easily see *all* branches to quickly see what we want to do,
without taking care if a branch is 1 commit or 10, since this make you gain
control of revert something if you need at some point in time. You end
having more control and people not involved in a particular development can
easily see what happened.

Right now I think is difficult to see since we are starting in GIT, but as
GIT graph evolve we will see more complex representations and will be
difficult to see quickly the GIT history. As I pass for that *problem*
before, I already adopted the way to make always a branch although I have
only one commit, but again, I recognized that it's a matter of tastes and
it's difficult to sell the idea if you like not do it.



2013/3/27 Alex Harui <ah...@adobe.com>

> I"m used to SVN's linear history. I like the fact that Git can show branch
> history, and like the idea that I can do multiple commits before pushing
> and
> each of those commits is clearly shown in the history.
>
> But if I don't want to show those multiple commits or I don't have multiple
> commits, my instinct would be to just make it a linear entry.  I think
> Carlos is saying there is some advantage to not doing that, and I want to
> know what that advantage is.
>
>
> On 3/27/13 10:06 AM, "Jose Barragan" <jo...@codeoscopic.com>
> wrote:
>
> > That's the point Alex...
> >
> > Any  solve can resolve as a single commit or in a change set, and this
> > decision, under what criterial it does?
> > --
> > Jose Barragan
> > Chief Software Architect
> > Codeoscopic Madrid
> > C/. Infanta Mercedes, 92.
> > Planta 5.  505.
> > 28020 Madrid.
> > Tel.: +34 912 94 80 80
> >
> > On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> At minimum, if we can't decide on one particular practice, can we get a
> >> better understanding of what problem is solved by a single commit in a
> >> branch?  Then those who are trying to decide what to do can make a
> better
> >> decision.
> >>
> >>
> >> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> >>
> >>> Another point Carlos,
> >>>
> >>>> this is really a matter of tastes. Each one should be happy with his
> way
> >>>> of proceed
> >>>
> >>> What should I do a git wiki with the good practices if at the end
> everyone
> >>> does what he wants, I guess we can try as written in the wiki for one
> month
> >>> and if it doesn't fit we can change it (but really, I think everyone
> will be
> >>> happy with it).
> >>>
> >>> Thanks,
> >>> -Fred
> >>>
> >>> -----Message d'origine-----
> >>> From: Frédéric THOMAS
> >>> Sent: Wednesday, March 27, 2013 5:22 PM
> >>> To: dev@flex.apache.org
> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>
> >>> Yeah, for sure, it's your point of view and happily everyone's got one
> and
> >>> not everyone the same, but from what I see from the current graph on
> the
> >>> develop branch or the one gave by Jose plus the explanations you gave,
> I
> >>> have the impression to see and hear "Why should I do simple when I can
> do
> >>> complicated".
> >>>
> >>> If you look closely to the ASCII graph I wrote, you might have noticed
> there
> >>> are no crossed lines, it's really linear, one commit/jira at time, I
> really
> >>> maintain it is more readable and reflect more what the people really
> >>> develops, there's no artificial forced merge.
> >>>
> >>> Thanks,
> >>> -Fred
> >>>
> >>> -----Message d'origine-----
> >>> From: Carlos Rovira
> >>> Sent: Wednesday, March 27, 2013 4:03 PM
> >>> To: dev@flex.apache.org
> >>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>
> >>> IMHO this is hard to see, and even more for people outside or coming
> some
> >>> time later in time, but that's only my opinion... I think we should not
> >>> stand too much on these topics and going forward since this is really a
> >>> matter of tastes. Each one should be happy with his way of proceed
> while
> >>> making things properly since both ways are right. This is much more
> like
> >>> trying to realize how to format code, each developer will do in its own
> >>> way....put the bracket in the same line? in the next line?. I think we
> >>> should be more interested in the overall GIT workflow that ensure that
> we
> >>> all can share our contributions and make the repo safe of problems.
> >>>
> >>>
> >>>
> >>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> >>>
> >>>>  It should have been like that even:
> >>>>
> >>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
> >>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
> >>>>  *   FLEX-33451: Tempora...                              [Fred]
> >>>>  *   FLEX-33451: Fix TLF                                     [Fred]
> >>>> *     FLEX-33349: Fix type error                          [Carlos]
> >>>> *     removed copy of empty.bundles...            [Justin]
> >>>> *     FLEX-28946 committed patch...                  [Cyrill]
> >>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
> >>>>  *   FLEX-21066: implemented remove item... [Carlos]
> >>>>  *   FLEX-21066: add removeItemError...          [Carlos]
> >>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
> >>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
> >>>>  *     ...
> >>>>
> >>>> I hope that will be display well.
> >>>>
> >>>> -Fred
> >>>>
> >>>> *From:* Jose Barragan <jo...@codeoscopic.com>
> >>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
> >>>> *To:* dev@flex.apache.org
> >>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into
> develop
> >>>>
> >>>> Here's how it would Develop, after merging the branches of Charles and
> >>>> Fred, as you can see, thereby properly appreciate the content of the
> two
> >>>> applied Tickets.
> >>>> However, Justin's commit b5da14a, is visually hidden under the branch
> of
> >>>> Cyrill.
> >>>>
> >>>> Thanks,
> >>>>    --
> >>>> *Jose Barragan*
> >>>> *Chief **Software Architect*
> >>>> Codeoscopic Madrid
> >>>> C/. Infanta Mercedes, 92.
> >>>> Planta 5.  505.
> >>>> 28020 Madrid.
> >>>> Tel.: +34 912 94 80 80
> >>>>
> >>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <
> webdoublefx@hotmail.com>
> >>>> wrote:
> >>>>
> >>>> Having the rule of one commit doesn't generated an extra merge commit
> and
> >>>> makes the log history more readable and because you know that
> corresponds
> >>>> to 1 single task/jira/file, it's still easy to find it back without
> the
> >>>> visual pollution of the extra useless merge commit.
> >>>>
> >>>> For the dictator-lieutenant model, we're not as big as linux kernel,
> maybe
> >>>> one day, in between I wouldn't like to introduce hierarchy in an
> apache
> >>>> model where it doesn't fit, anyway, look at what I said for the
> bugfix I
> >>>> just shared, "I'll do the merge at the end" which means I'll re-write
> >>>> commits in order, clean up what has to be clean if any, etc.., it's
> not
> >>>> the
> >>>> dictator-lieutenant model but a collaborative one which say as a lazy
> >>>> consensus someone will merge/ clean up at the end, as you can see at
> the
> >>>> end, no needs for a dictator model to do the same things as it is
> useless
> >>>> to use a gun to kill a fly.
> >>>>
> >>>> Thanks,
> >>>> -Fred
> >>>>
> >>>> -----Message d'origine----- From: Carlos Rovira
> >>>> Sent: Wednesday, March 27, 2013 10:24 AM
> >>>> To: dev@flex.apache.org
> >>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> Hi Frederic,
> >>>>
> >>>> in our experience working with GIT we saw that was extremely helpful
> to
> >>>> have visual track of each set of commits that are a single fix,
> >>>> functionality, feature or whatever, since you can always operate and
> have
> >>>> much control as branches grow and ramifies. In the particular case you
> >>>> point (single commit - flat history) it's a matter of tastes but
> making it
> >>>> flat for this particular case makes you lost visibility as GIT
> workflow
> >>>> evolve over time. Right now we could make it flat (at this point of
> >>>> simplicity), but I recommend not to do it since in few months we
> should
> >>>> expect more complex GIT graphs and this kind of loops will help to see
> >>>> others what historically happen.
> >>>>
> >>>> Apache Flex is so huge and modular and over time we should organize
> in a
> >>>> way that make us possible to plan huge releases with lots of modules,
> >>>> changes and consistence between pieces. We are right now at the very
> >>>> beginning trying to get the basic management and functionality but as
> >>>> people will understand the full potential of the tool and the kind of
> >>>> thinks we can now do, things will complicate. As we discussed in other
> >>>> thread some weeks ago, I suspect that we will end in an
> >>>> "dictator-lieutenant-apache" model (as we talked with Beltran the
> apache
> >>>> part is that decisions must be consolidated in this list to adopt such
> >>>> model), since it's what I see in other big open source projects where
> sub
> >>>> teams are organized in repositories and they commit in such
> repositories
> >>>> while the "lieutenant" assemble the final "module" (this happen in the
> >>>> same
> >>>> way all the way to root until reach the "dictator"). As we said, if
> we end
> >>>> in this model, the apache way will be less restricted in repo
> permissions
> >>>> and more conducted by the list where people will assign the tasks to a
> >>>> single person.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> >>>>
> >>>> Hi Carlos,
> >>>>
> >>>> This merge you did make me think I didn't talk about this case on the
> wiki
> >>>> [1], so I updated it, in short, while it is good to start a branch as
> you
> >>>> did for a new jira ticket and as you may don't know the final number
> of
> >>>> commits you will have at the end, once it is the time to merge, you
> know
> >>>> the number of commits you did, if you realize you've got only one, it
> is
> >>>> better to do a 'git rebase <my_branch>' instead of a 'git merge
> --no-ff
> >>>> <my_branch>, the reason behind that is that you can avoid the extra
> merge
> >>>> commit, practically nothing change, except you will have a flat
> history
> >>>> which is what we want for only one commit and it could be
> reverse/reset
> >>>> the
> >>>> same if needed.
> >>>>
> >>>> Thanks,
> >>>> -Fred
> >>>>
> >>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> >>>> vs+Bad+Git+usage<
> >>>>
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
> >>>>
> >>>> -----Message d'origine----- From: carlosrovira@apache.org
> >>>> Sent: Wednesday, March 27, 2013 3:12 AM
> >>>> To: commits@flex.apache.org
> >>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> Merge branch 'FLEX-33349' into develop
> >>>>
> >>>> * FLEX-33349:
> >>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as
> after
> >>>> refreshing the dataProvider of Combobox.
> >>>>
> >>>>
> >>>> Project:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
> http://git-wip-us.ap
> >>>> ac
> >>>> he.org/repos/asf/flex-sdk/repo>
> >>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> >>>> 39fdf7fa <
> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> >>>> Tree:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
> http://gi
> >>>> t-
> >>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> >>>> Diff:
> >>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
> http://gi
> >>>> t-
> >>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
> >>>>
> >>>> Branch: refs/heads/develop
> >>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> >>>> Parents: 6282657 5ca083e
> >>>> Author: Carlos Rovira <ca...@gmail.com>
> >>>> Authored: Wed Mar 27 03:12:08 2013 +0100
> >>>> Committer: Carlos Rovira <ca...@gmail.com>
> >>>> Committed: Wed Mar 27 03:12:08 2013 +0100
> >>>>
> >>>>
> ------------------------------**------------------------------**----------
> >>>> .../projects/spark/src/spark/**components/List.as    |   23
> >>>> +++++++++++----
> >>>> 1 files changed, 17 insertions(+), 6 deletions(-)
> >>>>
> ------------------------------**------------------------------**----------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> Director de Tecnología
> >>>> M: +34 607 22 60 05
> >>>> F:  +34 912 94 80 80
> >>>> http://www.codeoscopic.com
> >>>> http://www.directwriter.es
> >>>> http://www.avant2.es
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Alex Harui <ah...@adobe.com>.

I"m used to SVN's linear history. I like the fact that Git can show branch
history, and like the idea that I can do multiple commits before pushing and
each of those commits is clearly shown in the history.

But if I don't want to show those multiple commits or I don't have multiple
commits, my instinct would be to just make it a linear entry.  I think
Carlos is saying there is some advantage to not doing that, and I want to
know what that advantage is.


On 3/27/13 10:06 AM, "Jose Barragan" <jo...@codeoscopic.com> wrote:

> That's the point Alex...
> 
> Any  solve can resolve as a single commit or in a change set, and this
> decision, under what criterial it does?
> --
> Jose Barragan
> Chief Software Architect
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
> 
> On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:
> 
>> At minimum, if we can't decide on one particular practice, can we get a
>> better understanding of what problem is solved by a single commit in a
>> branch?  Then those who are trying to decide what to do can make a better
>> decision.
>> 
>> 
>> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>> 
>>> Another point Carlos,
>>> 
>>>> this is really a matter of tastes. Each one should be happy with his way
>>>> of proceed
>>> 
>>> What should I do a git wiki with the good practices if at the end everyone
>>> does what he wants, I guess we can try as written in the wiki for one month
>>> and if it doesn't fit we can change it (but really, I think everyone will be
>>> happy with it).
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> -----Message d'origine-----
>>> From: Frédéric THOMAS
>>> Sent: Wednesday, March 27, 2013 5:22 PM
>>> To: dev@flex.apache.org
>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Yeah, for sure, it's your point of view and happily everyone's got one and
>>> not everyone the same, but from what I see from the current graph on the
>>> develop branch or the one gave by Jose plus the explanations you gave, I
>>> have the impression to see and hear "Why should I do simple when I can do
>>> complicated".
>>> 
>>> If you look closely to the ASCII graph I wrote, you might have noticed there
>>> are no crossed lines, it's really linear, one commit/jira at time, I really
>>> maintain it is more readable and reflect more what the people really
>>> develops, there's no artificial forced merge.
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> -----Message d'origine-----
>>> From: Carlos Rovira
>>> Sent: Wednesday, March 27, 2013 4:03 PM
>>> To: dev@flex.apache.org
>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> IMHO this is hard to see, and even more for people outside or coming some
>>> time later in time, but that's only my opinion... I think we should not
>>> stand too much on these topics and going forward since this is really a
>>> matter of tastes. Each one should be happy with his way of proceed while
>>> making things properly since both ways are right. This is much more like
>>> trying to realize how to format code, each developer will do in its own
>>> way....put the bracket in the same line? in the next line?. I think we
>>> should be more interested in the overall GIT workflow that ensure that we
>>> all can share our contributions and make the repo safe of problems.
>>> 
>>> 
>>> 
>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>> 
>>>>  It should have been like that even:
>>>> 
>>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>>>>  *   FLEX-33451: Tempora...                              [Fred]
>>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>>>> *     FLEX-33349: Fix type error                          [Carlos]
>>>> *     removed copy of empty.bundles...            [Justin]
>>>> *     FLEX-28946 committed patch...                  [Cyrill]
>>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>>>  *   FLEX-21066: implemented remove item... [Carlos]
>>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>>>  *     ...
>>>> 
>>>> I hope that will be display well.
>>>> 
>>>> -Fred
>>>> 
>>>> *From:* Jose Barragan <jo...@codeoscopic.com>
>>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>>>> *To:* dev@flex.apache.org
>>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>> 
>>>> Here's how it would Develop, after merging the branches of Charles and
>>>> Fred, as you can see, thereby properly appreciate the content of the two
>>>> applied Tickets.
>>>> However, Justin's commit b5da14a, is visually hidden under the branch of
>>>> Cyrill.
>>>> 
>>>> Thanks,
>>>>    --
>>>> *Jose Barragan*
>>>> *Chief **Software Architect*
>>>> Codeoscopic Madrid
>>>> C/. Infanta Mercedes, 92.
>>>> Planta 5.  505.
>>>> 28020 Madrid.
>>>> Tel.: +34 912 94 80 80
>>>> 
>>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
>>>> wrote:
>>>> 
>>>> Having the rule of one commit doesn't generated an extra merge commit and
>>>> makes the log history more readable and because you know that corresponds
>>>> to 1 single task/jira/file, it's still easy to find it back without the
>>>> visual pollution of the extra useless merge commit.
>>>> 
>>>> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
>>>> one day, in between I wouldn't like to introduce hierarchy in an apache
>>>> model where it doesn't fit, anyway, look at what I said for the bugfix I
>>>> just shared, "I'll do the merge at the end" which means I'll re-write
>>>> commits in order, clean up what has to be clean if any, etc.., it's not
>>>> the
>>>> dictator-lieutenant model but a collaborative one which say as a lazy
>>>> consensus someone will merge/ clean up at the end, as you can see at the
>>>> end, no needs for a dictator model to do the same things as it is useless
>>>> to use a gun to kill a fly.
>>>> 
>>>> Thanks,
>>>> -Fred
>>>> 
>>>> -----Message d'origine----- From: Carlos Rovira
>>>> Sent: Wednesday, March 27, 2013 10:24 AM
>>>> To: dev@flex.apache.org
>>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>> 
>>>> Hi Frederic,
>>>> 
>>>> in our experience working with GIT we saw that was extremely helpful to
>>>> have visual track of each set of commits that are a single fix,
>>>> functionality, feature or whatever, since you can always operate and have
>>>> much control as branches grow and ramifies. In the particular case you
>>>> point (single commit - flat history) it's a matter of tastes but making it
>>>> flat for this particular case makes you lost visibility as GIT workflow
>>>> evolve over time. Right now we could make it flat (at this point of
>>>> simplicity), but I recommend not to do it since in few months we should
>>>> expect more complex GIT graphs and this kind of loops will help to see
>>>> others what historically happen.
>>>> 
>>>> Apache Flex is so huge and modular and over time we should organize in a
>>>> way that make us possible to plan huge releases with lots of modules,
>>>> changes and consistence between pieces. We are right now at the very
>>>> beginning trying to get the basic management and functionality but as
>>>> people will understand the full potential of the tool and the kind of
>>>> thinks we can now do, things will complicate. As we discussed in other
>>>> thread some weeks ago, I suspect that we will end in an
>>>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>>>> part is that decisions must be consolidated in this list to adopt such
>>>> model), since it's what I see in other big open source projects where sub
>>>> teams are organized in repositories and they commit in such repositories
>>>> while the "lieutenant" assemble the final "module" (this happen in the
>>>> same
>>>> way all the way to root until reach the "dictator"). As we said, if we end
>>>> in this model, the apache way will be less restricted in repo permissions
>>>> and more conducted by the list where people will assign the tasks to a
>>>> single person.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>>> 
>>>> Hi Carlos,
>>>> 
>>>> This merge you did make me think I didn't talk about this case on the wiki
>>>> [1], so I updated it, in short, while it is good to start a branch as you
>>>> did for a new jira ticket and as you may don't know the final number of
>>>> commits you will have at the end, once it is the time to merge, you know
>>>> the number of commits you did, if you realize you've got only one, it is
>>>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>>>> <my_branch>, the reason behind that is that you can avoid the extra merge
>>>> commit, practically nothing change, except you will have a flat history
>>>> which is what we want for only one commit and it could be reverse/reset
>>>> the
>>>> same if needed.
>>>> 
>>>> Thanks,
>>>> -Fred
>>>> 
>>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>>> vs+Bad+Git+usage<
>>>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>>> 
>>>> -----Message d'origine----- From: carlosrovira@apache.org
>>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>>> To: commits@flex.apache.org
>>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>>> 
>>>> Merge branch 'FLEX-33349' into develop
>>>> 
>>>> * FLEX-33349:
>>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>>>> refreshing the dataProvider of Combobox.
>>>> 
>>>> 
>>>> Project:
>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.ap
>>>> ac
>>>> he.org/repos/asf/flex-sdk/repo>
>>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>>> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>>> Tree:
>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://gi
>>>> t-
>>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>>> Diff:
>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://gi
>>>> t-
>>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>>> 
>>>> Branch: refs/heads/develop
>>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>>> Parents: 6282657 5ca083e
>>>> Author: Carlos Rovira <ca...@gmail.com>
>>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>>> Committer: Carlos Rovira <ca...@gmail.com>
>>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>>> 
>>>> ------------------------------**------------------------------**----------
>>>> .../projects/spark/src/spark/**components/List.as    |   23
>>>> +++++++++++----
>>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>> ------------------------------**------------------------------**----------
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Carlos Rovira
>>>> Director de Tecnología
>>>> M: +34 607 22 60 05
>>>> F:  +34 912 94 80 80
>>>> http://www.codeoscopic.com
>>>> http://www.directwriter.es
>>>> http://www.avant2.es
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragan <jo...@codeoscopic.com>.

That's the point Alex...

Any  solve can resolve as a single commit or in a change set, and this decision, under what criterial it does?
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 6:02 PM, Alex Harui <ah...@adobe.com> wrote:

> At minimum, if we can't decide on one particular practice, can we get a
> better understanding of what problem is solved by a single commit in a
> branch?  Then those who are trying to decide what to do can make a better
> decision.
> 
> 
> On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 
>> Another point Carlos,
>> 
>>> this is really a matter of tastes. Each one should be happy with his way
>>> of proceed
>> 
>> What should I do a git wiki with the good practices if at the end everyone
>> does what he wants, I guess we can try as written in the wiki for one month
>> and if it doesn't fit we can change it (but really, I think everyone will be
>> happy with it).
>> 
>> Thanks,
>> -Fred
>> 
>> -----Message d'origine-----
>> From: Frédéric THOMAS
>> Sent: Wednesday, March 27, 2013 5:22 PM
>> To: dev@flex.apache.org
>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>> Yeah, for sure, it's your point of view and happily everyone's got one and
>> not everyone the same, but from what I see from the current graph on the
>> develop branch or the one gave by Jose plus the explanations you gave, I
>> have the impression to see and hear "Why should I do simple when I can do
>> complicated".
>> 
>> If you look closely to the ASCII graph I wrote, you might have noticed there
>> are no crossed lines, it's really linear, one commit/jira at time, I really
>> maintain it is more readable and reflect more what the people really
>> develops, there's no artificial forced merge.
>> 
>> Thanks,
>> -Fred
>> 
>> -----Message d'origine-----
>> From: Carlos Rovira
>> Sent: Wednesday, March 27, 2013 4:03 PM
>> To: dev@flex.apache.org
>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>> IMHO this is hard to see, and even more for people outside or coming some
>> time later in time, but that's only my opinion... I think we should not
>> stand too much on these topics and going forward since this is really a
>> matter of tastes. Each one should be happy with his way of proceed while
>> making things properly since both ways are right. This is much more like
>> trying to realize how to format code, each developer will do in its own
>> way....put the bracket in the same line? in the next line?. I think we
>> should be more interested in the overall GIT workflow that ensure that we
>> all can share our contributions and make the repo safe of problems.
>> 
>> 
>> 
>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>> 
>>>  It should have been like that even:
>>> 
>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>>>  *   FLEX-33451: Tempora...                              [Fred]
>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>>> *     FLEX-33349: Fix type error                          [Carlos]
>>> *     removed copy of empty.bundles...            [Justin]
>>> *     FLEX-28946 committed patch...                  [Cyrill]
>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>>  *   FLEX-21066: implemented remove item... [Carlos]
>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>>  *     ...
>>> 
>>> I hope that will be display well.
>>> 
>>> -Fred
>>> 
>>> *From:* Jose Barragan <jo...@codeoscopic.com>
>>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>>> *To:* dev@flex.apache.org
>>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Here's how it would Develop, after merging the branches of Charles and
>>> Fred, as you can see, thereby properly appreciate the content of the two
>>> applied Tickets.
>>> However, Justin's commit b5da14a, is visually hidden under the branch of
>>> Cyrill.
>>> 
>>> Thanks,
>>>    --
>>> *Jose Barragan*
>>> *Chief **Software Architect*
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>> 
>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
>>> wrote:
>>> 
>>> Having the rule of one commit doesn't generated an extra merge commit and
>>> makes the log history more readable and because you know that corresponds
>>> to 1 single task/jira/file, it's still easy to find it back without the
>>> visual pollution of the extra useless merge commit.
>>> 
>>> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
>>> one day, in between I wouldn't like to introduce hierarchy in an apache
>>> model where it doesn't fit, anyway, look at what I said for the bugfix I
>>> just shared, "I'll do the merge at the end" which means I'll re-write
>>> commits in order, clean up what has to be clean if any, etc.., it's not
>>> the
>>> dictator-lieutenant model but a collaborative one which say as a lazy
>>> consensus someone will merge/ clean up at the end, as you can see at the
>>> end, no needs for a dictator model to do the same things as it is useless
>>> to use a gun to kill a fly.
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> -----Message d'origine----- From: Carlos Rovira
>>> Sent: Wednesday, March 27, 2013 10:24 AM
>>> To: dev@flex.apache.org
>>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Hi Frederic,
>>> 
>>> in our experience working with GIT we saw that was extremely helpful to
>>> have visual track of each set of commits that are a single fix,
>>> functionality, feature or whatever, since you can always operate and have
>>> much control as branches grow and ramifies. In the particular case you
>>> point (single commit - flat history) it's a matter of tastes but making it
>>> flat for this particular case makes you lost visibility as GIT workflow
>>> evolve over time. Right now we could make it flat (at this point of
>>> simplicity), but I recommend not to do it since in few months we should
>>> expect more complex GIT graphs and this kind of loops will help to see
>>> others what historically happen.
>>> 
>>> Apache Flex is so huge and modular and over time we should organize in a
>>> way that make us possible to plan huge releases with lots of modules,
>>> changes and consistence between pieces. We are right now at the very
>>> beginning trying to get the basic management and functionality but as
>>> people will understand the full potential of the tool and the kind of
>>> thinks we can now do, things will complicate. As we discussed in other
>>> thread some weeks ago, I suspect that we will end in an
>>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>>> part is that decisions must be consolidated in this list to adopt such
>>> model), since it's what I see in other big open source projects where sub
>>> teams are organized in repositories and they commit in such repositories
>>> while the "lieutenant" assemble the final "module" (this happen in the
>>> same
>>> way all the way to root until reach the "dictator"). As we said, if we end
>>> in this model, the apache way will be less restricted in repo permissions
>>> and more conducted by the list where people will assign the tasks to a
>>> single person.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>> 
>>> Hi Carlos,
>>> 
>>> This merge you did make me think I didn't talk about this case on the wiki
>>> [1], so I updated it, in short, while it is good to start a branch as you
>>> did for a new jira ticket and as you may don't know the final number of
>>> commits you will have at the end, once it is the time to merge, you know
>>> the number of commits you did, if you realize you've got only one, it is
>>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>>> <my_branch>, the reason behind that is that you can avoid the extra merge
>>> commit, practically nothing change, except you will have a flat history
>>> which is what we want for only one commit and it could be reverse/reset
>>> the
>>> same if needed.
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>> vs+Bad+Git+usage<
>>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>> 
>>> -----Message d'origine----- From: carlosrovira@apache.org
>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>> To: commits@flex.apache.org
>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Merge branch 'FLEX-33349' into develop
>>> 
>>> * FLEX-33349:
>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>>> refreshing the dataProvider of Combobox.
>>> 
>>> 
>>> Project:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apac
>>> he.org/repos/asf/flex-sdk/repo>
>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>> Tree:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-
>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>> Diff:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-
>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>> 
>>> Branch: refs/heads/develop
>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>> Parents: 6282657 5ca083e
>>> Author: Carlos Rovira <ca...@gmail.com>
>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>> Committer: Carlos Rovira <ca...@gmail.com>
>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>> 
>>> ------------------------------**------------------------------**----------
>>> .../projects/spark/src/spark/**components/List.as    |   23
>>> +++++++++++----
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>> ------------------------------**------------------------------**----------
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> Director de Tecnología
>>> M: +34 607 22 60 05
>>> F:  +34 912 94 80 80
>>> http://www.codeoscopic.com
>>> http://www.directwriter.es
>>> http://www.avant2.es
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Alex Harui <ah...@adobe.com>.

At minimum, if we can't decide on one particular practice, can we get a
better understanding of what problem is solved by a single commit in a
branch?  Then those who are trying to decide what to do can make a better
decision.


On 3/27/13 9:36 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:

> Another point Carlos,
> 
>> this is really a matter of tastes. Each one should be happy with his way
>> of proceed
> 
> What should I do a git wiki with the good practices if at the end everyone
> does what he wants, I guess we can try as written in the wiki for one month
> and if it doesn't fit we can change it (but really, I think everyone will be
> happy with it).
> 
> Thanks,
> -Fred
> 
> -----Message d'origine-----
> From: Frédéric THOMAS
> Sent: Wednesday, March 27, 2013 5:22 PM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> 
> Yeah, for sure, it's your point of view and happily everyone's got one and
> not everyone the same, but from what I see from the current graph on the
> develop branch or the one gave by Jose plus the explanations you gave, I
> have the impression to see and hear "Why should I do simple when I can do
> complicated".
> 
> If you look closely to the ASCII graph I wrote, you might have noticed there
> are no crossed lines, it's really linear, one commit/jira at time, I really
> maintain it is more readable and reflect more what the people really
> develops, there's no artificial forced merge.
> 
> Thanks,
> -Fred
> 
> -----Message d'origine-----
> From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 4:03 PM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> 
> IMHO this is hard to see, and even more for people outside or coming some
> time later in time, but that's only my opinion... I think we should not
> stand too much on these topics and going forward since this is really a
> matter of tastes. Each one should be happy with his way of proceed while
> making things properly since both ways are right. This is much more like
> trying to realize how to format code, each developer will do in its own
> way....put the bracket in the same line? in the next line?. I think we
> should be more interested in the overall GIT workflow that ensure that we
> all can share our contributions and make the repo safe of problems.
> 
> 
> 
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> 
>>   It should have been like that even:
>> 
>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>   *   FLEX-33451: Fixed .gitignore                      [Fred]
>>   *   FLEX-33451: Tempora...                              [Fred]
>>   *   FLEX-33451: Fix TLF                                     [Fred]
>> *     FLEX-33349: Fix type error                          [Carlos]
>> *     removed copy of empty.bundles...            [Justin]
>> *     FLEX-28946 committed patch...                  [Cyrill]
>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>   *   FLEX-21066: implemented remove item... [Carlos]
>>   *   FLEX-21066: add removeItemError...          [Carlos]
>>   *   FLEX-21066: add removeItem to list...        [Carlos]
>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>   *     ...
>> 
>> I hope that will be display well.
>> 
>> -Fred
>> 
>>  *From:* Jose Barragan <jo...@codeoscopic.com>
>> *Sent:* Wednesday, March 27, 2013 1:26 PM
>> *To:* dev@flex.apache.org
>> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>>  Here's how it would Develop, after merging the branches of Charles and
>> Fred, as you can see, thereby properly appreciate the content of the two
>> applied Tickets.
>> However, Justin's commit b5da14a, is visually hidden under the branch of
>> Cyrill.
>> 
>> Thanks,
>>     --
>> *Jose Barragan*
>> *Chief **Software Architect*
>> Codeoscopic Madrid
>> C/. Infanta Mercedes, 92.
>> Planta 5.  505.
>> 28020 Madrid.
>> Tel.: +34 912 94 80 80
>> 
>>  On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
>> wrote:
>> 
>> Having the rule of one commit doesn't generated an extra merge commit and
>> makes the log history more readable and because you know that corresponds
>> to 1 single task/jira/file, it's still easy to find it back without the
>> visual pollution of the extra useless merge commit.
>> 
>> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
>> one day, in between I wouldn't like to introduce hierarchy in an apache
>> model where it doesn't fit, anyway, look at what I said for the bugfix I
>> just shared, "I'll do the merge at the end" which means I'll re-write
>> commits in order, clean up what has to be clean if any, etc.., it's not
>> the
>> dictator-lieutenant model but a collaborative one which say as a lazy
>> consensus someone will merge/ clean up at the end, as you can see at the
>> end, no needs for a dictator model to do the same things as it is useless
>> to use a gun to kill a fly.
>> 
>> Thanks,
>> -Fred
>> 
>> -----Message d'origine----- From: Carlos Rovira
>> Sent: Wednesday, March 27, 2013 10:24 AM
>> To: dev@flex.apache.org
>> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>> Hi Frederic,
>> 
>> in our experience working with GIT we saw that was extremely helpful to
>> have visual track of each set of commits that are a single fix,
>> functionality, feature or whatever, since you can always operate and have
>> much control as branches grow and ramifies. In the particular case you
>> point (single commit - flat history) it's a matter of tastes but making it
>> flat for this particular case makes you lost visibility as GIT workflow
>> evolve over time. Right now we could make it flat (at this point of
>> simplicity), but I recommend not to do it since in few months we should
>> expect more complex GIT graphs and this kind of loops will help to see
>> others what historically happen.
>> 
>> Apache Flex is so huge and modular and over time we should organize in a
>> way that make us possible to plan huge releases with lots of modules,
>> changes and consistence between pieces. We are right now at the very
>> beginning trying to get the basic management and functionality but as
>> people will understand the full potential of the tool and the kind of
>> thinks we can now do, things will complicate. As we discussed in other
>> thread some weeks ago, I suspect that we will end in an
>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>> part is that decisions must be consolidated in this list to adopt such
>> model), since it's what I see in other big open source projects where sub
>> teams are organized in repositories and they commit in such repositories
>> while the "lieutenant" assemble the final "module" (this happen in the
>> same
>> way all the way to root until reach the "dictator"). As we said, if we end
>> in this model, the apache way will be less restricted in repo permissions
>> and more conducted by the list where people will assign the tasks to a
>> single person.
>> 
>> 
>> 
>> 
>> 
>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>> 
>> Hi Carlos,
>> 
>> This merge you did make me think I didn't talk about this case on the wiki
>> [1], so I updated it, in short, while it is good to start a branch as you
>> did for a new jira ticket and as you may don't know the final number of
>> commits you will have at the end, once it is the time to merge, you know
>> the number of commits you did, if you realize you've got only one, it is
>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>> <my_branch>, the reason behind that is that you can avoid the extra merge
>> commit, practically nothing change, except you will have a flat history
>> which is what we want for only one commit and it could be reverse/reset
>> the
>> same if needed.
>> 
>> Thanks,
>> -Fred
>> 
>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>> vs+Bad+Git+usage<
>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>> 
>> -----Message d'origine----- From: carlosrovira@apache.org
>> Sent: Wednesday, March 27, 2013 3:12 AM
>> To: commits@flex.apache.org
>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>> Merge branch 'FLEX-33349' into develop
>> 
>> * FLEX-33349:
>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>> refreshing the dataProvider of Combobox.
>> 
>> 
>> Project:
>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apac
>> he.org/repos/asf/flex-sdk/repo>
>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>> Tree:
>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-
>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>> Diff:
>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-
>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>> 
>> Branch: refs/heads/develop
>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>> Parents: 6282657 5ca083e
>> Author: Carlos Rovira <ca...@gmail.com>
>> Authored: Wed Mar 27 03:12:08 2013 +0100
>> Committer: Carlos Rovira <ca...@gmail.com>
>> Committed: Wed Mar 27 03:12:08 2013 +0100
>> 
>> ------------------------------**------------------------------**----------
>> .../projects/spark/src/spark/**components/List.as    |   23
>> +++++++++++----
>> 1 files changed, 17 insertions(+), 6 deletions(-)
>> ------------------------------**------------------------------**----------
>> 
>> 
>> 
>> 
>> 
>> --
>> Carlos Rovira
>> Director de Tecnología
>> M: +34 607 22 60 05
>> F:  +34 912 94 80 80
>> http://www.codeoscopic.com
>> http://www.directwriter.es
>> http://www.avant2.es
>> 
>> 
>> 
> 
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

Another point Carlos,

> this is really a matter of tastes. Each one should be happy with his way 
> of proceed

What should I do a git wiki with the good practices if at the end everyone 
does what he wants, I guess we can try as written in the wiki for one month 
and if it doesn't fit we can change it (but really, I think everyone will be 
happy with it).

Thanks,
-Fred

-----Message d'origine----- 
From: Frédéric THOMAS
Sent: Wednesday, March 27, 2013 5:22 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Yeah, for sure, it's your point of view and happily everyone's got one and
not everyone the same, but from what I see from the current graph on the
develop branch or the one gave by Jose plus the explanations you gave, I
have the impression to see and hear "Why should I do simple when I can do
complicated".

If you look closely to the ASCII graph I wrote, you might have noticed there
are no crossed lines, it's really linear, one commit/jira at time, I really
maintain it is more readable and reflect more what the people really
develops, there's no artificial forced merge.

Thanks,
-Fred

-----Message d'origine----- 
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

IMHO this is hard to see, and even more for people outside or coming some
time later in time, but that's only my opinion... I think we should not
stand too much on these topics and going forward since this is really a
matter of tastes. Each one should be happy with his way of proceed while
making things properly since both ways are right. This is much more like
trying to realize how to format code, each developer will do in its own
way....put the bracket in the same line? in the next line?. I think we
should be more interested in the overall GIT workflow that ensure that we
all can share our contributions and make the repo safe of problems.



2013/3/27 Frédéric THOMAS <we...@hotmail.com>

>   It should have been like that even:
>
> *     Merge branch ‘FLEX-33451’ into develop [Fred]
>   *   FLEX-33451: Fixed .gitignore                      [Fred]
>   *   FLEX-33451: Tempora...                              [Fred]
>   *   FLEX-33451: Fix TLF                                     [Fred]
> *     FLEX-33349: Fix type error                          [Carlos]
> *     removed copy of empty.bundles...            [Justin]
> *     FLEX-28946 committed patch...                  [Cyrill]
> *     Merge branch ‘FLEX-21066’ into develop  [Carlos]
>   *   FLEX-21066: implemented remove item... [Carlos]
>   *   FLEX-21066: add removeItemError...          [Carlos]
>   *   FLEX-21066: add removeItem to list...        [Carlos]
> *     Merge branch ‘FLEX-33408’ into develop   [Carlos]
>   *     ...
>
> I hope that will be display well.
>
> -Fred
>
>  *From:* Jose Barragan <jo...@codeoscopic.com>
> *Sent:* Wednesday, March 27, 2013 1:26 PM
> *To:* dev@flex.apache.org
> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
>  Here's how it would Develop, after merging the branches of Charles and
> Fred, as you can see, thereby properly appreciate the content of the two
> applied Tickets.
> However, Justin's commit b5da14a, is visually hidden under the branch of
> Cyrill.
>
> Thanks,
>     --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
>  On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
> wrote:
>
> Having the rule of one commit doesn't generated an extra merge commit and
> makes the log history more readable and because you know that corresponds
> to 1 single task/jira/file, it's still easy to find it back without the
> visual pollution of the extra useless merge commit.
>
> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
> one day, in between I wouldn't like to introduce hierarchy in an apache
> model where it doesn't fit, anyway, look at what I said for the bugfix I
> just shared, "I'll do the merge at the end" which means I'll re-write
> commits in order, clean up what has to be clean if any, etc.., it's not 
> the
> dictator-lieutenant model but a collaborative one which say as a lazy
> consensus someone will merge/ clean up at the end, as you can see at the
> end, no needs for a dictator model to do the same things as it is useless
> to use a gun to kill a fly.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 10:24 AM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Hi Frederic,
>
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
>
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the 
> same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
>
>
>
>
>
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>
> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset 
> the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
>
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

Yeah, for sure, it's your point of view and happily everyone's got one and 
not everyone the same, but from what I see from the current graph on the 
develop branch or the one gave by Jose plus the explanations you gave, I 
have the impression to see and hear "Why should I do simple when I can do 
complicated".

If you look closely to the ASCII graph I wrote, you might have noticed there 
are no crossed lines, it's really linear, one commit/jira at time, I really 
maintain it is more readable and reflect more what the people really 
develops, there's no artificial forced merge.

Thanks,
-Fred

-----Message d'origine----- 
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

IMHO this is hard to see, and even more for people outside or coming some
time later in time, but that's only my opinion... I think we should not
stand too much on these topics and going forward since this is really a
matter of tastes. Each one should be happy with his way of proceed while
making things properly since both ways are right. This is much more like
trying to realize how to format code, each developer will do in its own
way....put the bracket in the same line? in the next line?. I think we
should be more interested in the overall GIT workflow that ensure that we
all can share our contributions and make the repo safe of problems.



2013/3/27 Frédéric THOMAS <we...@hotmail.com>

>   It should have been like that even:
>
> *     Merge branch ‘FLEX-33451’ into develop [Fred]
>   *   FLEX-33451: Fixed .gitignore                      [Fred]
>   *   FLEX-33451: Tempora...                              [Fred]
>   *   FLEX-33451: Fix TLF                                     [Fred]
> *     FLEX-33349: Fix type error                          [Carlos]
> *     removed copy of empty.bundles...            [Justin]
> *     FLEX-28946 committed patch...                  [Cyrill]
> *     Merge branch ‘FLEX-21066’ into develop  [Carlos]
>   *   FLEX-21066: implemented remove item... [Carlos]
>   *   FLEX-21066: add removeItemError...          [Carlos]
>   *   FLEX-21066: add removeItem to list...        [Carlos]
> *     Merge branch ‘FLEX-33408’ into develop   [Carlos]
>   *     ...
>
> I hope that will be display well.
>
> -Fred
>
>  *From:* Jose Barragan <jo...@codeoscopic.com>
> *Sent:* Wednesday, March 27, 2013 1:26 PM
> *To:* dev@flex.apache.org
> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
>  Here's how it would Develop, after merging the branches of Charles and
> Fred, as you can see, thereby properly appreciate the content of the two
> applied Tickets.
> However, Justin's commit b5da14a, is visually hidden under the branch of
> Cyrill.
>
> Thanks,
>     --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
>  On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
> wrote:
>
> Having the rule of one commit doesn't generated an extra merge commit and
> makes the log history more readable and because you know that corresponds
> to 1 single task/jira/file, it's still easy to find it back without the
> visual pollution of the extra useless merge commit.
>
> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
> one day, in between I wouldn't like to introduce hierarchy in an apache
> model where it doesn't fit, anyway, look at what I said for the bugfix I
> just shared, "I'll do the merge at the end" which means I'll re-write
> commits in order, clean up what has to be clean if any, etc.., it's not 
> the
> dictator-lieutenant model but a collaborative one which say as a lazy
> consensus someone will merge/ clean up at the end, as you can see at the
> end, no needs for a dictator model to do the same things as it is useless
> to use a gun to kill a fly.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 10:24 AM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Hi Frederic,
>
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
>
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the 
> same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
>
>
>
>
>
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>
> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset 
> the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
>
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Carlos Rovira <ca...@codeoscopic.com>.

IMHO this is hard to see, and even more for people outside or coming some
time later in time, but that's only my opinion... I think we should not
stand too much on these topics and going forward since this is really a
matter of tastes. Each one should be happy with his way of proceed while
making things properly since both ways are right. This is much more like
trying to realize how to format code, each developer will do in its own
way....put the bracket in the same line? in the next line?. I think we
should be more interested in the overall GIT workflow that ensure that we
all can share our contributions and make the repo safe of problems.



2013/3/27 Frédéric THOMAS <we...@hotmail.com>

>   It should have been like that even:
>
> *     Merge branch ‘FLEX-33451’ into develop [Fred]
>   *   FLEX-33451: Fixed .gitignore                      [Fred]
>   *   FLEX-33451: Tempora...                              [Fred]
>   *   FLEX-33451: Fix TLF                                     [Fred]
> *     FLEX-33349: Fix type error                          [Carlos]
> *     removed copy of empty.bundles...            [Justin]
> *     FLEX-28946 committed patch...                  [Cyrill]
> *     Merge branch ‘FLEX-21066’ into develop  [Carlos]
>   *   FLEX-21066: implemented remove item... [Carlos]
>   *   FLEX-21066: add removeItemError...          [Carlos]
>   *   FLEX-21066: add removeItem to list...        [Carlos]
> *     Merge branch ‘FLEX-33408’ into develop   [Carlos]
>   *     ...
>
> I hope that will be display well.
>
> -Fred
>
>  *From:* Jose Barragan <jo...@codeoscopic.com>
> *Sent:* Wednesday, March 27, 2013 1:26 PM
> *To:* dev@flex.apache.org
> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
>  Here's how it would Develop, after merging the branches of Charles and
> Fred, as you can see, thereby properly appreciate the content of the two
> applied Tickets.
> However, Justin's commit b5da14a, is visually hidden under the branch of
> Cyrill.
>
> Thanks,
>     --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
>  On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com>
> wrote:
>
> Having the rule of one commit doesn't generated an extra merge commit and
> makes the log history more readable and because you know that corresponds
> to 1 single task/jira/file, it's still easy to find it back without the
> visual pollution of the extra useless merge commit.
>
> For the dictator-lieutenant model, we're not as big as linux kernel, maybe
> one day, in between I wouldn't like to introduce hierarchy in an apache
> model where it doesn't fit, anyway, look at what I said for the bugfix I
> just shared, "I'll do the merge at the end" which means I'll re-write
> commits in order, clean up what has to be clean if any, etc.., it's not the
> dictator-lieutenant model but a collaborative one which say as a lazy
> consensus someone will merge/ clean up at the end, as you can see at the
> end, no needs for a dictator model to do the same things as it is useless
> to use a gun to kill a fly.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 10:24 AM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Hi Frederic,
>
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
>
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
>
>
>
>
>
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>
> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
>
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

It should have been like that even:

*     Merge branch ‘FLEX-33451’ into develop [Fred]
  *   FLEX-33451: Fixed .gitignore                      [Fred]
  *   FLEX-33451: Tempora...                              [Fred]
  *   FLEX-33451: Fix TLF                                     [Fred]
*     FLEX-33349: Fix type error                          [Carlos]
*     removed copy of empty.bundles...            [Justin]
*     FLEX-28946 committed patch...                  [Cyrill]
*     Merge branch ‘FLEX-21066’ into develop  [Carlos]
  *   FLEX-21066: implemented remove item... [Carlos]
  *   FLEX-21066: add removeItemError...          [Carlos]
  *   FLEX-21066: add removeItem to list...        [Carlos]
*     Merge branch ‘FLEX-33408’ into develop   [Carlos]
  *     ...

I hope that will be display well.

-Fred

From: Jose Barragan 
Sent: Wednesday, March 27, 2013 1:26 PM
To: dev@flex.apache.org 
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Here's how it would Develop, after merging the branches of Charles and Fred, as you can see, thereby properly appreciate the content of the two applied Tickets. 
However, Justin's commit b5da14a, is visually hidden under the branch of Cyrill.

 
Thanks,

--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid 
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com> wrote:


  Having the rule of one commit doesn't generated an extra merge commit and makes the log history more readable and because you know that corresponds to 1 single task/jira/file, it's still easy to find it back without the visual pollution of the extra useless merge commit.

  For the dictator-lieutenant model, we're not as big as linux kernel, maybe one day, in between I wouldn't like to introduce hierarchy in an apache model where it doesn't fit, anyway, look at what I said for the bugfix I just shared, "I'll do the merge at the end" which means I'll re-write commits in order, clean up what has to be clean if any, etc.., it's not the dictator-lieutenant model but a collaborative one which say as a lazy consensus someone will merge/ clean up at the end, as you can see at the end, no needs for a dictator model to do the same things as it is useless to use a gun to kill a fly.

  Thanks,
  -Fred

  -----Message d'origine----- From: Carlos Rovira
  Sent: Wednesday, March 27, 2013 10:24 AM
  To: dev@flex.apache.org
  Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

  Hi Frederic,

  in our experience working with GIT we saw that was extremely helpful to
  have visual track of each set of commits that are a single fix,
  functionality, feature or whatever, since you can always operate and have
  much control as branches grow and ramifies. In the particular case you
  point (single commit - flat history) it's a matter of tastes but making it
  flat for this particular case makes you lost visibility as GIT workflow
  evolve over time. Right now we could make it flat (at this point of
  simplicity), but I recommend not to do it since in few months we should
  expect more complex GIT graphs and this kind of loops will help to see
  others what historically happen.

  Apache Flex is so huge and modular and over time we should organize in a
  way that make us possible to plan huge releases with lots of modules,
  changes and consistence between pieces. We are right now at the very
  beginning trying to get the basic management and functionality but as
  people will understand the full potential of the tool and the kind of
  thinks we can now do, things will complicate. As we discussed in other
  thread some weeks ago, I suspect that we will end in an
  "dictator-lieutenant-apache" model (as we talked with Beltran the apache
  part is that decisions must be consolidated in this list to adopt such
  model), since it's what I see in other big open source projects where sub
  teams are organized in repositories and they commit in such repositories
  while the "lieutenant" assemble the final "module" (this happen in the same
  way all the way to root until reach the "dictator"). As we said, if we end
  in this model, the apache way will be less restricted in repo permissions
  and more conducted by the list where people will assign the tasks to a
  single person.





  2013/3/27 Frédéric THOMAS <we...@hotmail.com>


    Hi Carlos,

    This merge you did make me think I didn't talk about this case on the wiki
    [1], so I updated it, in short, while it is good to start a branch as you
    did for a new jira ticket and as you may don't know the final number of
    commits you will have at the end, once it is the time to merge, you know
    the number of commits you did, if you realize you've got only one, it is
    better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
    <my_branch>, the reason behind that is that you can avoid the extra merge
    commit, practically nothing change, except you will have a flat history
    which is what we want for only one commit and it could be reverse/reset the
    same if needed.

    Thanks,
    -Fred

    [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
    vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>

    -----Message d'origine----- From: carlosrovira@apache.org
    Sent: Wednesday, March 27, 2013 3:12 AM
    To: commits@flex.apache.org
    Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop

    Merge branch 'FLEX-33349' into develop

    * FLEX-33349:
    Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
    refreshing the dataProvider of Combobox.


    Project: http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
    Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
    39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
    Tree: http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
    Diff: http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>

    Branch: refs/heads/develop
    Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
    Parents: 6282657 5ca083e
    Author: Carlos Rovira <ca...@gmail.com>
    Authored: Wed Mar 27 03:12:08 2013 +0100
    Committer: Carlos Rovira <ca...@gmail.com>
    Committed: Wed Mar 27 03:12:08 2013 +0100

    ------------------------------**------------------------------**----------
    .../projects/spark/src/spark/**components/List.as    |   23
    +++++++++++----
    1 files changed, 17 insertions(+), 6 deletions(-)
    ------------------------------**------------------------------**----------






  -- 
  Carlos Rovira
  Director de Tecnología
  M: +34 607 22 60 05
  F:  +34 912 94 80 80
  http://www.codeoscopic.com
  http://www.directwriter.es
  http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragan <jo...@codeoscopic.com>.

Here's how it would Develop, after merging the branches of Charles and Fred, as you can see, thereby properly appreciate the content of the two applied Tickets. 
However, Justin's commit b5da14a, is visually hidden under the branch of Cyrill.


Thanks,
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <we...@hotmail.com> wrote:

> Having the rule of one commit doesn't generated an extra merge commit and makes the log history more readable and because you know that corresponds to 1 single task/jira/file, it's still easy to find it back without the visual pollution of the extra useless merge commit.
> 
> For the dictator-lieutenant model, we're not as big as linux kernel, maybe one day, in between I wouldn't like to introduce hierarchy in an apache model where it doesn't fit, anyway, look at what I said for the bugfix I just shared, "I'll do the merge at the end" which means I'll re-write commits in order, clean up what has to be clean if any, etc.., it's not the dictator-lieutenant model but a collaborative one which say as a lazy consensus someone will merge/ clean up at the end, as you can see at the end, no needs for a dictator model to do the same things as it is useless to use a gun to kill a fly.
> 
> Thanks,
> -Fred
> 
> -----Message d'origine----- From: Carlos Rovira
> Sent: Wednesday, March 27, 2013 10:24 AM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> 
> Hi Frederic,
> 
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
> 
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
> 
> 
> 
> 
> 
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> 
>> Hi Carlos,
>> 
>> This merge you did make me think I didn't talk about this case on the wiki
>> [1], so I updated it, in short, while it is good to start a branch as you
>> did for a new jira ticket and as you may don't know the final number of
>> commits you will have at the end, once it is the time to merge, you know
>> the number of commits you did, if you realize you've got only one, it is
>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>> <my_branch>, the reason behind that is that you can avoid the extra merge
>> commit, practically nothing change, except you will have a flat history
>> which is what we want for only one commit and it could be reverse/reset the
>> same if needed.
>> 
>> Thanks,
>> -Fred
>> 
>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>> vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>> 
>> -----Message d'origine----- From: carlosrovira@apache.org
>> Sent: Wednesday, March 27, 2013 3:12 AM
>> To: commits@flex.apache.org
>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>> 
>> Merge branch 'FLEX-33349' into develop
>> 
>> * FLEX-33349:
>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>> refreshing the dataProvider of Combobox.
>> 
>> 
>> Project: http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>> Tree: http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>> Diff: http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>> 
>> Branch: refs/heads/develop
>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>> Parents: 6282657 5ca083e
>> Author: Carlos Rovira <ca...@gmail.com>
>> Authored: Wed Mar 27 03:12:08 2013 +0100
>> Committer: Carlos Rovira <ca...@gmail.com>
>> Committed: Wed Mar 27 03:12:08 2013 +0100
>> 
>> ------------------------------**------------------------------**----------
>> .../projects/spark/src/spark/**components/List.as    |   23
>> +++++++++++----
>> 1 files changed, 17 insertions(+), 6 deletions(-)
>> ------------------------------**------------------------------**----------
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Frédéric THOMAS <we...@hotmail.com>.

Having the rule of one commit doesn't generated an extra merge commit and 
makes the log history more readable and because you know that corresponds to 
1 single task/jira/file, it's still easy to find it back without the visual 
pollution of the extra useless merge commit.

For the dictator-lieutenant model, we're not as big as linux kernel, maybe 
one day, in between I wouldn't like to introduce hierarchy in an apache 
model where it doesn't fit, anyway, look at what I said for the bugfix I 
just shared, "I'll do the merge at the end" which means I'll re-write 
commits in order, clean up what has to be clean if any, etc.., it's not the 
dictator-lieutenant model but a collaborative one which say as a lazy 
consensus someone will merge/ clean up at the end, as you can see at the 
end, no needs for a dictator model to do the same things as it is useless to 
use a gun to kill a fly.

Thanks,
-Fred

-----Message d'origine----- 
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 10:24 AM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Hi Frederic,

in our experience working with GIT we saw that was extremely helpful to
have visual track of each set of commits that are a single fix,
functionality, feature or whatever, since you can always operate and have
much control as branches grow and ramifies. In the particular case you
point (single commit - flat history) it's a matter of tastes but making it
flat for this particular case makes you lost visibility as GIT workflow
evolve over time. Right now we could make it flat (at this point of
simplicity), but I recommend not to do it since in few months we should
expect more complex GIT graphs and this kind of loops will help to see
others what historically happen.

Apache Flex is so huge and modular and over time we should organize in a
way that make us possible to plan huge releases with lots of modules,
changes and consistence between pieces. We are right now at the very
beginning trying to get the basic management and functionality but as
people will understand the full potential of the tool and the kind of
thinks we can now do, things will complicate. As we discussed in other
thread some weeks ago, I suspect that we will end in an
"dictator-lieutenant-apache" model (as we talked with Beltran the apache
part is that decisions must be consolidated in this list to adopt such
model), since it's what I see in other big open source projects where sub
teams are organized in repositories and they commit in such repositories
while the "lieutenant" assemble the final "module" (this happen in the same
way all the way to root until reach the "dictator"). As we said, if we end
in this model, the apache way will be less restricted in repo permissions
and more conducted by the list where people will assign the tasks to a
single person.





2013/3/27 Frédéric THOMAS <we...@hotmail.com>

> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset 
> the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
>  Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project: 
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree: 
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff: 
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragan <jo...@codeoscopic.com>.

Thanks Carlos, and sorry for the inconvenience
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 10:58 AM, Carlos Rovira <ca...@codeoscopic.com> wrote:

> Hi Pepe, the link is tokenized for your use. Here's the public link:
> 
> http://refcardz.dzone.com/refcardz/git-patterns-and-anti-patterns
> 
> Thanks
> 
> Carlos
> 
> 
> 
> 2013/3/27 Jose Barragán <jo...@codeoscopic.com>
> 
>> Sorry for missing link: Git Patterns and Anti-Patterns: Scaling from
>> Workgroup to Enterprise<
>> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
>>> 
>> -->
>> 
>> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
>> 
>> On Wed, Mar 27, 2013 at 10:41 AM, Jose Barragan <
>> jose.barragan@codeoscopic.com> wrote:
>> 
>>> +1 with Carlos
>>> 
>>> check it out this:  Git Patterns and Anti-Patterns: Scaling from
>>> Workgroup to Enterprise<
>> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
>>> 
>>> --
>>> *Jose Barragan*
>>> *Chief **Software Architect*
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>> 
>>> On Mar 27, 2013, at 10:35 AM, Jose Barragan <
>> jose.barragan@codeoscopic.com>
>>> wrote:
>>> 
>>> +1 with Carlos
>>> <rc178-010d-git-patterns-antipatterns_1.pdf>
>>> 
>>> --
>>> *Jose Barragan*
>>> *Chief **Software Architect*
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>> 
>>> On Mar 27, 2013, at 10:24 AM, Carlos Rovira <
>> carlos.rovira@codeoscopic.com>
>>> wrote:
>>> 
>>> Hi Frederic,
>>> 
>>> in our experience working with GIT we saw that was extremely helpful to
>>> have visual track of each set of commits that are a single fix,
>>> functionality, feature or whatever, since you can always operate and have
>>> much control as branches grow and ramifies. In the particular case you
>>> point (single commit - flat history) it's a matter of tastes but making
>> it
>>> flat for this particular case makes you lost visibility as GIT workflow
>>> evolve over time. Right now we could make it flat (at this point of
>>> simplicity), but I recommend not to do it since in few months we should
>>> expect more complex GIT graphs and this kind of loops will help to see
>>> others what historically happen.
>>> 
>>> Apache Flex is so huge and modular and over time we should organize in a
>>> way that make us possible to plan huge releases with lots of modules,
>>> changes and consistence between pieces. We are right now at the very
>>> beginning trying to get the basic management and functionality but as
>>> people will understand the full potential of the tool and the kind of
>>> thinks we can now do, things will complicate. As we discussed in other
>>> thread some weeks ago, I suspect that we will end in an
>>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>>> part is that decisions must be consolidated in this list to adopt such
>>> model), since it's what I see in other big open source projects where sub
>>> teams are organized in repositories and they commit in such repositories
>>> while the "lieutenant" assemble the final "module" (this happen in the
>> same
>>> way all the way to root until reach the "dictator"). As we said, if we
>> end
>>> in this model, the apache way will be less restricted in repo permissions
>>> and more conducted by the list where people will assign the tasks to a
>>> single person.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>>> 
>>> Hi Carlos,
>>> 
>>> This merge you did make me think I didn't talk about this case on the
>> wiki
>>> [1], so I updated it, in short, while it is good to start a branch as you
>>> did for a new jira ticket and as you may don't know the final number of
>>> commits you will have at the end, once it is the time to merge, you know
>>> the number of commits you did, if you realize you've got only one, it is
>>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>>> <my_branch>, the reason behind that is that you can avoid the extra merge
>>> commit, practically nothing change, except you will have a flat history
>>> which is what we want for only one commit and it could be reverse/reset
>> the
>>> same if needed.
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>> vs+Bad+Git+usage<
>>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>> 
>>> -----Message d'origine----- From: carlosrovira@apache.org
>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>> To: commits@flex.apache.org
>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Merge branch 'FLEX-33349' into develop
>>> 
>>> * FLEX-33349:
>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>>> refreshing the dataProvider of Combobox.
>>> 
>>> 
>>> Project:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>> 39fdf7fa <
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>> Tree:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>> Diff:
>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>> 
>>> Branch: refs/heads/develop
>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>> Parents: 6282657 5ca083e
>>> Author: Carlos Rovira <ca...@gmail.com>
>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>> Committer: Carlos Rovira <ca...@gmail.com>
>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>> 
>>> 
>> ------------------------------**------------------------------**----------
>>> .../projects/spark/src/spark/**components/List.as    |   23
>>> +++++++++++----
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>> 
>> ------------------------------**------------------------------**----------
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> Director de Tecnología
>>> M: +34 607 22 60 05
>>> F:  +34 912 94 80 80
>>> http://www.codeoscopic.com
>>> http://www.directwriter.es
>>> http://www.avant2.es
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Carlos Rovira <ca...@codeoscopic.com>.

Hi Pepe, the link is tokenized for your use. Here's the public link:

http://refcardz.dzone.com/refcardz/git-patterns-and-anti-patterns

Thanks

Carlos



2013/3/27 Jose Barragán <jo...@codeoscopic.com>

> Sorry for missing link: Git Patterns and Anti-Patterns: Scaling from
> Workgroup to Enterprise<
> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
> >
>  -->
>
> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
>
> On Wed, Mar 27, 2013 at 10:41 AM, Jose Barragan <
> jose.barragan@codeoscopic.com> wrote:
>
> > +1 with Carlos
> >
> > check it out this:  Git Patterns and Anti-Patterns: Scaling from
> > Workgroup to Enterprise<
> http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf
> >
> > --
> > *Jose Barragan*
> > *Chief **Software Architect*
> > Codeoscopic Madrid
> > C/. Infanta Mercedes, 92.
> > Planta 5.  505.
> > 28020 Madrid.
> > Tel.: +34 912 94 80 80
> >
> > On Mar 27, 2013, at 10:35 AM, Jose Barragan <
> jose.barragan@codeoscopic.com>
> > wrote:
> >
> > +1 with Carlos
> > <rc178-010d-git-patterns-antipatterns_1.pdf>
> >
> > --
> > *Jose Barragan*
> > *Chief **Software Architect*
> > Codeoscopic Madrid
> > C/. Infanta Mercedes, 92.
> > Planta 5.  505.
> > 28020 Madrid.
> > Tel.: +34 912 94 80 80
> >
> > On Mar 27, 2013, at 10:24 AM, Carlos Rovira <
> carlos.rovira@codeoscopic.com>
> > wrote:
> >
> > Hi Frederic,
> >
> > in our experience working with GIT we saw that was extremely helpful to
> > have visual track of each set of commits that are a single fix,
> > functionality, feature or whatever, since you can always operate and have
> > much control as branches grow and ramifies. In the particular case you
> > point (single commit - flat history) it's a matter of tastes but making
> it
> > flat for this particular case makes you lost visibility as GIT workflow
> > evolve over time. Right now we could make it flat (at this point of
> > simplicity), but I recommend not to do it since in few months we should
> > expect more complex GIT graphs and this kind of loops will help to see
> > others what historically happen.
> >
> > Apache Flex is so huge and modular and over time we should organize in a
> > way that make us possible to plan huge releases with lots of modules,
> > changes and consistence between pieces. We are right now at the very
> > beginning trying to get the basic management and functionality but as
> > people will understand the full potential of the tool and the kind of
> > thinks we can now do, things will complicate. As we discussed in other
> > thread some weeks ago, I suspect that we will end in an
> > "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> > part is that decisions must be consolidated in this list to adopt such
> > model), since it's what I see in other big open source projects where sub
> > teams are organized in repositories and they commit in such repositories
> > while the "lieutenant" assemble the final "module" (this happen in the
> same
> > way all the way to root until reach the "dictator"). As we said, if we
> end
> > in this model, the apache way will be less restricted in repo permissions
> > and more conducted by the list where people will assign the tasks to a
> > single person.
> >
> >
> >
> >
> >
> > 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
> >
> > Hi Carlos,
> >
> > This merge you did make me think I didn't talk about this case on the
> wiki
> > [1], so I updated it, in short, while it is good to start a branch as you
> > did for a new jira ticket and as you may don't know the final number of
> > commits you will have at the end, once it is the time to merge, you know
> > the number of commits you did, if you realize you've got only one, it is
> > better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> > <my_branch>, the reason behind that is that you can avoid the extra merge
> > commit, practically nothing change, except you will have a flat history
> > which is what we want for only one commit and it could be reverse/reset
> the
> > same if needed.
> >
> > Thanks,
> > -Fred
> >
> > [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> > vs+Bad+Git+usage<
> > https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
> >
> > -----Message d'origine----- From: carlosrovira@apache.org
> > Sent: Wednesday, March 27, 2013 3:12 AM
> > To: commits@flex.apache.org
> > Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
> >
> > Merge branch 'FLEX-33349' into develop
> >
> > * FLEX-33349:
> > Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> > refreshing the dataProvider of Combobox.
> >
> >
> > Project:
> > http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
> http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> > Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> > 39fdf7fa <
> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> > Tree:
> > http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
> http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> > Diff:
> > http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
> http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
> >
> > Branch: refs/heads/develop
> > Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> > Parents: 6282657 5ca083e
> > Author: Carlos Rovira <ca...@gmail.com>
> > Authored: Wed Mar 27 03:12:08 2013 +0100
> > Committer: Carlos Rovira <ca...@gmail.com>
> > Committed: Wed Mar 27 03:12:08 2013 +0100
> >
> >
> ------------------------------**------------------------------**----------
> > .../projects/spark/src/spark/**components/List.as    |   23
> > +++++++++++----
> > 1 files changed, 17 insertions(+), 6 deletions(-)
> >
> ------------------------------**------------------------------**----------
> >
> >
> >
> >
> >
> > --
> > Carlos Rovira
> > Director de Tecnología
> > M: +34 607 22 60 05
> > F:  +34 912 94 80 80
> > http://www.codeoscopic.com
> > http://www.directwriter.es
> > http://www.avant2.es
> >
> >
> >
> >
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragán <jo...@codeoscopic.com>.

Sorry for missing link: Git Patterns and Anti-Patterns: Scaling from
Workgroup to Enterprise<http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf>
 -->
http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf

On Wed, Mar 27, 2013 at 10:41 AM, Jose Barragan <
jose.barragan@codeoscopic.com> wrote:

> +1 with Carlos
>
> check it out this:  Git Patterns and Anti-Patterns: Scaling from
> Workgroup to Enterprise<http://refcardz.dzone.com/assets/download/refcard/bf3d79c7ce6019dc5ff28cf76c3f48db/rc178-010d-git-patterns-antipatterns_1.pdf>
> --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
> On Mar 27, 2013, at 10:35 AM, Jose Barragan <jo...@codeoscopic.com>
> wrote:
>
> +1 with Carlos
> <rc178-010d-git-patterns-antipatterns_1.pdf>
>
> --
> *Jose Barragan*
> *Chief **Software Architect*
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92.
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
>
> On Mar 27, 2013, at 10:24 AM, Carlos Rovira <ca...@codeoscopic.com>
> wrote:
>
> Hi Frederic,
>
> in our experience working with GIT we saw that was extremely helpful to
> have visual track of each set of commits that are a single fix,
> functionality, feature or whatever, since you can always operate and have
> much control as branches grow and ramifies. In the particular case you
> point (single commit - flat history) it's a matter of tastes but making it
> flat for this particular case makes you lost visibility as GIT workflow
> evolve over time. Right now we could make it flat (at this point of
> simplicity), but I recommend not to do it since in few months we should
> expect more complex GIT graphs and this kind of loops will help to see
> others what historically happen.
>
> Apache Flex is so huge and modular and over time we should organize in a
> way that make us possible to plan huge releases with lots of modules,
> changes and consistence between pieces. We are right now at the very
> beginning trying to get the basic management and functionality but as
> people will understand the full potential of the tool and the kind of
> thinks we can now do, things will complicate. As we discussed in other
> thread some weeks ago, I suspect that we will end in an
> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
> part is that decisions must be consolidated in this list to adopt such
> model), since it's what I see in other big open source projects where sub
> teams are organized in repositories and they commit in such repositories
> while the "lieutenant" assemble the final "module" (this happen in the same
> way all the way to root until reach the "dictator"). As we said, if we end
> in this model, the apache way will be less restricted in repo permissions
> and more conducted by the list where people will assign the tasks to a
> single person.
>
>
>
>
>
> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>
> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff:
> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
>
>
>

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Jose Barragan <jo...@codeoscopic.com>.

+1 with Carlos

check it out this:  Git Patterns and Anti-Patterns: Scaling from Workgroup to Enterprise
--
Jose Barragan
Chief Software Architect
Codeoscopic Madrid
C/. Infanta Mercedes, 92. 
Planta 5.  505.
28020 Madrid.
Tel.: +34 912 94 80 80

On Mar 27, 2013, at 10:35 AM, Jose Barragan <jo...@codeoscopic.com> wrote:

> +1 with Carlos
> <rc178-010d-git-patterns-antipatterns_1.pdf>
> 
> --
> Jose Barragan
> Chief Software Architect
> Codeoscopic Madrid
> C/. Infanta Mercedes, 92. 
> Planta 5.  505.
> 28020 Madrid.
> Tel.: +34 912 94 80 80
> 
> On Mar 27, 2013, at 10:24 AM, Carlos Rovira <ca...@codeoscopic.com> wrote:
> 
>> Hi Frederic,
>> 
>> in our experience working with GIT we saw that was extremely helpful to
>> have visual track of each set of commits that are a single fix,
>> functionality, feature or whatever, since you can always operate and have
>> much control as branches grow and ramifies. In the particular case you
>> point (single commit - flat history) it's a matter of tastes but making it
>> flat for this particular case makes you lost visibility as GIT workflow
>> evolve over time. Right now we could make it flat (at this point of
>> simplicity), but I recommend not to do it since in few months we should
>> expect more complex GIT graphs and this kind of loops will help to see
>> others what historically happen.
>> 
>> Apache Flex is so huge and modular and over time we should organize in a
>> way that make us possible to plan huge releases with lots of modules,
>> changes and consistence between pieces. We are right now at the very
>> beginning trying to get the basic management and functionality but as
>> people will understand the full potential of the tool and the kind of
>> thinks we can now do, things will complicate. As we discussed in other
>> thread some weeks ago, I suspect that we will end in an
>> "dictator-lieutenant-apache" model (as we talked with Beltran the apache
>> part is that decisions must be consolidated in this list to adopt such
>> model), since it's what I see in other big open source projects where sub
>> teams are organized in repositories and they commit in such repositories
>> while the "lieutenant" assemble the final "module" (this happen in the same
>> way all the way to root until reach the "dictator"). As we said, if we end
>> in this model, the apache way will be less restricted in repo permissions
>> and more conducted by the list where people will assign the tasks to a
>> single person.
>> 
>> 
>> 
>> 
>> 
>> 2013/3/27 Frédéric THOMAS <we...@hotmail.com>
>> 
>>> Hi Carlos,
>>> 
>>> This merge you did make me think I didn't talk about this case on the wiki
>>> [1], so I updated it, in short, while it is good to start a branch as you
>>> did for a new jira ticket and as you may don't know the final number of
>>> commits you will have at the end, once it is the time to merge, you know
>>> the number of commits you did, if you realize you've got only one, it is
>>> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
>>> <my_branch>, the reason behind that is that you can avoid the extra merge
>>> commit, practically nothing change, except you will have a flat history
>>> which is what we want for only one commit and it could be reverse/reset the
>>> same if needed.
>>> 
>>> Thanks,
>>> -Fred
>>> 
>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>> vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>> 
>>> -----Message d'origine----- From: carlosrovira@apache.org
>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>> To: commits@flex.apache.org
>>> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>>> 
>>> Merge branch 'FLEX-33349' into develop
>>> 
>>> * FLEX-33349:
>>> Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
>>> refreshing the dataProvider of Combobox.
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>> Tree: http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>> Diff: http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>> 
>>> Branch: refs/heads/develop
>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>> Parents: 6282657 5ca083e
>>> Author: Carlos Rovira <ca...@gmail.com>
>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>> Committer: Carlos Rovira <ca...@gmail.com>
>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>> 
>>> ------------------------------**------------------------------**----------
>>> .../projects/spark/src/spark/**components/List.as    |   23
>>> +++++++++++----
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>> ------------------------------**------------------------------**----------
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> Director de Tecnología
>> M: +34 607 22 60 05
>> F:  +34 912 94 80 80
>> http://www.codeoscopic.com
>> http://www.directwriter.es
>> http://www.avant2.es
>

Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop

Posted by Carlos Rovira <ca...@codeoscopic.com>.

Hi Frederic,

in our experience working with GIT we saw that was extremely helpful to
have visual track of each set of commits that are a single fix,
functionality, feature or whatever, since you can always operate and have
much control as branches grow and ramifies. In the particular case you
point (single commit - flat history) it's a matter of tastes but making it
flat for this particular case makes you lost visibility as GIT workflow
evolve over time. Right now we could make it flat (at this point of
simplicity), but I recommend not to do it since in few months we should
expect more complex GIT graphs and this kind of loops will help to see
others what historically happen.

Apache Flex is so huge and modular and over time we should organize in a
way that make us possible to plan huge releases with lots of modules,
changes and consistence between pieces. We are right now at the very
beginning trying to get the basic management and functionality but as
people will understand the full potential of the tool and the kind of
thinks we can now do, things will complicate. As we discussed in other
thread some weeks ago, I suspect that we will end in an
"dictator-lieutenant-apache" model (as we talked with Beltran the apache
part is that decisions must be consolidated in this list to adopt such
model), since it's what I see in other big open source projects where sub
teams are organized in repositories and they commit in such repositories
while the "lieutenant" assemble the final "module" (this happen in the same
way all the way to root until reach the "dictator"). As we said, if we end
in this model, the apache way will be less restricted in repo permissions
and more conducted by the list where people will assign the tasks to a
single person.





2013/3/27 Frédéric THOMAS <we...@hotmail.com>

> Hi Carlos,
>
> This merge you did make me think I didn't talk about this case on the wiki
> [1], so I updated it, in short, while it is good to start a branch as you
> did for a new jira ticket and as you may don't know the final number of
> commits you will have at the end, once it is the time to merge, you know
> the number of commits you did, if you realize you've got only one, it is
> better to do a 'git rebase <my_branch>' instead of a 'git merge --no-ff
> <my_branch>, the reason behind that is that you can avoid the extra merge
> commit, practically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine----- From: carlosrovira@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: commits@flex.apache.org
> Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Merge branch 'FLEX-33349' into develop
>
> * FLEX-33349:
>  Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
> refreshing the dataProvider of Combobox.
>
>
> Project: http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<http://git-wip-us.apache.org/repos/asf/flex-sdk/repo>
> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
> 39fdf7fa <http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
> Tree: http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
> Diff: http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>
> Branch: refs/heads/develop
> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
> Parents: 6282657 5ca083e
> Author: Carlos Rovira <ca...@gmail.com>
> Authored: Wed Mar 27 03:12:08 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> Committed: Wed Mar 27 03:12:08 2013 +0100
>
> ------------------------------**------------------------------**----------
> .../projects/spark/src/spark/**components/List.as    |   23
> +++++++++++----
> 1 files changed, 17 insertions(+), 6 deletions(-)
> ------------------------------**------------------------------**----------
>
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es