Re: Git Debug Branch

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2025-04-11 08:10:28

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-dependencies

> 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.