OK, fair enough ! I am comfortable with that ;) 2014-11-27 18:57 GMT+01:00 Gerhard Petracek <[email protected]>:
> @oliver: > as you might have seen those branches are just external. they never get > added to the main repository. instead the content is applied via a rebase. > at deltaspike we only used that if it's easier to show something based on a > refactoring or a small prototype (instead of long threads on the > mailing-list). > > @anatole: > at the asf the whole code-base is open to every committer of the project > and everybody is equal (when it comes to commits). > a commit which isn't "optimal" can be fixed by a subsequent commit. > what we did at other projects is e.g. a release-review (at least in view of > the api). > being too restrictive during the development-phase will scare > community-members off. > > regards, > gerhard > > > > 2014-11-27 16:53 GMT+01:00 Anatole Tresch <[email protected]>: > > > 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 > > > > > > > > > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
