While it is OK for me to drop GitFlow, I'm -1 for moving core development to GitHub. We should not rely on an external service for our internal workflow. GitHub should remain the interface for external contributors, but not the place where the committership driven development should take place. I'm pretty sure we'll get in trouble justifying such a move towards the board.
Basides that, what was the reasoning behind deprecating struts2-portlet-plugin? Did I miss something? - René Am 17.05.15 um 10:33 schrieb Lukasz Lenart: > 2015-05-15 15:08 GMT+02:00 Lukasz Lenart <lukaszlen...@apache.org>: >> Finally struts-archive was migrated to Git [1] so I can kicking out >> deprecated plugins and start cleaning up the code [2] >> >> [1] https://git1-us-west.apache.org/repos/asf?p=struts-archive.git;a=tree >> [2] >> https://cwiki.apache.org/confluence/display/WW/Struts+Next#StrutsNext-M1(akaStruts2.5) > > Before I will start working on 2.5 I would like throw away GitFlow - > it simple doesn't work for the project, to point just few issues: > - dedicated develop and bunch of feature branches which are replicated > all over the world and scatter other's repos [1] > - Maven does tagging which means I always have to remember to use -n > flag to avoid tagging by GitFlow > - Maven introduces next development cycle which means I always must > manually update version in master branch and resolve bunch of > conflicts in poms > - etc > > My idea is to have only master branch in Apache Git and use GitHub for > large work, so committers can always directly push changes to master > (we use tags to keep track on versions). If you are going to work on > something bigger you can create local branch or clone Struts via GH > and work on your own clone there. Next you can prepare a PR which will > be directly merged into master. So Git repo will always contain just > one branch which will reduce number of branches scattered over the > world. And as we use Maven to release new versions, it will be > possible to release directly from master branch - no need to update > versions and resolve conflicts. > > All this is based on my over year of experience with using GitFlow in > Struts. If there be no objections, in 72h - assuming silence > consensus, I will drop GitFlow support. > > > [1] my local list of branches > * develop > feature/WW-4176-support-string-keys-in-json > feature/locale-aware-converters > master > remotes/aleksandr-m/develop > remotes/aleksandr-m/feature/exclude-object-class > remotes/aleksandr-m/feature/http-interceptor > remotes/aleksandr-m/feature/preselect-optgroup > remotes/aleksandr-m/feature/remove-html5-deprecations > remotes/aleksandr-m/feature/use-js-to-support-multiple-buttons > remotes/aleksandr-m/feature/visitor-validator-full-field-name > remotes/aleksandr-m/master > remotes/origin/HEAD -> origin/master > remotes/origin/develop > remotes/origin/feature/locale-aware-converters > remotes/origin/master > > > Regards > -- René Gielen IT-Neering.net Kalkbergstraße 171, 52080 Aachen, Germany Tel: +49-(0)2405-4067285 Fax: +49-(0)2405-4067286 Cel: +49-(0)163-2844164 http://twitter.com/rgielen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
