Re: Github Fork And Contibutions via Pull Request
Pascal Robert <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.wonder-disc |
|---|---|
| Message-ID | <[email protected]> |
Le 2012-10-18 à 15:40, Michael Hast <[email protected]> a écrit : > Thank you very much for the explanation. That makes all sense now. > > One more question. Do you checkout your Wonder fork from github when you > do a production release directly e.g. [email protected]:<your > name>/wonder.git, or did you clone your fork to a server in your company? Production release = fetching Wonder to build it along your application (with Jenkins or something else)? > What if github is not available or accessible, you still can access your > company server and checkout your fork from there? Just wondering. Don't forget that you always have your local copy, so even if GitHub is down, you can still commit, branches, etc. This is no SVN crap. > Michael > > On 10/18/2012 11:16 AM, Maik Musall wrote: >> Hi Michael, >> >> Am 18.10.2012 um 19:20 schrieb Michael Hast <[email protected]>: >> >>> Thanks Maik: >>> >>> Just to clarify: Here is what normally do. After creating the fork and doing a clone, I have the master branch checked out. Now we come across a bug or need to do a feature enhancement. >>> >>> 1. Code the change, commit the change and push it to our fork on github (master branch). >> >> Well. master is always weeks to months behind. You should checkout integration first and see if the given bug still occurs there. You should also review outstanding pull requests or issues on github to see if someone else already addressed this. >> >> If not, next choice is what wonder branch to base the changes on. Most people here who contribute to the project work with integration anyway, and for those it's a no-brainer. If you base your production stuff on master and need those changes there before they would make their way through integration and rc into the next master release, you could be better off to base them on master for that purpose, using a new branch based on the latest master release. >> >> You could then create a separate new branch from integration that you'll use to merge your changes in there periodically. That way you can always check compatibility against the newest wonder developments, and you would use that branch to make your pull request, because that needs to be based on integration for easier merge by the core committers. And you would need to be able to test your changes against newest integration before even making the pull request. >> >> Maik >> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Wonder-disc mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wonder-disc ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct