Hi Christofer,
Thanks for bringing up this topic. Yes, we should be working in branches
more.
To me, the problem is in getting folks to try your branch. The "dual"
branch has been out there for weeks now. How many of you have tried it?
Right now, it seems like the only way to get people to try it is to push
it to develop. Unfortunately, we don't have enough tests to prove that
someone won't get broken. We don't want to discourage contributions by
making the process take too long, but we don't want to delay everyone else
by breaking stuff. Apache projects aren't a business where a manager can
direct people to use the branch right away. We want a volunteer with a
spare evening to be able to propose a change and not have to wait days for
approval because we're all busy doing other things. We can have 3 folks
try the branch and like it and a 4th who just doesn't have time to test it
before it gets merged ends up getting broken. IOW, we have to come up
with a process that compensates for asynchronicity and volunteerism.
So while we should be using branches more, maybe we also have to get
better at defending ourselves against breakage. I think there are some
common scenarios.
1) Assuming you are working in a local branch, one common breakage is when
you merge back to develop locally and find that your changes no longer
work due to some other changes in the same repo.
2) Another common breakage is when you are working in flex-asjs and a
change to flex-falcon breaks flex-asjs. This happened recently. IMO, in
this scenario you can detach the head of flex-falcon using "git checkout
<some prior hash>".
3) Are most folks working from the repos or are folks relying on nightly
builds? Maybe we need to archive nightlies so you can roll back to them
if needed.
What else can we do to make it easier to use a different branch, and/or
get unblocked when something breaks?
Thoughts?
-Alex
On 3/28/17, 11:13 AM, "Peter Ent" <p...@adobe.com> wrote:
>+1 to this.
>
>Having pushed my changes to develop and causing a bit of mayhem, using a
>feature branch would have been the right thing to do. I'm currently trying
>to get the Charts package to work which will entail a little bit more
>change to HTML project, and I will put this into a features branch so
>everyone can try it out first before it gets merged into develop.
>
>We need to clean FlexJS up - I believe there are lots of unused files and
>the HTML project is way too big. So keep that in mind for the near future
>if you want do that.
>
>Regards,
>Peter Ent
>
>On 3/28/17, 12:49 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
><omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>
>>The general approach should be to first merge dev branch into the feature
>>branch and test if any examples are broken.
>>
>>Then ask for volunteers to test the feature branch and report issues.
>>
>>After a reasonable amount of time, the feature branch can ne merged into
>>dev.
>>
>>This will not solve all the issues, but major breakages can be contained
>>this way.
>>
>>At my work, for feature to dev merges, we have a Pull Request attached
>>to
>>a code review and an automated build. But given that we are open source
>>we
>>need to rely on self discipline and community testing.
>>
>>Thanks,
>>Om
>>
>>
>>On Mar 28, 2017 4:37 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com>
>>wrote:
>>
>>+1 to all of this.
>>
>>For people looking at the other's work it more easy to follow git graphs
>>if
>>people make it's own branch.
>>I suscribe all Chris's email and agree with all.
>>
>>So hope folks embrace the maven way of building and abandone ANT since
>>there's no benefit at all in that build system.
>>
>>Thanks Chris for bringing this :)
>>
>>
>>
>>2017-03-28 12:04 GMT+02:00 Harbs <harbs.li...@gmail.com>:
>>
>>> I do think that development should be done almost exclusively on
>>>feature
>>> branches.
>>>
>>> If the build status for a feature branch can be verified on the server
>>> (like you set it up) that¹s ideal because it does not require using
>>> specifically ant or maven locally.
>>>
>>> > On Mar 28, 2017, at 12:59 PM, Harbs <harbs.li...@gmail.com> wrote:
>>> >
>>> > I still have not managed to get maven setup correctly.
>>> >
>>> >> On Mar 28, 2017, at 12:46 PM, Christofer Dutz <
>>> christofer.d...@c-ware.de> wrote:
>>> >>
>>> >> Hi Harbs,
>>> >> (this time replying to the right name ;-) )
>>> >>
>>> >> I usually simply make sure I update my repos and do the full maven
>>> build with tests and examples locally before pushing Š I guess this is
>>> sufficient protection against most problems. In IntelliJ that¹s two
>>>clicks
>>> and a cup of coffee or whatever beverage you prefer.
>>> >>
>>> >> Chris
>>> >>
>>> >>
>>> >> Am 28.03.17, 11:41 schrieb "Harbs" <harbs.li...@gmail.com>:
>>> >>
>>> >> +1.
>>> >>
>>> >> I think it¹s OK to develop however we might be comfortable on a
>>> feature branch, but we definitely want an approved procedure which must
>>>be
>>> done before committing to the develop branch.
>>> >>
>>> >> Harbs
>>> >>
>>> >>> On Mar 28, 2017, at 12:29 PM, Christofer Dutz <
>>> christofer.d...@c-ware.de> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> For the last months, we have seen a huge increase in people working
>>>on
>>> the FlexJS and people working on first applications using FlexJS. I
>>>think
>>> we should discuss how we can make sure we don¹t have interruptions like
>>the
>>> current one in the future.
>>> >>>
>>> >>> One point that has been causing pain in the past, was that some
>>>people
>>> are using Ant and some are using Maven. Maven is quite a bit more
>>> restrictive than Ant and it builds a lot more and tests a lot more.
>>>Just
>>as
>>> an example in contrast to the Ant build the Maven build builds all
>>Examples
>>> and it also tests some of them to be runnable in a browser. The Ant
>>>build
>>> only builds the framework and most of the latest problems only pop up
>>>if
>>> you build an application. It has occurred several times that Changed
>>failed
>>> the Maven build but didn¹t fail the Ant build Š just because the Ant
>>>build
>>> doesn¹t build everything. We could avoid this problem if people would
>>>not
>>> simply ignore build failures reported by the ASF Jenkins, which is
>>>taking
>>> care of the Maven build. It is currently setup to give feedback within
>>>an
>>> hour or so.
>>> >>>
>>> >>> Sometimes the ³fix² was to exclude a module in Maven. This usually
>>>had
>>> the side-effect of the RAT plugin failing after that because it now
>>>finds
>>> files without Apache headers. A quick solution to that problem is to
>>log-in
>>> to the ASF Jenkins and to click on ³wipe workspace² of that build.
>>>After
>>> that this type of problem should go away immediately.
>>> >>>
>>> >>> Another point was that sometimes people work together on a larger
>>> refactoring and check-in stuff to develop in order to share code. We
>>should
>>> start using feature branches for this. This has currently not been
>>> happening at all. I have setup everything that if you create a branch
>>>IN
>>> ALL 3 REPOS with a name ³feature/{somename}² (but the same ³somename²
>>>in
>>> all three ;-) ) the ASF Jenkins will setup a Job for that which builds
>>all
>>> parts in one go and give you immediate feedback on the state of your
>>> branch. Feature branches that are not ³blue² should not be merged back
>>>to
>>> develop.
>>> >>>
>>> >>> One last pattern I have encountered was people reporting stuff
>>>like:
>>> ³I have been working on X and have almost finished ... I know it will
>>break
>>> Y, but I¹ll push my changes and fix Y after that² Š keep in mind: By
>>> breaking Y everyone working on FlexJS is forced to stop working so I
>>>will
>>> probably veto every suggestion I encounter on the list that has a
>>>similar
>>> pattern.
>>> >>>
>>> >>> FlexJS has matured and we are approaching a 1.0, but we also must
>>> mature the way we develop or we will hurt early adopters and people
>>willing
>>> to help get FlexJS to shape. We want enterprise users to use our stuff,
>>> then we must start working in an enterprise-acceptable way.
>>> >>>
>>> >>> Keep up the awesome work and lets just get a little more awesome
>>>;-)
>>> >>>
>>> >>> Chris
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>>--
>>
>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.code
>>o
>>scopic.com&data=02%7C01%7C%7C123774576f0941e3637108d475fa6eb3%7Cfa7b1b5a7
>>b
>>34438794aed2c178decee1%7C0%7C0%7C636263165849714677&sdata=QOYgOePHU%2FtUV
>>T
>>uukDlhpZ%2FLJxXJgTQW7%2FnFMCnyG%2Fg%3D&reserved=0>
>>
>>Carlos Rovira
>>
>>Director General
>>
>>M: +34 607 22 60 05
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeo
>>s
>>copic.com&data=02%7C01%7C%7C123774576f0941e3637108d475fa6eb3%7Cfa7b1b5a7b
>>3
>>4438794aed2c178decee1%7C0%7C0%7C636263165849714677&sdata=QOYgOePHU%2FtUVT
>>u
>>ukDlhpZ%2FLJxXJgTQW7%2FnFMCnyG%2Fg%3D&reserved=0
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avant
>>2
>>.es&data=02%7C01%7C%7C123774576f0941e3637108d475fa6eb3%7Cfa7b1b5a7b344387
>>9
>>4aed2c178decee1%7C0%7C0%7C636263165849714677&sdata=smQ0AM8OqoFkIcpLhXRqqs
>>w
>>wB38V6n8JrRoi1C%2BD9xs%3D&reserved=0
>>
>>
>>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>información privilegiada o confidencial. Si ha recibido este mensaje por
>>error, le rogamos que nos lo comunique inmediatamente por esta misma vía
>>y
>>proceda a su destrucción.
>>
>>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>comunicamos
>>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>servicio o información solicitados, teniendo usted derecho de acceso,
>>rectificación, cancelación y oposición de sus datos dirigiéndose a
>>nuestras
>>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>necesaria.
>
