Document in the wiki the process and conventions that are to be used to maintain the standard

[AaronWilton]

need to document conventions for:
branching
milestones

[AaronWilton]

For standard development work that we are doing I think we are more after the BRANCH option

1. It keeps the repository together so we can work collaboratively on it… (cf FORK which makes your own distinct, personal copy)
2. If I am not mistaken (and there is a good chance that I am!) FORK is a github concept not a pure GIT concept -> implications for tools? Transfer to other repos?
   My vote
3. is that we only use Branch
4. We have a single development branch that is the Branch that will be VOTED on for inclusion into the MASTER
5. We can have other feature branches that we work on that will be merged back into the development branch, then if accepted into the MASTER
   We should transfer this discussion to Document in the wiki the process and conventions that are to be used to maintain the standard #39
   I will copy this email to that issue
   Cheers
   A

From: Niels Klazenga [mailto:Niels.Klazenga@rbg.vic.gov.au]
Sent: Tuesday, 17 March 2015 5:39 p.m.
To: Ben Richardson; Aaron Wilton
Cc: anne.fuchs@environment.gov.au; eleanor.crichton@sa.gov.au
Subject: RE: HISPID Review telephone hook-up

And that I know how to do, as that is how I edited the AVH Advanced Search page. Also, anyone can do that, not just us, and we still get to decide what goes in and what not. I think both viable alternatives.

"Richardson, Ben" Ben.Richardson@DPaW.wa.gov.au 17/03/2015 3:32 PM >>>
Aaron,

Were you suggesting we each work in our own branch? Or was it that you thought we could share a development branch?

GitHub has the concept of forking, which goes even further, copying the entire tree into my account, perhaps this is even better?

Cheers, Ben

[nielsklazenga]

I think whether to fork or not to fork is not the question. People who are not owners who do want to make changes have to fork anyway and have to do a pull request. Owners can decide for themselves whether they want to push directly into the hiscom/hispid repository, or want to push to a fork they created in their own account and send a pull request, which they can then merge themselves (seems an unnecessary detour to me)..

The question is what we want to do with changes that are pushed or pulled into the hiscom/hispid repository, whether they go straight into the master, or whether they go first into a branch, which can later be merged into master. Aaron wants the latter and I think (now) that makes sense, as that means the master will never be in between two "versions" and will always have the current version.

[AaronWilton]

Yes - that is a good summary Niels.
Using a Master branch and a new version branch would also allow us to make minor corrections to the master - so called hot fixes while we are working on the next version - in this cases those hot fixes would be minor/trivial edits I guess (e.g,. typo's in note or similar)