Sometime ago someone made the case that we should drop the Debug branch in the git storage for the libraries. I found the case pretty convincing and endorsed the change. However, it seems that the idea was not well received and the idea was not adopted. I hope my endorsement wasn't responsable for it's being dismissed. Now it seems that the idea HAS been adopted. I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging. This was kind of problematic as the debug and master branch were no longer easily understood by doing a diff. Worse, other "maintainers" check into the debug branch in the traditional way leaving the merge to master as a separate operation in the traditional manner. My custom has been to merger to master just before the next release. I only dip into maintenance occasionally, so I don't remember all the details and I have to spend a lot of time looking at who did what. So, I'm announcing that I am unilaterally declaring soon I will be leaving the debug branch aside and not use it in the future. Those who have the authority to directly make changes in these libraries (as opposed do making a merge request) should know that any pushes to the debug branch will be lost. Robert Ramey
On 10 Apr 2025 23:38, Robert Ramey via Boost wrote:
Sometime ago someone made the case that we should drop the Debug branch in the git storage for the libraries. I found the case pretty convincing and endorsed the change. However, it seems that the idea was not well received and the idea was not adopted. I hope my endorsement wasn't responsable for it's being dismissed.
Now it seems that the idea HAS been adopted. I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging. This was kind of problematic as the debug and master branch were no longer easily understood by doing a diff. Worse, other "maintainers" check into the debug branch in the traditional way leaving the merge to master as a separate operation in the traditional manner. My custom has been to merger to master just before the next release.
I only dip into maintenance occasionally, so I don't remember all the details and I have to spend a lot of time looking at who did what. So, I'm announcing that I am unilaterally declaring soon I will be leaving the debug branch aside and not use it in the future. Those who have the authority to directly make changes in these libraries (as opposed do making a merge request) should know that any pushes to the debug branch will be lost.
First, I'm assuming you mean the develop branch, not debug. Second, the two branches are referenced by the superproject and therefore are used by all submodules, including those which are not maintained by you. If you stop updating develop, this will eventually affect any downstream libraries, potentially breaking them. If this is your intention (is it?) then I guess this signals downstream libraries to stop depending on your libraries. I'm not sure how it affects the superproject and the release procedure, but it raises the question of whether the libraries should stay in Boost in this state or be eventually removed (which would be unfortunate). I'm curious, what is the problem with develop are you facing that warrants such a change?
On 4/10/25 1:57 PM, Andrey Semashev via Boost wrote:
On 10 Apr 2025 23:38, Robert Ramey via Boost wrote:
Sometime ago someone made the case that we should drop the Debug branch in the git storage for the libraries. I found the case pretty convincing and endorsed the change. However, it seems that the idea was not well received and the idea was not adopted. I hope my endorsement wasn't responsable for it's being dismissed.
Now it seems that the idea HAS been adopted. I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging. This was kind of problematic as the debug and master branch were no longer easily understood by doing a diff. Worse, other "maintainers" check into the debug branch in the traditional way leaving the merge to master as a separate operation in the traditional manner. My custom has been to merger to master just before the next release.
I only dip into maintenance occasionally, so I don't remember all the details and I have to spend a lot of time looking at who did what. So, I'm announcing that I am unilaterally declaring soon I will be leaving the debug branch aside and not use it in the future. Those who have the authority to directly make changes in these libraries (as opposed do making a merge request) should know that any pushes to the debug branch will be lost.
First, I'm assuming you mean the develop branch, not debug.
Right
Second, the two branches are referenced by the superproject and therefore are used by all submodules, including those which are not maintained by you. If you stop updating develop, this will eventually affect any downstream libraries, potentially breaking them.
True. On my own system, I've dropped testing against other libraries which are not on the master branch. That is, I set all the boost libraries excepting my own to master branch. This is because I spent way too much time trying to test something in my own library which I ended up having to track down into some other library which was in a state of flux due to being on the develop branch. A huge waste of time. By doing this way, I had the confidence that when my library was updated in the master, it was effectively testing against the next release rather than the last one. This eliminated occasional problems which consumed disproportional amount of time to sort out.
If this is your intention (is it?) then I guess this signals downstream libraries to stop depending on your libraries.
LOL - it signals downstream libraries that they are I'm not sure how it
affects the superproject and the release procedure, but it raises the question of whether the libraries should stay in Boost in this state or be eventually removed (which would be unfortunate).
Since we have no usage statistics for individual libraries, we have no way of knowing which libraries we should prioritize. It raises the question as to what utility the develop branch provides.
I'm curious, what is the problem with develop are you facing that warrants such a change?
see above. It's mostly a problem because I only engage in library maintenance occasionally. And truth is I forget a lot of stuff in the meantime. I'm also not a git guru (and hardly a git hacker!) which also means an amount of wasted time. I've totally given up trying to understand B2 and I never touch the jam files so at least that's not a problem. I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11 Apr 2025 02:29, Robert Ramey via Boost wrote:
On 4/10/25 1:57 PM, Andrey Semashev via Boost wrote:
Second, the two branches are referenced by the superproject and therefore are used by all submodules, including those which are not maintained by you. If you stop updating develop, this will eventually affect any downstream libraries, potentially breaking them.
True. On my own system, I've dropped testing against other libraries which are not on the master branch. That is, I set all the boost libraries excepting my own to master branch. This is because I spent way too much time trying to test something in my own library which I ended up having to track down into some other library which was in a state of flux due to being on the develop branch. A huge waste of time. By doing this way, I had the confidence that when my library was updated in the master, it was effectively testing against the next release rather than the last one. This eliminated occasional problems which consumed disproportional amount of time to sort out.
I understand that it can be frustrating to have your code broken by someone else's change, but this is just the nature of software development. You can report the issue if you don't want to dig into it. Personally, I find reporting bugs or PRs in other components just another way to contribute to the project, and usually, if the library is maintained, the reported bugs do get fixed in a timely manner. As a last resort, if a certain component is repeatedly causing problems, you have the option to stop using it. However, if you stop updating develop this will permanently affect other libraries' develop builds with no course of resolution on their part, other than to just stop using your libraries.
If this is your intention (is it?) then I guess this signals downstream libraries to stop depending on your libraries.
LOL - it signals downstream libraries that they are
Assuming that this sentence is complete, there are quite a few dependencies on Boost.Serialization. https://pdimov.github.io/boostdep-report/develop/serialization.html#reverse-...
I'm not sure how it
affects the superproject and the release procedure, but it raises the question of whether the libraries should stay in Boost in this state or be eventually removed (which would be unfortunate).
Since we have no usage statistics for individual libraries, we have no way of knowing which libraries we should prioritize.
It concerns all offending libraries, regardless of usage or priorities.
I'm curious, what is the problem with develop are you facing that warrants such a change?
see above.
It's mostly a problem because I only engage in library maintenance occasionally. And truth is I forget a lot of stuff in the meantime. I'm also not a git guru (and hardly a git hacker!) which also means an amount of wasted time. I've totally given up trying to understand B2 and I never touch the jam files so at least that's not a problem.
Perhaps, you should seek for a co-maintainer then? For git, you may want to maintain a model where develop and master track the same sequence of commits rather than separate. This does require some discipline, in particular: - no merge commits from develop to master - no cherry-picks from develop to master, unless absolutely needed (which may happen during a release cycle, but normally should not happen) - every merge from develop to master is a fast-forward one - if develop and master have diverged (usually, during a release cycle, when select commits need to be merged to master but not the whole develop), unify them ASAP (usually, after the release is shipped). This makes reasoning about commit history easier as you only have a single history to deal with instead of two. Both `git log` and GitHub UI shows which commits have made it to master and which haven't yet.
I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous.
It's not an unreasonable point of view, but unilaterally dropping develop in spite the rest of the project is disruptive and harmful to the developers who still see value in it. Such decisions need to be made project-wide, and the last discussion showed that most people still find the develop branch useful.
On Fri, Apr 11, 2025 at 2:59 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous.
Considering the master branch is closed to merges for over a month during each release cycle, the develop branch gives dependent libraries a good time window to test out new changes before merging into master. Otherwise, in the event of a regression, the amount of changes in master could become overwhelming for the release manager.
Am 11.04.25 um 01:29 schrieb Robert Ramey via Boost:
It's mostly a problem because I only engage in library maintenance occasionally. And truth is I forget a lot of stuff in the meantime. I'm also not a git guru (and hardly a git hacker!) which also means an amount of wasted time.
I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous.
Does "feature branch way of doing things" refer to: Develop a new feature in a branch, if done and tested merge that to "production"? I see how this makes the develop branch pretty much superfluous. It is the equivalent to a "staging" branch though, i.e. the last point before it goes to production. As you already test your changes against master and your CI tests them against develop when you open your usual PR what you could do is merge develop to master right after merging the PR. Of course except during a release preparation where the last merge needs to wait. This way your workflow has only a minor extra step but enables everyone else to maintain their workflow. As a "bonus" you can continue to work even when master is closed which you couldn't with only one branch. At least you could not test multiple changes/PRs together. To me it looks mainly like a communication issue: You look at your master branch after a while and see a non-merge commit you didn't do and were not aware of. Now you'd need to do extra work to check that this commit is also in your develop branch, which is annoying I guess. Would a compromise be acceptable for you that some "trusted contributors" (it seems only Peter does such cherry-picks) be allowed to merge develop to master when you didn't do that yet after merging a PR to develop? As your workflow of testing against master is known, I think there is no risk in doing that instead of cherry-picks. This way others are unblocked in case of "pending" changes from your side and you don't need to check anything extra if there are only merge commits in master. Of course this doesn't solve the issue where your develop branch gets broken due to a change in some other library. But that would soon be in master too breaking also your master branch. This is however not much different than when using a single-branch Boost-wide. That being said I understand your concern about having 2 branches, especially with the many states the whole of Boost could be in when each library can have "pending" changes or not. I've been bitten too waiting for changes that others didn't merge to master yet, but of course others are limited in their resources too. Maybe we can improve that somehow.
On Thu, Apr 10, 2025 at 3:43 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging.
Can you point to specific such cases? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On 4/10/25 2:01 PM, René Ferdinand Rivera Morell via Boost wrote:
On Thu, Apr 10, 2025 at 3:43 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging.
Can you point to specific such cases?
Here's one from the Safe Numerics library: https://github.com/boostorg/safe_numerics/commit/777e0be5ec763d0333a717c5e42... here's a few more from the serialization library $git log --committer=Dimov commit 030b627dcee41b44875d8ae496c4baf744426a52 (origin/feature/fix-clang-cl-regression) Author: Peter Dimov <pdimov@gmail.com> Date: Mon Aug 28 17:37:15 2023 +0300 Fix clang-cl regression introduced by #282 commit f395fa35faf32a89de4673fa54635eeb5eb39f0c (origin/feature/remove-jam-debug-print) Author: Peter Dimov <pdimov@gmail.com> Date: Sat Aug 26 00:27:50 2023 +0300 Remove debug output from util/test.jam commit 52bcaffa8c895a549c4d594511898acf8b821688 (origin/feature/fix-testmi-sub-eq) Author: Peter Dimov <pdimov@gmail.com> Date: Sat Aug 26 00:08:48 2023 +0300 Fix Sub::operator== signature to avoid ambiguity errors in C++20 commit 48a60a2bbb6b214d3c295fc2943aff22db63a944 (origin/feature/remove-gha-cxx03) Author: Peter Dimov <pdimov@gmail.com> Date: Fri Aug 25 20:57:19 2023 +0300 Remove C++03 from GHA, because Variant and LexicalCast no longer compile under C++03 Looking at this more carefully, I see that I'm the major offender in this practice. Oh Well. I guess it's easier to do than first meets the eye. I will say that when it has been done without my knowing it, it seems to take a lot of fussing around to track down the anomolies that show it. Robert Ramey
On Thu, Apr 10, 2025 at 9:11 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 4/10/25 2:01 PM, René Ferdinand Rivera Morell via Boost wrote:
On Thu, Apr 10, 2025 at 3:43 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging.
Can you point to specific such cases?
Here's one from the Safe Numerics library:
https://github.com/boostorg/safe_numerics/commit/777e0be5ec763d0333a717c5e42...
Just looking at that one, as I suspect the others are the same, it looks perfectly normal. Peter made a build system fix in the develop branch, probably waited for tests to pass, and then cherry picked the change from develop to master. Which is the appropriate way to do things that will track history such that the master branch can get specific fixes sooner than general merging from develop to master. And is the way that will ensure that the change is not clobbered (or munged) when such a general develop to master merge is done. Of course assuming that one doesn't otherwise make changes to master that bypass the develop branch. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
Robert Ramey wrote:
here's a few more from the serialization library
$git log --committer=Dimov commit 030b627dcee41b44875d8ae496c4baf744426a52 (origin/feature/fix-clang-cl-regression) Author: Peter Dimov <pdimov@gmail.com> Date: Mon Aug 28 17:37:15 2023 +0300
Fix clang-cl regression introduced by #282
This is https://github.com/boostorg/serialization/pull/296 merged by you.
commit f395fa35faf32a89de4673fa54635eeb5eb39f0c (origin/feature/remove-jam-debug-print) Author: Peter Dimov <pdimov@gmail.com> Date: Sat Aug 26 00:27:50 2023 +0300
Remove debug output from util/test.jam
This is https://github.com/boostorg/serialization/pull/294 merged by you.
commit 52bcaffa8c895a549c4d594511898acf8b821688 (origin/feature/fix-testmi-sub-eq) Author: Peter Dimov <pdimov@gmail.com> Date: Sat Aug 26 00:08:48 2023 +0300
Fix Sub::operator== signature to avoid ambiguity errors in C++20
This is https://github.com/boostorg/serialization/pull/295 merged by you.
commit 48a60a2bbb6b214d3c295fc2943aff22db63a944 (origin/feature/remove-gha-cxx03) Author: Peter Dimov <pdimov@gmail.com> Date: Fri Aug 25 20:57:19 2023 +0300
Remove C++03 from GHA, because Variant and LexicalCast no longer compile under C++03
This is https://github.com/boostorg/serialization/pull/293 merged by you. What, exactly, is the accusation here? That I've submitted pull requests to Serialization?
On 4/10/25 4:13 PM, Robert Ramey via Boost wrote:
Looking at this more carefully, I see that I'm the major offender in this practice. Oh Well. I guess it's easier to do than first meets the eye. I will say that when it has been done without my knowing it, it seems to take a lot of fussing around to track down the anomolies that show it.
It seems I got this wrong and I apologize to Peter and Rene. I think I was confused by this github page. https://github.com/boostorg/serialization/tree/master Whe I select a particular commit, it switches to the branch to "develop". Git seems simple when it's explained. But when one starts to use it, it seems a lot hard to understand. Again I apologize to Peter and Rene.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Apr 11, 2025 at 12:49 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
Git seems simple when it's explained. But when one starts to use it, it seems a lot hard to understand.
Except that https://github.com/boostorg/serialization/tree/master is not git, it is GitHub. The former is a significant technological advancement invented by Linus Torvalds while the latter is a proprietary web application purchased by Microsoft. They are not the same. Thanks
participants (7)
-
Alexander Grund -
Andrey Semashev -
Mohammad Nejati [ashtum] -
Peter Dimov -
René Ferdinand Rivera Morell -
Robert Ramey -
Vinnie Falco