My experience shows that they are only rarely used. Most of the discussions we had in JSR 354 were done only on the mailing list, and I will follow a similar discussion scheme to enable this as well here. Basically every EG member could commit to the API, whereas RI and TCK was quite open. Basically this has proven to work well, as long as every commit is reviewed by somebody (the project or stream lead).
Static code analysis, continuous build etc is a must for me, for everything. I tend to say: let us start on the mailing list and keep things simple first so we have quick progress. I am quite sure, especially with the quality of committers on the list, we will not face bigger issues. But definitively, when growing over time, we must add some kind of more advanced quality gates. Nevertheless we must ensure that everybody cannot change APIs without prior discussion and agreement with the core team. But from my experience (JSR 354) this was never an issue when you have a relatively small committer community and the process is clearly stated (documented). Bugfixes / tests are generally easier to handle. Anatole Oliver B. Fischer <[email protected]> schrieb am Thu Nov 27 2014 at 16:37:37: > I still doubt that feature branches the right way to go. I don't refuse > them generally but they are not a good choice for ongoing development > which is not finished after a short period. Many feature branches lead > to late integration and the effort for integration is much higher then > without. They even prohibit refactorings if a large amount of the code > base is effected. > > If we worry about the code quality there are other ways open for us. > Better and more tests, better coverrage, static code analysis and good > and communicated coding rules. > > I would prefer to have a stable branch and an development branch. > Development branch is open for direct commits until it enters a > stabilizing phase. > > I still think that we should have an open commit policy until we have > reached a specific state for Tamaya. > > wdyt? > > Best, > > Oliver > > > > > Am 27.11.14 10:40, schrieb Gerhard Petracek: > > you don't need a formal vote (= 72h waiting time) in any case. > > for sure we need to discuss every part of the api (also the parts of the > > initial import). > > (for such cases a formal vote is just needed if there is no agreement.) > > > > @feature branches: > > if we need to discuss ideas which are prototyped, we can follow [1]. > > -> you don't get tons of branches and merge-commits, but you have most of > > the benefits. > > > > @github: > > it used to be a read-only mirror. > > > > just fyi: > > history-rewrites of pushed commits are restricted > > > > regards, > > gerhard > > > > [1] > > http://deltaspike.apache.org/suggested-git-workflows.html# > discussion-workflow-optional > > > > > > > > 2014-11-27 10:21 GMT+01:00 Anatole Tresch <[email protected]>: > > > >> The project is also mirrored to GH, i did not check if it is writable > from > >> the mirror as well, but if so wecan benefit from the GH > infrstructure...? > >> > >> - > >> Anatole Tresch > >> Glärnischweg 10 > >> 8620 Wetzikon > >> Tel +41 (43) 317 05 30 > >> - > >> Send from Mobile > >> > >>> Am 27.11.2014 um 10:14 schrieb "Oliver B. Fischer" < > >> [email protected]>: > >>> I agree on the quality aspect and that the hard part of Tamaya will be > >> the discussion. Only my personal experience with feature branches is > not so > >> positive. I know it works for a lot of people and even for a lot of > >> projects at GitHub and at Bitbucket. Such plattforms provide tooling > >> support we don't have. Or do we? > >>> Bye, > >>> > >>> Oliver > >>> > >>> -- > >>> N Oliver B. Fischer > >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >>> P +49 30 44793251 > >>> M +49 178 7903538 > >>> E [email protected] > >>> S oliver.b.fischer > >>> J [email protected] > >>> X http://xing.to/obf > >>> > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > >
