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