Re: [boost] [git help] Documenting common modular boost workflows
Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind. I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems). And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle? Sent from Windows Mail From: Peter Dimov Sent: Monday, October 21, 2013 10:16 AM To: Boost Dev-List Dave Abrahams wrote:
IIUC we already agreed long ago to use gitflow:
It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers? When Boost release 1.64.0 is started, who is going to create the gitflow release branch, and from what? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Oct 21, 2013 at 2:57 PM, Daryle Walker
Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind.
Gitflow is about managing the flow of work through the branches of a project. Why would it matter if that project is included in another project as a sub-module? Or included in 100 projects as a sub-module, for that matter?
I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems).
I'm guessing something similar to your guesses, but I was hoping to get a response from someone who had actually used Gitflow in a submodule environment.
And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle?
That's a whole topic in of itself, and may have different answers for the short term and the long term. I don't want to waste CPU cycles on that until the basic local machine docs are further along. --Beman
Beman Dawes wrote:
And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle?
That's a whole topic in of itself, and may have different answers for the short term and the long term. I don't want to waste CPU cycles on that until the basic local machine docs are further along.
You would be putting the carriage before the horse then. What the testers test and how a release is prepared determine how a library maintainer works, not vice versa.
On Mon, Oct 21, 2013 at 9:39 PM, Peter Dimov
Beman Dawes wrote:
And do the test runners work off “develop,” “master,” “release,” or does > it shift depending where we are in the release cycle?
That's a whole topic in of itself, and may have different answers for the short term and the long term. I don't want to waste CPU cycles on that until the basic local machine docs are further along.
You would be putting the carriage before the horse then. What the testers test and how a release is prepared determine how a library maintainer works, not vice versa.
You are right of course in a design sense, and that's exactly how the design evolved two or three years ago. There were endless discussions of testing and release management wants and needs. But my part in this right now is to get enough documentation together to allow boost developers who have no familiarity with git, let alone gitflow, to start to experiment with their libraries in a modular environment. Once the basic developers docs are in place the plan is to move on to tester and release manager docs. --Beman
on Mon Oct 21 2013, Daryle Walker
Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind.
I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems).
And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle?
Ideally, we'd test everything, in this priority order: master release/v<version> develop
Sent from Windows Mail
From: Peter Dimov Sent: Monday, October 21, 2013 10:16 AM To: Boost Dev-List
Dave Abrahams wrote:
IIUC we already agreed long ago to use gitflow:
It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers?
Both
When Boost release 1.64.0 is started, who is going to create the gitflow release branch,
A Boost release manager
and from what?
From the "master" branch of the top-level Boost repository
-- Dave Abrahams
participants (4)
-
Beman Dawes -
Daryle Walker -
Dave Abrahams -
Peter Dimov