You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/08/15 00:24:49 UTC
[MENTORS] Current Branching Strategy Vote Results
Hi Mentors,
We’re just past the halfway mark (and some folks who voted in the poll have not yet voted) but if I culled the votes properly (see below), there is a significant difference of opinion between the PPMC and the community. Maybe it is too early to be asking, but I was wondering what your thoughts are on resolving such a difference.
---Binding Votes---
Three Tier Model on SVN and then on Git: 3
Alex Harui
Jeffry Houser
Igor Costa
Classic Model on SVN: 6
Carol Frampton
Mike Labriola
Bertrand Delacretaz
Greg Reddin
Justin Mclean
Dave Fisher
Git Branching Model on Git now: 2
Omprakash Muppirala (Om)
Omar Gonzalez
---Non-Binding Votes--
Classic Model on SVN: 2
superabe
Erik de Bruin
Git Branching Model on Git now: 9
Cyrill Zadra
Dasa Paddock
Javier Vacas
Jose Barrigan
Judah Frangipane (Jude)
Peter Ent
Jeff Conrad
Carlos Rovira
Ben Dalton
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Omar Gonzalez <om...@gmail.com>.
>
>
>
> But this drove home for me the need for a "develop" branch in options 1-3
> or
> 7-9. Yes, this would be caught if we had mustella running in CI, but there
> are other things like this that might get past mustella.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
And with having both GBM with 7-9 and Mustella on CI and this project would
be kicking some ass.
-omar
Re: Mustella validator test issue
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 10:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> OK, I will watch for a commit from you.
> Committed.
Ahh, so much better. Only one failure instead of 100+. Thanks.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Mustella validator test issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> OK, I will watch for a commit from you.
Committed.
> To me JIRA is a "to-do" list tracker with some overhead.
Agreed no need to add every little issue.
\
Justin
Re: Mustella validator test issue
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 10:22 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> 1) rename the validator.properties bundle in apache.swc to something else
>> and fix up references
> While not ideal first option probably better than second option. I'll go
> ahead, test and check in. However I'm unable to run the Mustella test so if
> you could check that it fixes the issue once checked in I'd appreciate it.
OK, I will watch for a commit from you.
>
>> I don't think this needs a JIRA issue. But it does raise an good question:
>> are we even supposed to create JIRA issues for problems found in commits?
> Why wouldn't you? I don't think JIRA use needs to be restricted to the last
> released version, otherwise something could be missed and sneak into the next
> build.
>
Oh, for sure, JIRA can be for current work.
To me JIRA is a "to-do" list tracker with some overhead. IMO, if you check
in something and misspelled a word in a comment, I should just tell you or
just fix it for you. No need to create a JIRA for that because we're on it
and taking care of it right now. The longer it will take before it gets
resolved, the better it is to use JIRA. So I see it as a judgment call and
wouldn't load down JIRA for this because you and I will hopefully just get
it done in short order.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Mustella validator test issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 1) rename the validator.properties bundle in apache.swc to something else
> and fix up references
While not ideal first option probably better than second option. I'll go ahead, test and check in. However I'm unable to run the Mustella test so if you could check that it fixes the issue once checked in I'd appreciate it.
> I don't think this needs a JIRA issue. But it does raise an good question:
> are we even supposed to create JIRA issues for problems found in commits?
Why wouldn't you? I don't think JIRA use needs to be restricted to the last released version, otherwise something could be missed and sneak into the next build.
Thanks,
Justin
Re: Mustella validator test issue
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 6:29 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi Alex,
>
> I need more information than the brief sentence you gave describing the issue
> as I am not as familiar with Mustella as you are.
>
> Please raise a JIRA issue with the exact steps to reproduce and error message
> and I'll try and fix.
>
> I really don't think there is any need to revert code that was checked in
> before Mustella was donated especially when it's an issue with a test. Doing
> so it may break the SDK for anyone that happen to be using that feature.
>
> Thanks,
> Justin
Hi Justin,
As I said in the last post, it isn't an issue with the test. There is a
limitation in the linker that if two swcs have the same resource bundle
name, one will win and the other will lose. By adding an apache.swc with a
validator.properties bundle now all old MX and Spark validator.properties
bundles are not being linked in and tests are breaking.
If you run the mustella spark/validator/CurrencyValidator tests before your
commit they will pass, with your commit they will not. If we'd had mustella
and CI before your commit it would have caught you and you wouldn't have
committed.
I don't want to revert either, so let's choose one of the other two options:
1) rename the validator.properties bundle in apache.swc to something else
and fix up references
2) move the resources from apache.swc bundles to the framework.swc bundles.
The first option requires making up some less obvious name for a bundle of
validator resources. The second option needlessly fattens every app with
resource strings that may not be used and separates bundle management from
the swc. Which is not very modular, but I noticed we already cheated that
way for spark.swc.
I don't think this needs a JIRA issue. But it does raise an good question:
are we even supposed to create JIRA issues for problems found in commits?
Anyway, pick an option and if you are backlogged and can't get to it today
let me know and I will do it tomorrow so I can see what other validator
tests are breaking for other reasons.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Mustella validator test issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi Alex,
I need more information than the brief sentence you gave describing the issue as I am not as familiar with Mustella as you are.
Please raise a JIRA issue with the exact steps to reproduce and error message and I'll try and fix.
I really don't think there is any need to revert code that was checked in before Mustella was donated especially when it's an issue with a test. Doing so it may break the SDK for anyone that happen to be using that feature.
Thanks,
Justin
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 3:30 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> After digging for a while, it turns out that the apache.swc that
>> Justin added to trunk broke the validator tests because he added a validator
>> resource bundle there and the linker uses the first bundle found and does
>> not aggregate them so all of the other spark validator resources are missing
>> causing the tests to fail.
>
> From memory the existing validator classes don't need or use any of the new
> resources and the new validator class were placed in a new namespace and swf
> so I wouldn't of expected them to cause any issues along these line. Without
> more info on the error I'm not 100% sure what the problem is. I can't
> currently run Mustella in my development environment because of the issues it
> has with spaces in it's path.
The explanation is above. By adding your own validator.properties to a swc
the linker will not find the framework.swc's validator.properties and tests
relying on those resources fail.
>
>> The quick answer is to revert that change or move the resources to the
>> central bundle in framework.swc
> The quick answer would be to fix the test would it not? Tell me what the exact
> issue is and I'll have a go a fixing it. Probably better if the resources were
> kept separate as if they are not we need localizations for every supported
> language that framework.swc needs.
The tests are correct. The addition of the apache.swc with its
validator.properties broke the tests.
Long term, the linker should probably try to aggregate bundles with the same
name. Short term, we either use a different bundle name in apache.swc,
consolidate its resources into framework.swc's validator.properties, or
revert.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Mustella with Spaces
Posted by Peter Ent <pe...@adobe.com>.
Thanks, Justin. This certainly clarifies the issue. I'll put it on my
to-do list and get on it.
--peter
On 8/16/12 10:20 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I'd like to help resolve the issue you are having with spaces in paths.
>
>Thanks much appreciated.
>
>> Which OS are you using and can you identify a path that's causing the
>> problem (e.g., your home directory, the Flex SDK directory). If you are
>> using Windows, which Unix shell are you using?
>
>I'm using OSX but the issue is many fold and not OSX specific.
>
>First off minor issue with the build file - easily enough fixed.
>
>- <sysproperty key="mxmlc.args" value="${mxmlc.args}
>-source-path=${mustella.dir}/Assets "/>
>+ <sysproperty key="mxmlc.args" value="${mxmlc.args}" />
>+ <sysproperty key="source-path" value="${mustella.dir}/Assets"/>
>
>Next issue I think is with how "-source-path" is added to arguments in
>CompileMustellaSwfs.java, it's missing quotes this needs to be changed in
>a dozen or so places. Might be other ways of solving this.
>
>eg line 960 in CompileMustellaSwfs.java change
>args+=" -source-path=" + pieces[i];
>to
>args+=" -source-path=\"" + pieces[i] + "\"";
>
>Possibly similar changes need to be made in CompilUtils.java and
>MustellaDirs.java.
>
>Next after the argument string is build up it's split on spaces via this
>(line 1007 in CompileMustellaSwfs.java)
>
> defaultArgs=StringUtils.StringToArray(args);
>
>Not so easy to fix. I've played about changing it to something like this:
>
> Matcher match =
>Pattern.compile("([^\\S]*\"[^\"]*\")|(\\S+)").matcher(args);
> ArrayList argList = new ArrayList();
>
> while (match.find()) {
> if (match.group(1) == null) {
> argList.add(match.group(2));
> } else {
> argList.add(match.group(1));
> }
> }
>
>Not quite right/working yet, but you get the idea.
>
>But the real issue with line 1007 is as far as I can see there's no need
>to build up a string only to convert it to an array when you could build
>the array in the first place. That may be the way to fix the issue rather
>than playing about with regular expressions.
>
>Thanks,
>Justin
>
Re: Mustella with Spaces
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I'd like to help resolve the issue you are having with spaces in paths.
Thanks much appreciated.
> Which OS are you using and can you identify a path that's causing the
> problem (e.g., your home directory, the Flex SDK directory). If you are
> using Windows, which Unix shell are you using?
I'm using OSX but the issue is many fold and not OSX specific.
First off minor issue with the build file - easily enough fixed.
- <sysproperty key="mxmlc.args" value="${mxmlc.args} -source-path=${mustella.dir}/Assets "/>
+ <sysproperty key="mxmlc.args" value="${mxmlc.args}" />
+ <sysproperty key="source-path" value="${mustella.dir}/Assets"/>
Next issue I think is with how "-source-path" is added to arguments in CompileMustellaSwfs.java, it's missing quotes this needs to be changed in a dozen or so places. Might be other ways of solving this.
eg line 960 in CompileMustellaSwfs.java change
args+=" -source-path=" + pieces[i];
to
args+=" -source-path=\"" + pieces[i] + "\"";
Possibly similar changes need to be made in CompilUtils.java and MustellaDirs.java.
Next after the argument string is build up it's split on spaces via this (line 1007 in CompileMustellaSwfs.java)
defaultArgs=StringUtils.StringToArray(args);
Not so easy to fix. I've played about changing it to something like this:
Matcher match = Pattern.compile("([^\\S]*\"[^\"]*\")|(\\S+)").matcher(args);
ArrayList argList = new ArrayList();
while (match.find()) {
if (match.group(1) == null) {
argList.add(match.group(2));
} else {
argList.add(match.group(1));
}
}
Not quite right/working yet, but you get the idea.
But the real issue with line 1007 is as far as I can see there's no need to build up a string only to convert it to an array when you could build the array in the first place. That may be the way to fix the issue rather than playing about with regular expressions.
Thanks,
Justin
Mustella with Spaces
Posted by Peter Ent <pe...@adobe.com>.
Justin,
I'd like to help resolve the issue you are having with spaces in paths.
Which OS are you using and can you identify a path that's causing the
problem (e.g., your home directory, the Flex SDK directory). If you are
using Windows, which Unix shell are you using?
Thanks,
Peter Ent
Flex SDK Team
Adobe Systems
On 8/15/12 6:30 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> After digging for a while, it turns out that the apache.swc that
>> Justin added to trunk broke the validator tests because he added a
>>validator
>> resource bundle there and the linker uses the first bundle found and
>>does
>> not aggregate them so all of the other spark validator resources are
>>missing
>> causing the tests to fail.
>
>From memory the existing validator classes don't need or use any of the
>new resources and the new validator class were placed in a new namespace
>and swf so I wouldn't of expected them to cause any issues along these
>line. Without more info on the error I'm not 100% sure what the problem
>is. I can't currently run Mustella in my development environment because
>of the issues it has with spaces in it's path.
>
>> The quick answer is to revert that change or move the resources to the
>> central bundle in framework.swc
>The quick answer would be to fix the test would it not? Tell me what the
>exact issue is and I'll have a go a fixing it. Probably better if the
>resources were kept separate as if they are not we need localizations for
>every supported language that framework.swc needs.
>
>Thanks,
>Justin
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> After digging for a while, it turns out that the apache.swc that
> Justin added to trunk broke the validator tests because he added a validator
> resource bundle there and the linker uses the first bundle found and does
> not aggregate them so all of the other spark validator resources are missing
> causing the tests to fail.
From memory the existing validator classes don't need or use any of the new resources and the new validator class were placed in a new namespace and swf so I wouldn't of expected them to cause any issues along these line. Without more info on the error I'm not 100% sure what the problem is. I can't currently run Mustella in my development environment because of the issues it has with spaces in it's path.
> The quick answer is to revert that change or move the resources to the
> central bundle in framework.swc
The quick answer would be to fix the test would it not? Tell me what the exact issue is and I'll have a go a fixing it. Probably better if the resources were kept separate as if they are not we need localizations for every supported language that framework.swc needs.
Thanks,
Justin
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Alex Harui <ah...@adobe.com>.
Life is funny. Fate just handed me an example of the idiosyncracies of our
code base. I took on trying to get the Mustella spark validator tests to
run. After digging for a while, it turns out that the apache.swc that
Justin added to trunk broke the validator tests because he added a validator
resource bundle there and the linker uses the first bundle found and does
not aggregate them so all of the other spark validator resources are missing
causing the tests to fail.
The quick answer is to revert that change or move the resources to the
central bundle in framework.swc which is not very modular, but probably what
we'll have to do. I'll wait a bit for Justin to give his opinion and make a
change, then move the resources myself if he doesn't.
But this drove home for me the need for a "develop" branch in options 1-3 or
7-9. Yes, this would be caught if we had mustella running in CI, but there
are other things like this that might get past mustella.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [MENTORS] Current Branching Strategy Vote Results
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Anything that makes it even a little harder for people to be involved or contribute should be removed. Working with Git for a while I don't see an equal for open development.
>+1 binding
Jon,
You have a short while to add that to the Vote thread :)
Mike
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Jonathan Campos <jo...@gmail.com>.
On Tue, Aug 14, 2012 at 5:24 PM, Alex Harui <ah...@adobe.com> wrote:
> Git Branching Model on Git now: 2
Anything that makes it even a little harder for people to be involved or
contribute should be removed. Working with Git for a while I don't see an
equal for open development.
+1 binding
--
Jonathan Campos
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by jude <fl...@gmail.com>.
On Wed, Aug 15, 2012 at 4:47 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi Carlos,
>
> On Wed, Aug 15, 2012 at 11:01 AM, Carlos Rovira
> <ca...@codeoscopic.com> wrote:
> > ...the problem is not about tooling. Is about the things we plan to do.
> The
> > revision and transformation of the core at flex...
>
> I guess that's where the disconnect is, I hear you and others saying
> "we plan to do big things" but I see just small things (besides code
> donations) happen at [1].
You bring up a very good point. And this needs to be made clear to
everyone. And that is, there are many of us waiting until the core
foundation of this project is laid before jumping in. That is, the test
suite and other donations that we have been waiting for from Adobe and the
workflow model is setup.
I'm not going to go in and modify the framework if I can't then test that
my changes don't break things. I'm not going to spend a lot of time trying
to setup a development environment until all the pieces are in place to do
so. Until recently those pieces weren't in place.
I'm also not going to want to help if the process and workflow is a
nightmare. Think about this, the Flex SDK has been an open source project
for a few years now. Because of the nature of the business we're in we have
slices of time that we can commit (we meaning me). We need to be have a
model and ecosystem that supports where we are able to make drive by
commits.
... and what Omar just said about community and collaboration on GitHub.
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Omar Gonzalez <om...@gmail.com>.
On Wednesday, August 15, 2012, Bertrand Delacretaz wrote:
> Hi Carlos,
>
> On Wed, Aug 15, 2012 at 11:01 AM, Carlos Rovira
> <carlos.rovira@codeoscopic.com <javascript:;>> wrote:
> > ...the problem is not about tooling. Is about the things we plan to do.
> The
> > revision and transformation of the core at flex...
>
> I guess that's where the disconnect is, I hear you and others saying
> "we plan to do big things" but I see just small things (besides code
> donations) happen at [1]. If you or others can show concrete examples
> (i.e. code) of those big things that are impossible to do with svn
> that might help change your mentors' opinions. And in the meantime,
> there's probably lots of small to medium things to do to improve Flex
> anyway.
>
> > ...If there's a development
> > model based on SVN chaos, nobody will spend an hour to make it happen...
>
> Nobody said svn chaos...there are some serious projects like Hadoop,
> httpd, Lucene, Solr for example which have *tons* more activity than
> Flex currently has, and they're doing just fine with svn.
>
> -Bertrand
Jut because those projects are running SVN does not equate to their
projects running _as efficiently as they possibly could be_.
Also, you keep posting links to SVN stats. This project was in a prolonged
wait period because we were/are waiting for code donations (Mustella, can't
make big changed without tests) and JIRA. It's hardly fair to compare our
activity to projects that have been running forever. Did they wait 8 months
for vital pieces of the project to make it thru legal review? I'm betting
thy didn't.
-omar
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 15, 2012 at 12:03 PM, Carlos Rovira
<ca...@codeoscopic.com> wrote:
> ...In our case we have a core piece called UIComponent composed over 14-15k
> lines of code that are "flex" itself.
>
> If we plan to refactor and rethink that core piece we will do over several
> weeks until it was done. People doing it can't made in whiteboards and it's
> not a one-man-task.
>
> This kind of task need to be done in team and with a SCM prepared for that....
I don't know the details of that issue, so I might be off-base but in
general here's how I would tackle such a job:
1. Fork/branch the code and create a proof of concept prototype, to
see more clearly what needs to change. Maybe several prototypes if
people have different ideas. Make sure to concentrate on the core
problem.
2. Review the differences between the prototype and trunk to see the impact
3. Discuss the best strategy for implementing the actual change, based
on the proof of concept
4. Make sure the changed areas are covered by automated tests
5. Implement the changes, over a relatively short period of time as
the proof of concept has shown how to do that, and hopefully its code
can partially be reused.
In this scenario 5. is where the bulk of the merging/refactoring
happens in trunk - if it has big impact it might need some
coordination to make sure enough manpower is available to make it
happen with minimal disruption.
I don't think using Git or svn makes much of a difference in such a
scenario - 5. is going to be somewhat painful anyway.
-Bertrand
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 8/15/2012 6:03 AM, Carlos Rovira wrote:
>
> If we plan to refactor and rethink that core piece we will do over several
> weeks until it was done. People doing it can't made in whiteboards and it's
> not a one-man-task.
I don't believe either of these is true.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Carlos Rovira <ca...@codeoscopic.com>.
And maybe any one those you mention need to tweak some core part that is
used along the software like us?
In our case we have a core piece called UIComponent composed over 14-15k
lines of code that are "flex" itself.
If we plan to refactor and rethink that core piece we will do over several
weeks until it was done. People doing it can't made in whiteboards and it's
not a one-man-task.
This kind of task need to be done in team and with a SCM prepared for that.
If you don't set the SCM before start, no body will go to that task.
The problem here is that we are thinking on it us "just a tool", and it's
not. It's a model development for people that has many things to do in a
day a can't invest the time it will be if we do with ancestral tooling and
development models.
As I said before, it's not a matter of "how big" our project is (or the
others) is about the task we want to accomplish here.
If we plan only to make additive task, SVN will be sufficient for me, but I
think that is not the plan, isn't it?
2012/8/15 Bertrand Delacretaz <bd...@apache.org>
> Hi Carlos,
>
> On Wed, Aug 15, 2012 at 11:01 AM, Carlos Rovira
> <ca...@codeoscopic.com> wrote:
> > ...the problem is not about tooling. Is about the things we plan to do.
> The
> > revision and transformation of the core at flex...
>
> I guess that's where the disconnect is, I hear you and others saying
> "we plan to do big things" but I see just small things (besides code
> donations) happen at [1]. If you or others can show concrete examples
> (i.e. code) of those big things that are impossible to do with svn
> that might help change your mentors' opinions. And in the meantime,
> there's probably lots of small to medium things to do to improve Flex
> anyway.
>
> > ...If there's a development
> > model based on SVN chaos, nobody will spend an hour to make it happen...
>
> Nobody said svn chaos...there are some serious projects like Hadoop,
> httpd, Lucene, Solr for example which have *tons* more activity than
> Flex currently has, and they're doing just fine with svn.
>
> -Bertrand
>
> [1]
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fflex
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carlos,
On Wed, Aug 15, 2012 at 11:01 AM, Carlos Rovira
<ca...@codeoscopic.com> wrote:
> ...the problem is not about tooling. Is about the things we plan to do. The
> revision and transformation of the core at flex...
I guess that's where the disconnect is, I hear you and others saying
"we plan to do big things" but I see just small things (besides code
donations) happen at [1]. If you or others can show concrete examples
(i.e. code) of those big things that are impossible to do with svn
that might help change your mentors' opinions. And in the meantime,
there's probably lots of small to medium things to do to improve Flex
anyway.
> ...If there's a development
> model based on SVN chaos, nobody will spend an hour to make it happen...
Nobody said svn chaos...there are some serious projects like Hadoop,
httpd, Lucene, Solr for example which have *tons* more activity than
Flex currently has, and they're doing just fine with svn.
-Bertrand
[1] http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fflex
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Bertrand,
the problem is not about tooling. Is about the things we plan to do. The
revision and transformation of the core at flex. If there's a development
model based on SVN chaos, nobody will spend an hour to make it happen.
This my unweight opinion as a community member.
2012/8/15 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> On Wed, Aug 15, 2012 at 12:24 AM, Alex Harui <ah...@adobe.com> wrote:
> > ...We’re just past the halfway mark (and some folks who voted in the
> poll have not yet voted)
> > but if I culled the votes properly (see below), there is a significant
> difference of opinion
> > between the PPMC and the community...
>
> This is about which tools the committers use (and might have to
> partially support in case of Git, for now) so I wouldn't give much
> weight to the community's opinion in this particular case. Those who
> do the work decide IMO.
>
> From the community point of view, one big advantage of github IMO is
> that it makes "drive-by contributions" easier, as you don't need to
> subscribe to anything to create a pull request - but it's totally
> possible for Flex committers to commit the occasional pull requests
> that come in against the existing mirrors listed at
> http://git.apache.org/ - and if/when those become too frequent, that
> would be the time to revisit the tooling.
>
> -Bertrand
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
RE: [MENTORS] Current Branching Strategy Vote Results
Posted by Jeffrey Barrus <JB...@SolutionStream.com>.
Just to add another voice to the git and github community experience - the pull system makes it so easy to contribute. I can fork the repo, make the changes and submit a pull request. A committer can review the pull request, make comments (even in the code) and I can easily make the changes and have the pull request reviewed again. If there is a significant branch that needs to be made, it is really easy for many people to work on that branch together.
I am much more likely to contribute to an open source project if it is on github. For me, there is just something fun and compelling about the github experience. The number of projects and contributors on github is a testament to that.
CouchDB appears to be using a two way mirror with Github. Can we get someone from CouchDB to comment on this work flow?
-----Original Message-----
From: Ben Dalton [mailto:bendalton@gmail.com]
Sent: Wednesday, August 15, 2012 8:07 AM
To: flex-dev@incubator.apache.org
Subject: Re: [MENTORS] Current Branching Strategy Vote Results
I agree with Omar 100%.
Git is a bit better of a SCM, but the flexibility the use of GitHub affords really lends itself to a more engaged community.
If we want an engaged community, and the challenges we face with Apache's non-support of Git aren't too severe, Git is the only good choice for future growth.
All that being said, there's still a ton of work to do before we can have an extremely active community of contributors. Until we have a test suite that runs in minutes (and not hours) with CI, it's going to be labor and time intensive to incorporate contributions.
So if the mentors FIRMLY believe that it is a better decision to stick with SVN in the near term, then I support that. As long as we realize that it will be a limiting factor for community contributions and we should plan on moving to Git once we are fully prepared to handle changes from the community. We certainly don't want to end up in the same situation as Adobe in the Flex 2 days and become overwhelmed with patches having limited/no capacity to handle them.
Just my 2cents..
On Wednesday, August 15, 2012 at 9:46 AM, Omar Gonzalez wrote:
> On Wednesday, August 15, 2012, Bertrand Delacretaz wrote:
>
> > Hi,
> >
> > On Wed, Aug 15, 2012 at 12:24 AM, Alex Harui <aharui@adobe.com (mailto:aharui@adobe.com)<javascript:;>>
> > wrote:
> > > ...We’re just past the halfway mark (and some folks who voted in the
> >
> > poll have not yet voted)
> > > but if I culled the votes properly (see below), there is a significant
> >
> > difference of opinion
> > > between the PPMC and the community...
> >
> >
> > This is about which tools the committers use (and might have to
> > partially support in case of Git, for now) so I wouldn't give much
> > weight to the community's opinion in this particular case. Those who
> > do the work decide IMO.
> >
>
>
>
> It's not only the pull requests. It's the easy forking, the commenting on
> commits (directly inline with code) enabling much easier to handle
> patch/code reviews.
>
> It's all about how Git/GitHub promotes community and collaboration. It
> promotes it much better and handles it much smoother via pull requests and
> code reviews than submitting patches thru JIRA and having back and forth
> discussions via email which are hard to keep track of when u can comment
> directly on code in GitHub.
>
> -omar
>
>
>
>
> That just seems pretty messed up to not consider the community. Git enables
> a lot more collaboration, especially when used with GitHub. This is largely
> why so many developers have moved to GitHub. To dismiss this as "This is
> about which tools the committers use" is a mistake. As this tool is also
> how we interface with contributions from the community.
>
>
> > From the community point of view, one big advantage of github IMO is
> > that it makes "drive-by contributions" easier, as you don't need to
> > subscribe to anything to create a pull request - but it's totally
> > possible for Flex committers to commit the occasional pull requests
> > that come in against the existing mirrors listed at
> > http://git.apache.org/ - and if/when those become too frequent, that
> > would be the time to revisit the tooling.
> >
> > -Bertrand
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Ben Dalton <be...@gmail.com>.
I agree with Omar 100%.
Git is a bit better of a SCM, but the flexibility the use of GitHub affords really lends itself to a more engaged community.
If we want an engaged community, and the challenges we face with Apache's non-support of Git aren't too severe, Git is the only good choice for future growth.
All that being said, there's still a ton of work to do before we can have an extremely active community of contributors. Until we have a test suite that runs in minutes (and not hours) with CI, it's going to be labor and time intensive to incorporate contributions.
So if the mentors FIRMLY believe that it is a better decision to stick with SVN in the near term, then I support that. As long as we realize that it will be a limiting factor for community contributions and we should plan on moving to Git once we are fully prepared to handle changes from the community. We certainly don't want to end up in the same situation as Adobe in the Flex 2 days and become overwhelmed with patches having limited/no capacity to handle them.
Just my 2cents..
On Wednesday, August 15, 2012 at 9:46 AM, Omar Gonzalez wrote:
> On Wednesday, August 15, 2012, Bertrand Delacretaz wrote:
>
> > Hi,
> >
> > On Wed, Aug 15, 2012 at 12:24 AM, Alex Harui <aharui@adobe.com (mailto:aharui@adobe.com)<javascript:;>>
> > wrote:
> > > ...We’re just past the halfway mark (and some folks who voted in the
> >
> > poll have not yet voted)
> > > but if I culled the votes properly (see below), there is a significant
> >
> > difference of opinion
> > > between the PPMC and the community...
> >
> >
> > This is about which tools the committers use (and might have to
> > partially support in case of Git, for now) so I wouldn't give much
> > weight to the community's opinion in this particular case. Those who
> > do the work decide IMO.
> >
>
>
>
> It's not only the pull requests. It's the easy forking, the commenting on
> commits (directly inline with code) enabling much easier to handle
> patch/code reviews.
>
> It's all about how Git/GitHub promotes community and collaboration. It
> promotes it much better and handles it much smoother via pull requests and
> code reviews than submitting patches thru JIRA and having back and forth
> discussions via email which are hard to keep track of when u can comment
> directly on code in GitHub.
>
> -omar
>
>
>
>
> That just seems pretty messed up to not consider the community. Git enables
> a lot more collaboration, especially when used with GitHub. This is largely
> why so many developers have moved to GitHub. To dismiss this as "This is
> about which tools the committers use" is a mistake. As this tool is also
> how we interface with contributions from the community.
>
>
> > From the community point of view, one big advantage of github IMO is
> > that it makes "drive-by contributions" easier, as you don't need to
> > subscribe to anything to create a pull request - but it's totally
> > possible for Flex committers to commit the occasional pull requests
> > that come in against the existing mirrors listed at
> > http://git.apache.org/ - and if/when those become too frequent, that
> > would be the time to revisit the tooling.
> >
> > -Bertrand
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Omar Gonzalez <om...@gmail.com>.
On Wednesday, August 15, 2012, Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Aug 15, 2012 at 12:24 AM, Alex Harui <aharui@adobe.com<javascript:;>>
> wrote:
> > ...We’re just past the halfway mark (and some folks who voted in the
> poll have not yet voted)
> > but if I culled the votes properly (see below), there is a significant
> difference of opinion
> > between the PPMC and the community...
>
> This is about which tools the committers use (and might have to
> partially support in case of Git, for now) so I wouldn't give much
> weight to the community's opinion in this particular case. Those who
> do the work decide IMO.
It's not only the pull requests. It's the easy forking, the commenting on
commits (directly inline with code) enabling much easier to handle
patch/code reviews.
It's all about how Git/GitHub promotes community and collaboration. It
promotes it much better and handles it much smoother via pull requests and
code reviews than submitting patches thru JIRA and having back and forth
discussions via email which are hard to keep track of when u can comment
directly on code in GitHub.
-omar
That just seems pretty messed up to not consider the community. Git enables
a lot more collaboration, especially when used with GitHub. This is largely
why so many developers have moved to GitHub. To dismiss this as "This is
about which tools the committers use" is a mistake. As this tool is also
how we interface with contributions from the community.
> From the community point of view, one big advantage of github IMO is
> that it makes "drive-by contributions" easier, as you don't need to
> subscribe to anything to create a pull request - but it's totally
> possible for Flex committers to commit the occasional pull requests
> that come in against the existing mirrors listed at
> http://git.apache.org/ - and if/when those become too frequent, that
> would be the time to revisit the tooling.
>
> -Bertrand
>
RE: [MENTORS] Current Branching Strategy Vote Results
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Given what I know we want to do short term, I think we can live with GBM on SVN for now. The next release isn't going to contain any UIComponent refactoring, we've got lots of mustella tests to fix and some >new components to integrate. I think SVN can handle that.
I agree with you and hence my original vote. The change is more about the idea that *anything* that gives us a better chance of more people contributing in any way right now is good for us and I believe git will. My original (and somewhat ongoing) concern is that I don't want to take another detour. However, with several people volunteering to work on this, I think it can go forward while work continues... So, I will hope someone else votes.
Mike
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Anyone interested porting this:
https://github.com/nvie/gitflow/
To use SVN?
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 16, 2012 at 9:38 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...My guess (and hopefully I'm wrong but infra have a lot on their plate at the moment) that
> it will take some time to get GIt up and running for the project so it's likely we have
> to live with this for a while....
That's probable, http://s.apache.org/infra_git shows two projects
waiting since beginning of this month, and between INFRA-4137 and the
still experimental label of Git support, such requests are probably
handled with low priority.
-Bertrand
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Slightly off topic (no about Git) but may be of interest to people.
Mike Mason & Martin Fowler on feature branching
http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Justin
"So each new change would need to work in a feature branch and then merged
into develop? How/when is it decided to merge into develop? Can I do that
or do I need to involve other people? For "simple" changes do we just
commit straight in develop?"
I responded most of this in the response to Joao.
Regarding how to integrate GBM in SVN Pepe Barragan or I will post soon a
solution that could work.
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Please read the following article that is the the core of the development
> model selected:
> nvie.com/posts/a-successful-git-branching-model
I have but I'm unsure of exactly how to apply it in SVN. Hence my questions.
> the branch "develop" should be the place to work and the one of wich we
> could extract nightly builds because it should be stable over time (each
> feature merged with develop should be stable making develop stable as well).
So each new change would need to work in a feature branch and then merged into develop? How/when is it decided to merge into develop? Can I do that or do I need to involve other people? For "simple" changes do we just commit straight in develop?
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Yes, I mean "sharing" the local branch in the apache git, so everybody
could checkout and support the effort.
But take into account that it is not possible yet...
2012/8/16 João Fernandes <jo...@gmail.com>
> On 16 August 2012 12:45, Carlos Rovira <carlos.rovira@codeoscopic.com
> >wrote:
>
> > Hi Joao,
> >
> > as you say something so huge as UIComponent refactor should not be done
> in
> > "develop". Nothing that will take relative time should done in develop.
> > Only minor changes. "develop" always should be stable.
> >
> > The guy starting this effort should branch in a feature branch. For
> example
> > "uicomponent-refactor", and start working there. Only when the branch is
> > stable is when is merged back to develop.
> >
> > Since this feature is so huge and long term, normaly the guy starting the
> > effort based on some plan, should publish the branch so other people
> could
> > help him in such huge effort.
> >
> >
> By publishing do you mean creating that branch under the Apache git
> repository right?
> --
>
> João Fernandes
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Omar Gonzalez <om...@gmail.com>.
On Thursday, August 16, 2012, Justin Mclean wrote:
> Hi,
>
> > By publishing do you mean creating that branch under the Apache git
> > repository right?
>
> Currently (and likely to be the case for a few months) we would have to
> create a SVN branch which would be mirrored in the git mirror.
> https://github.com/apache/flex/branches
>
> Thanks,
> Justin
I can spend time today to work out the commands etc in SVN to pull off GBM.
I use GBM on my projects, and know SVN good enough to make the translation,
I also have a light day today.
-omar
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> By publishing do you mean creating that branch under the Apache git
> repository right?
Currently (and likely to be the case for a few months) we would have to create a SVN branch which would be mirrored in the git mirror.
https://github.com/apache/flex/branches
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by João Fernandes <jo...@gmail.com>.
On 16 August 2012 12:45, Carlos Rovira <ca...@codeoscopic.com>wrote:
> Hi Joao,
>
> as you say something so huge as UIComponent refactor should not be done in
> "develop". Nothing that will take relative time should done in develop.
> Only minor changes. "develop" always should be stable.
>
> The guy starting this effort should branch in a feature branch. For example
> "uicomponent-refactor", and start working there. Only when the branch is
> stable is when is merged back to develop.
>
> Since this feature is so huge and long term, normaly the guy starting the
> effort based on some plan, should publish the branch so other people could
> help him in such huge effort.
>
>
By publishing do you mean creating that branch under the Apache git
repository right?
--
João Fernandes
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Joao,
as you say something so huge as UIComponent refactor should not be done in
"develop". Nothing that will take relative time should done in develop.
Only minor changes. "develop" always should be stable.
The guy starting this effort should branch in a feature branch. For example
"uicomponent-refactor", and start working there. Only when the branch is
stable is when is merged back to develop.
Since this feature is so huge and long term, normaly the guy starting the
effort based on some plan, should publish the branch so other people could
help him in such huge effort.
2012/8/16 João Fernandes <jo...@gmail.com>
> I understand that we'll have a git repository clone from develop and master
> locally but for big changes that some are planning, shouldn't a dedicated
> branch be created (from develop) so pull requests could be made to that
> specific branch instead of develop?
> I'm asking this because I don't see a work like "UIComponent refactoring"
> being done directly under develop.
> Am I wrong?
>
> João Fernandes
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by João Fernandes <jo...@gmail.com>.
I understand that we'll have a git repository clone from develop and master
locally but for big changes that some are planning, shouldn't a dedicated
branch be created (from develop) so pull requests could be made to that
specific branch instead of develop?
I'm asking this because I don't see a work like "UIComponent refactoring"
being done directly under develop.
Am I wrong?
João Fernandes
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Justin,
So any changes I wanted to commit I'll need to commit to develop branch
> once it exists? How exactly is it decided that the branch should then be
> merged with trunk?
>
Please read the following article that is the the core of the development
model selected:
nvie.com/posts/a-successful-git-branching-model
the branch "develop" should be the place to work and the one of wich we
could extract nightly builds because it should be stable over time (each
feature merged with develop should be stable making develop stable as well).
"trunk" will become "master" and this should bring us the releases (passing
for a release branch to prepare the release).
So the main work should take place in develop and master should bring work
from develop when a release will scheduled (passing for a release branch
first)
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 3:35 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I would plan my changes so as not to break "develop" so I can just check it
>> in and share it even though it isn't 100% complete. If I can't do that I
>> would create a branch and folks can get at that branch from SVN if they want
>> to see what you are doing.
>
> The issue with is is that you need to know in advance if your changes will
> break the build in order to know to if you need to create a branch or not
> branch. I guess there are ways to do this ie work in develop, break it, create
> a patch, revert to develop, create new branch, reapply the patch and then
> commit new branch but probably needs to be documented.
>
> Thanks,
> Justin
>
I guess you could do that, usually I know whether I'm working on something
big that needs a branch or not. For normal bug fixes and small additions my
workflow would be to run mustella before checking in. That's why I'm trying
to get all mustella tests passing.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would plan my changes so as not to break "develop" so I can just check it
> in and share it even though it isn't 100% complete. If I can't do that I
> would create a branch and folks can get at that branch from SVN if they want
> to see what you are doing.
The issue with is is that you need to know in advance if your changes will break the build in order to know to if you need to create a branch or not branch. I guess there are ways to do this ie work in develop, break it, create a patch, revert to develop, create new branch, reapply the patch and then commit new branch but probably needs to be documented.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 1:54 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> It is going to be a bit before we can answer all these questions. From the
>> git branching model, we need master (trunk) and the develop branch right
>> away.
> So any changes I wanted to commit I'll need to commit to develop branch once
> it exists?
Yes, and Carol just created it so "svn switch" to it and continue on.
> How exactly is it decided that the branch should then be merged
> with trunk?
I expect there to be a discussion about cutting a release shortly, then when
folks agree, we'd cut a branch from "develop" to make a release branch,
finish the release there and merge to both trunk and develop.
> How do we keep the develop branch in a state in which that is easy
> to do. Do we need to create other branches for things that might need some
> more testing/may not be 100%?
Yes, create branches for stuff that will break the build. There will be
differing opinions on this, but I think it is ok to check anything into
develop that doesn't break the build. So, you don't really need to branch
to add a new locale, for example.
>
> For example let say I want to work on something like getting Mustella working
> with filenames with spaces. I check out the develop branch, then I get to a
> point were I almost have it working but not quite so I can't check it back
> into develop as it's not 100%. How do I then share that with other people can
> work on it/help me out? (With SVN not Git.) Do I need to create another SVN
> branch, merge my changes in develop with that and check that new branch back
> in as a feature branch or do something else? Or do we just do this on a case
> by case bases so it's not really the gitflow model but more like the 3 Tier
> SVN model?
I would plan my changes so as not to break "develop" so I can just check it
in and share it even though it isn't 100% complete. If I can't do that I
would create a branch and folks can get at that branch from SVN if they want
to see what you are doing.
>
> Thanks
> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It is going to be a bit before we can answer all these questions. From the
> git branching model, we need master (trunk) and the develop branch right
> away.
So any changes I wanted to commit I'll need to commit to develop branch once it exists? How exactly is it decided that the branch should then be merged with trunk? How do we keep the develop branch in a state in which that is easy to do. Do we need to create other branches for things that might need some more testing/may not be 100%?
For example let say I want to work on something like getting Mustella working with filenames with spaces. I check out the develop branch, then I get to a point were I almost have it working but not quite so I can't check it back into develop as it's not 100%. How do I then share that with other people can work on it/help me out? (With SVN not Git.) Do I need to create another SVN branch, merge my changes in develop with that and check that new branch back in as a feature branch or do something else? Or do we just do this on a case by case bases so it's not really the gitflow model but more like the 3 Tier SVN model?
Thanks
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I'm with you Om. Now that we all have clear that we want 9# as a result of
the voting, it's a matter of getting the pieces enter in the puzzle. The
main thing here IMHO is that we choose for a model of future and we, as a
team, should row towards that goal.
2012/8/16 Om <bi...@gmail.com>
> On Thu, Aug 16, 2012 at 1:24 AM, Justin Mclean <justin@classsoftware.com
> >wrote:
>
> > Hi,
> >
> > I raised several concerns but lets not go over that ground again.
> >
> > We'll need to have some documentation on how it's going to work and what
> > SVN commands we need to use in each case. Anyone want to help out with
> this?
> >
> > We have a few people who don't know both SNV and Git well and no one used
> > Gitflow before (that I know) so even some simple guidance/instructions is
> > going to help everyone.
> >
> > >> How do we share the local branches that would exist in git?
> > > That may be one thing we can't do, but I don't think that was in the
> > > diagram, but I'm also not familiar enough with Git to say for sure.
> >
> > Most of the branches shown in the digram are local and only master and
> > develop are central in my understanding.
> >
> > Thanks,
> > Justin
>
>
> It is going to be a bit before we can answer all these questions. From the
> git branching model, we need master (trunk) and the develop branch right
> away. I believe everything else can wait and we can do it when needed.
> Any reason we need to branch right away? I am not aware of any major
> 'feature' branches or a release imminently coming up.
>
> Thanks,
> Om
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Om <bi...@gmail.com>.
On Thu, Aug 16, 2012 at 1:24 AM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> I raised several concerns but lets not go over that ground again.
>
> We'll need to have some documentation on how it's going to work and what
> SVN commands we need to use in each case. Anyone want to help out with this?
>
> We have a few people who don't know both SNV and Git well and no one used
> Gitflow before (that I know) so even some simple guidance/instructions is
> going to help everyone.
>
> >> How do we share the local branches that would exist in git?
> > That may be one thing we can't do, but I don't think that was in the
> > diagram, but I'm also not familiar enough with Git to say for sure.
>
> Most of the branches shown in the digram are local and only master and
> develop are central in my understanding.
>
> Thanks,
> Justin
It is going to be a bit before we can answer all these questions. From the
git branching model, we need master (trunk) and the develop branch right
away. I believe everything else can wait and we can do it when needed.
Any reason we need to branch right away? I am not aware of any major
'feature' branches or a release imminently coming up.
Thanks,
Om
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Using Git you have a complete repository localy in your machine.
Sure I understand that I do use git just not use gifflow before. We wont have full git support for a while. How do we work with SVN until then in the gitflow model? I know basically but the exact details I'm unsure on.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Justin,
Using Git you have a complete repository localy in your machine. In
contrast with SVN there's only pointers not complete copy of files. For
this reason is a distributed repository. So all branches in remote could be
checkout in local and you can create local branches and be able to publish
in remote.
Regarding gitflow. If you are in Mac I recomend you to use the free client
SourceTree that brings GitFlow out of the box. GitFlow is very convenient
since is a group of scripts that modelize what we read in
nvie.com/posts/a-successful-git-branching-model
Since this is the development model selected would be great to use Gitflow,
but first we need to solve all the stuff that relate to get Git working...
> Most of the branches shown in the digram are local and only master and
> develop are central in my understanding.
>
> Thanks,
> Justin
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I raised several concerns but lets not go over that ground again.
We'll need to have some documentation on how it's going to work and what SVN commands we need to use in each case. Anyone want to help out with this?
We have a few people who don't know both SNV and Git well and no one used Gitflow before (that I know) so even some simple guidance/instructions is going to help everyone.
>> How do we share the local branches that would exist in git?
> That may be one thing we can't do, but I don't think that was in the
> diagram, but I'm also not familiar enough with Git to say for sure.
Most of the branches shown in the digram are local and only master and develop are central in my understanding.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 12:38 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> Well first concern is will the Git branching model actually work with SVN as
> described in the document? It wasn't designed with SVN in mind.
In the prior discussions, nobody came up with a reason the branches shown in
the article couldn't be done in SVN, but we should expect greater merge pain
when merging, and I would avoid major refactoring in the next release.
There was a post I read about git-svn that might be helpful. I will try to
find that tomorrow. It talked about what kind of Git branching can mess up
git-svn. We should try to avoid that for now.
>
> So what changes need to be made to the process it in order for us with work
> cleanly with SVN?
I think we have to be careful about making lots of branches, but I think SVN
can handle the branching in the diagram.
> For instance how is history going to be managed when
> merging?
History will be handled however SVN handles merging and history.
> How do we share the local branches that would exist in git?
That may be one thing we can't do, but I don't think that was in the
diagram, but I'm also not familiar enough with Git to say for sure.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Well first concern is will the Git branching model actually work with SVN as described in the document? It wasn't designed with SVN in mind.
So what changes need to be made to the process it in order for us with work cleanly with SVN? For instance how is history going to be managed when merging? How do we share the local branches that would exist in git?
My guess (and hopefully I'm wrong but infra have a lot on their plate at the moment) that it will take some time to get GIt up and running for the project so it's likely we have to live with this for a while.
Thanks,
Justin
Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote
Results)
Posted by Alex Harui <ah...@adobe.com>.
As you may have seen, TLF is ready for donation. Falcon will be next week.
Given that, I think there are two "vectors" here that can be worked on in
parallel: 1) switching SVN usage to GBM and handling donations, and 2)
Getting a read/write Git repo.
It looks like there is a group of folks who are volunteering to work with
Infra so hopefully they will organize and make (2) happen.
Meanwhile, I think the rest of us can keep on using SVN. I don't think we
need to hold off for Git. I think the steps are:
(1) Rearrange SVN for new structure
(2) Create "develop" branch in sdk/trunk/branches
(3) Remove post-release commits from trunk and block the removal from
merging to "develop" branch.
(4) Start syncing and working from "develop" branch.
(5) Fixes to mustella go into "develop" and get synced to trunk
Thoughts?
-Alex
On 8/15/12 2:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> On 8/15/12 2:04 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
>>
>> If this is how the project wishes to roll then I would suggest the following
>> sequence assuming that Falcon is coming in a few days.
> The VP that signs these things won't sign until Monday at the earliest.
>
> FWIW, I think there will be at least one more donation (3.x) that was in
> Adobe SVN so keeping some sort of SVN around might be useful as a landing
> point then transferring to Git.
>
> I was thinking that it will be a few days until we get Git up and running
> even if we're very lucky so step 1.5 should be to create a develop branch in
> SVN and have folks get working (and branching) in SVN until Git is up.
>
>
>>
>> (1) Rearrange the SVN Repository for the new structure.
>>
>> (2) Import Falcon into SVN.
>>
>> (3) INFRA JIRA request for Git in the current supported mode. Include the
>> Flex
>> Git volunteers along with the PPMC, Committer, and/or Contributor status for
>> each.
>>
>> (4) Once the Git Mirrors are ready then let the pulls begin.
>>
>> (5) The Volunteers may help drive this to the desired, fully blessed, outcome
>> faster, or they might not, only work and time will tell. (Contributors may
>> very well earn enough merit for the PPMC to vote them Committer status.)
>>
>> BTW - There was an #asfinfra discussion about Apache Policy and enforcing no
>> log history rewrites along with requiring a rebase this morning. Didn't
>> follow
>> it too closely, but the result was the closing of an INFRA JIRA.
>>
>> Regards,
>> Dave
>>
>>
>>>
>>>
>>> --
>>> 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: [MENTORS] Current Branching Strategy Vote Results
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 2:04 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
> On Aug 15, 2012, at 1:25 PM, Alex Harui wrote:
>
>>
>>
>>
>> On 8/15/12 1:13 PM, "labriola@digitalprimates.net"
>> <la...@digitalprimates.net> wrote:
>>
>>>> Mike, there's about 2.5 hours left. If you change your vote to #9 and get
>>>> a
>>>> few others who responded to the poll but did not vote to move to #9, you
>>>> can
>>>> probably tip the scales in favor of GBM.
>>>
>>> Alex,
>>>
>>> How about you next? Wanna switch from Git later to Git now? We have people
>>> here who want to do the work. Shall we help them do so?
>>>
>>> Mike
>>>
>> My current count says it is 5 for Classic, 4 for GBM. If you can get one
>> more from someone else to tie it up, I will switch over to break the tie in
>> favor of GBM (unless the Classic folks also stage a rally).
>>
>> I've been pondering the notion that it just seems too risky to move to Git
>> now and what we really need is for GBM to win. The fine print in the ballot
>> says that if #9 wins but Apache doesn't let us move to Git now, we would
>> implement GBM on SVN until Apache makes Git official (which AFAICT is a
>> matter of when, not if).
>>
>> Given what I know we want to do short term, I think we can live with GBM on
>> SVN for now. The next release isn't going to contain any UIComponent
>> refactoring, we've got lots of mustella tests to fix and some new components
>> to integrate. I think SVN can handle that. If we implement GBM on SVN,
>> which pretty much means make a "develop" branch and having folks work there,
>> I think that allows committers to use Git and git-svn to commit and the
>> community to use our Git mirrors now. And hopefully infra will bless Git
>> read/write repos this year after our second release (and maybe even
>> graduation) and we can move there and start in on longer term projects.
>
> If this is how the project wishes to roll then I would suggest the following
> sequence assuming that Falcon is coming in a few days.
The VP that signs these things won't sign until Monday at the earliest.
FWIW, I think there will be at least one more donation (3.x) that was in
Adobe SVN so keeping some sort of SVN around might be useful as a landing
point then transferring to Git.
I was thinking that it will be a few days until we get Git up and running
even if we're very lucky so step 1.5 should be to create a develop branch in
SVN and have folks get working (and branching) in SVN until Git is up.
>
> (1) Rearrange the SVN Repository for the new structure.
>
> (2) Import Falcon into SVN.
>
> (3) INFRA JIRA request for Git in the current supported mode. Include the Flex
> Git volunteers along with the PPMC, Committer, and/or Contributor status for
> each.
>
> (4) Once the Git Mirrors are ready then let the pulls begin.
>
> (5) The Volunteers may help drive this to the desired, fully blessed, outcome
> faster, or they might not, only work and time will tell. (Contributors may
> very well earn enough merit for the PPMC to vote them Committer status.)
>
> BTW - There was an #asfinfra discussion about Apache Policy and enforcing no
> log history rewrites along with requiring a rebase this morning. Didn't follow
> it too closely, but the result was the closing of an INFRA JIRA.
>
> Regards,
> Dave
>
>
>>
>>
>> --
>> 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: [MENTORS] Current Branching Strategy Vote Results
Posted by Dave Fisher <da...@comcast.net>.
On Aug 15, 2012, at 1:25 PM, Alex Harui wrote:
>
>
>
> On 8/15/12 1:13 PM, "labriola@digitalprimates.net"
> <la...@digitalprimates.net> wrote:
>
>>> Mike, there's about 2.5 hours left. If you change your vote to #9 and get a
>>> few others who responded to the poll but did not vote to move to #9, you can
>>> probably tip the scales in favor of GBM.
>>
>> Alex,
>>
>> How about you next? Wanna switch from Git later to Git now? We have people
>> here who want to do the work. Shall we help them do so?
>>
>> Mike
>>
> My current count says it is 5 for Classic, 4 for GBM. If you can get one
> more from someone else to tie it up, I will switch over to break the tie in
> favor of GBM (unless the Classic folks also stage a rally).
>
> I've been pondering the notion that it just seems too risky to move to Git
> now and what we really need is for GBM to win. The fine print in the ballot
> says that if #9 wins but Apache doesn't let us move to Git now, we would
> implement GBM on SVN until Apache makes Git official (which AFAICT is a
> matter of when, not if).
>
> Given what I know we want to do short term, I think we can live with GBM on
> SVN for now. The next release isn't going to contain any UIComponent
> refactoring, we've got lots of mustella tests to fix and some new components
> to integrate. I think SVN can handle that. If we implement GBM on SVN,
> which pretty much means make a "develop" branch and having folks work there,
> I think that allows committers to use Git and git-svn to commit and the
> community to use our Git mirrors now. And hopefully infra will bless Git
> read/write repos this year after our second release (and maybe even
> graduation) and we can move there and start in on longer term projects.
If this is how the project wishes to roll then I would suggest the following sequence assuming that Falcon is coming in a few days.
(1) Rearrange the SVN Repository for the new structure.
(2) Import Falcon into SVN.
(3) INFRA JIRA request for Git in the current supported mode. Include the Flex Git volunteers along with the PPMC, Committer, and/or Contributor status for each.
(4) Once the Git Mirrors are ready then let the pulls begin.
(5) The Volunteers may help drive this to the desired, fully blessed, outcome faster, or they might not, only work and time will tell. (Contributors may very well earn enough merit for the PPMC to vote them Committer status.)
BTW - There was an #asfinfra discussion about Apache Policy and enforcing no log history rewrites along with requiring a rebase this morning. Didn't follow it too closely, but the result was the closing of an INFRA JIRA.
Regards,
Dave
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 1:13 PM, "labriola@digitalprimates.net"
<la...@digitalprimates.net> wrote:
>> Mike, there's about 2.5 hours left. If you change your vote to #9 and get a
>> few others who responded to the poll but did not vote to move to #9, you can
>> probably tip the scales in favor of GBM.
>
> Alex,
>
> How about you next? Wanna switch from Git later to Git now? We have people
> here who want to do the work. Shall we help them do so?
>
> Mike
>
My current count says it is 5 for Classic, 4 for GBM. If you can get one
more from someone else to tie it up, I will switch over to break the tie in
favor of GBM (unless the Classic folks also stage a rally).
I've been pondering the notion that it just seems too risky to move to Git
now and what we really need is for GBM to win. The fine print in the ballot
says that if #9 wins but Apache doesn't let us move to Git now, we would
implement GBM on SVN until Apache makes Git official (which AFAICT is a
matter of when, not if).
Given what I know we want to do short term, I think we can live with GBM on
SVN for now. The next release isn't going to contain any UIComponent
refactoring, we've got lots of mustella tests to fix and some new components
to integrate. I think SVN can handle that. If we implement GBM on SVN,
which pretty much means make a "develop" branch and having folks work there,
I think that allows committers to use Git and git-svn to commit and the
community to use our Git mirrors now. And hopefully infra will bless Git
read/write repos this year after our second release (and maybe even
graduation) and we can move there and start in on longer term projects.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [MENTORS] Current Branching Strategy Vote Results
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Mike, there's about 2.5 hours left. If you change your vote to #9 and get a few others who responded to the poll but did not vote to move to #9, you can probably tip the scales in favor of GBM.
Alex,
How about you next? Wanna switch from Git later to Git now? We have people here who want to do the work. Shall we help them do so?
Mike
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Michael, this is your turn to make the difference
:)
2012/8/15 Alex Harui <ah...@adobe.com>
>
>
>
> On 8/15/12 6:52 AM, "labriola@digitalprimates.net"
> <la...@digitalprimates.net> wrote:
>
> >> This is about which tools the committers use (and might have to
> partially
> >> support in case of Git, for now) so I wouldn't give much weight to the
> >> community's opinion in this particular case. Those who do the work
> >decide
> >> IMO.
> >
> > This feels like a great way to ensure the current committer pool doesn¹t
> grow.
> >
> > Mike
> Mike, there's about 2.5 hours left. If you change your vote to #9 and get
> a
> few others who responded to the poll but did not vote to move to #9, you
> can
> probably tip the scales in favor of GBM.
>
> --
> 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 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 15, 2012 at 3:52 PM, Michael A. Labriola
<la...@digitalprimates.net> wrote:
> Bertrand wrote:
>>This is about which tools the committers use (and might have to partially
>> support in case of Git, for now) so I wouldn't give much weight to the community's
>> opinion in this particular case. Those who do the work decide IMO.
>
> This feels like a great way to ensure the current committer pool doesn’t grow.
In general I would agree with you - this particular vote has mentors
unanimous on one opinion, PPMC leaning in the same direction and
community leaning in a different direction. My opinion is based on
allowing this project to finally start going forward instead of
endlessly discussing options.
-Bertrand
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Alex Harui <ah...@adobe.com>.
On 8/15/12 6:52 AM, "labriola@digitalprimates.net"
<la...@digitalprimates.net> wrote:
>> This is about which tools the committers use (and might have to partially
>> support in case of Git, for now) so I wouldn't give much weight to the
>> community's opinion in this particular case. Those who do the work >decide
>> IMO.
>
> This feels like a great way to ensure the current committer pool doesn¹t grow.
>
> Mike
Mike, there's about 2.5 hours left. If you change your vote to #9 and get a
few others who responded to the poll but did not vote to move to #9, you can
probably tip the scales in favor of GBM.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [MENTORS] Current Branching Strategy Vote Results
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>This is about which tools the committers use (and might have to partially support in case of Git, for now) so I wouldn't give much weight to the community's opinion in this particular case. Those who do the work >decide IMO.
This feels like a great way to ensure the current committer pool doesn’t grow.
Mike
Re: [MENTORS] Current Branching Strategy Vote Results
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Aug 15, 2012 at 12:24 AM, Alex Harui <ah...@adobe.com> wrote:
> ...We’re just past the halfway mark (and some folks who voted in the poll have not yet voted)
> but if I culled the votes properly (see below), there is a significant difference of opinion
> between the PPMC and the community...
This is about which tools the committers use (and might have to
partially support in case of Git, for now) so I wouldn't give much
weight to the community's opinion in this particular case. Those who
do the work decide IMO.
>From the community point of view, one big advantage of github IMO is
that it makes "drive-by contributions" easier, as you don't need to
subscribe to anything to create a pull request - but it's totally
possible for Flex committers to commit the occasional pull requests
that come in against the existing mirrors listed at
http://git.apache.org/ - and if/when those become too frequent, that
would be the time to revisit the tooling.
-Bertrand