Matt Yes i think even for the most trivial of updates it is possibly worthwhile. It seems that it will provide a nice traceability to a 'unit of work/ticket'. Since branching/merging is so cheap/natural this also has the really nice side effect of being able to selectively include/revert/etc..
Wondering though if these branches should be pushed to this central repo. I assume so. In all these cases I am making this up based on my own limited Git experience and knowledge so look forward to other views. Thanks Joe On Tue, Dec 9, 2014 at 10:28 AM, Matt Gilman <[email protected]> wrote: > We definitely need to discuss what the expectations are here as this is my > first time working in this model. I've now addressed two minor isolated > issues without 'feature' branching. This work was performed and pushed back > to the develop branch. Do we really want to require branching off of > develop when the issue is something as simple as adding a dependency to a > pom (which was the case for one of the issues)? > > Thanks. > > On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <[email protected]> wrote: > > > Hello > > > > So a question on gitflow given that commits are now underway. When > working > > on a feature in a local repo which is a branch off the develop > branch...do > > you push the feature branch to the central repo? This then can be merged > > by someone else as a sort of code review/pull process? > > > > Thanks > > Joe > > > > On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <[email protected]> wrote: > > > > > All, > > > > > > Now that we have our code up it is important to establish a process > > around > > > git in particular. A general consensus in the thread appears to be > that > > > gitflow workflow is a reasonable option. > > > > > > > > > > > > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > > > > > > To that end I've added a develop branch off of master from which > features > > > can be built. As we converge toward a release then we'll > > address/introduce > > > some of the other aspects of gitflow. > > > > > > Please discuss/comment if there are views that we should be taking > > another > > > path. > > > > > > Thanks > > > Joe > > > > > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies < > [email protected] > > > > > > wrote: > > > > > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <[email protected]> > > >> wrote: > > >> > Hi Adam, > > >> > > > >> > one remarks about this: > > >> > > > >> > On 28/11/14 18:07, Adam Taft wrote: > > >> >> > > >> >> Knowing how we work today, if it were me, I would suggest using the > > >> above > > >> >> workflow combined with the "forking workflow" to guard access to > the > > >> >> production release (master) branches. A very small subset of the > > >> >> incubator's commiters should have the ability to merge the > "develop" > > >> >> branch > > >> >> down to a master "release" branch. > > >> > > > >> > > > >> > Suck workflow is not in place in ASF. On the one hand, the current > git > > >> > infrastructure does not provide such branches' management, like > > >> > bitbucket/stash do for instance. On the other hand, and more > > important, > > >> a > > >> > project is not hierarchical organization, but a a meritocratic one. > > >> > > > >> > I recommend you this blog post in case you want to read a bit more: > > >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/ > > >> > > > >> > If someone has permissions to do (i.e., he is a committer), he can > do > > >> it, > > >> > simple The tool provide you instruments to revert those changes in > > case > > >> on > > >> > involuntary errors. > > >> > > > >> >> It would be ideal to have someone who > > >> >> is NOT performing the majority of changes on the "develop" branch > > take > > >> >> this > > >> >> role to coordinate releases, ensure minimal coding standards, run > > >> through > > >> >> unit and integration tests, before signing off on the release and > > >> issuing > > >> >> the release artifacts. > > >> > > >> You seem to be imagining an individual with a job which is shared in > > >> by the community. In healthy communities, a release happens when > > >> there's a consensus to have a release. There is no person who 'ensures > > >> minimal coding standards', that's everyone watching commits. There's > > >> no one 'running unit and integration tests' because (a) every > > >> committer does this before every commit, (b) Jenkins does it, (c) the > > >> release process does it. (d) there's no signing off on a release. The > > >> RM puts it up for a vote, and PMC members vote. > > >> > > >> > > >> > > > >> > > > >> > Release comes after that. The release manager is responsible on > > >> creating a > > >> > proper release, which must include a code release and should include > > >> > binaries too. Each artifact release must be signed. Demonstrate your > > >> ability > > >> > as a project to produce releases is one of the goals of the > > incubation. > > >> But > > >> > we are not yet there, step by step. > > >> > > > >> > Hope that helps. > > >> > > > >> > Cheers, > > >> > > > >> > > > >> > -- > > >> > Sergio Fernández > > >> > Partner Technology Manager > > >> > Redlink GmbH > > >> > m: +43 660 2747 925 > > >> > e: [email protected] > > >> > w: http://redlink.co > > >> > > > > > > > > >
