Re: Git Debug Branch

From: Robert Ramey (ramey_at_[hidden])
Date: 2025-04-10 23:29:19

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