+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
>
>
>
