git-flow applied! http://struts.staging.apache.org/git-for-struts.html
Please check if everything os ok (I'm not sure what else I suppose to do instead calling git flow init -d) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2014-01-29 Lukasz Lenart <lukaszlen...@apache.org>: > Just added info about git-flow > > http://struts.staging.apache.org/git-for-struts.html > > 2014-01-29 Lukasz Lenart <lukaszlen...@apache.org>: >> 2014-01-28 Rene Gielen <rgie...@apache.org>: >>> Am 28.01.14 12:19, schrieb Lukasz Lenart: >>>> I don't think we need git-flow - we don't have huge development team, >>>> there is (almost) no situation when we work together on some >>>> issue/feature. And learning the whole flow is useless (at this >>>> moment). >>>> >>> >>> Then I'm wondering a bit why we wanted to move to git in the first >>> place. It was my impression that we wanted to profit especially from >>> advanced processes like easy feature branching and merging, e.g. >>> - isolate features to make their impact better assessable >>> - allow for (yet not require!) code reviews before features are merged >>> to mainline - especially useful for our new committers, IMO >>> - allow cherry picking for releases >>> - backporting features from development to stable branches >>> - allow for collaborative working on groundbreaking features and ideas >>> for new major versions >>> - allow isolated work and straight forward, well documented processes >>> for hotfix releases, including multiple merging to all working branches >>> - allow for external contributions while working on new features, solely >>> targeted towards such feature >>> ... to name just a few. >> >> All these points are valid for git, but they don't proof that we must >> use the git-flow ;-) >> >>> As for me, I did not find it hard to learn git-flow to a level that I >>> felt my own and my team's productivity increased. I started with forcing >>> myself to work based on feature branches and the follow-up processes, >>> only to to find me loving it soon and missing it everywhere where I was >>> forced to use e.g. svn where such processes are PITA. >>> >>>> I'd rather start with something simpler and what we can understand and >>>> explain each others - using git-flow means we must understand how it >>>> works in first place and it isn't just to read some blog posts - >>>> understand the whole philosophy behind. >>>> >>> >>> I agree that git-flow is not the only possible way to go, and that we >>> might want to establish our own solution. Of course, it is well thought >>> out and flexible for both keeping things simple if you want to, as well >>> as offering advanced tooling for advanced problems. In either case - >>> adapting git-flow or working out our own process - I would opt for a >>> model that is both easy to use and grows with our needs. I see advanced >>> needs if we start our work on S3, and if we might manage to attract more >>> contributors along the way. Certainly we would want to establish a flow >>> that does not limit ourselves in future, wouldn't we? >>> >>> Just to give an example, I started some prototyping experiments on how >>> multiple possible return value types and result containers could work >>> out (inspired by Spring MVC and Play). To advance on this, I would like >>> to share this and have others review and potentially collaborate on >>> this. But for a rather long time, this might stay experimental and not >>> ready even for development branches that we might want to offer >>> adventurous users to use in their projects. I'm pretty sure that there >>> might be a lot of such experiments and ideas that develop around the >>> idea of bringing out a new major release. >> >> Ok, I'm still not fully convinced but it doesn't make sense to spend >> more time on this topic - let's adopt the git-flow! >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
