[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 12 Oct 2020 15:53:27 -0400
On Oct 12, 2020, at 15:37, Jonas Hahnfeld <firstname.lastname@example.org> wrote:
> Am Montag, den 12.10.2020, 08:19 -0400 schrieb Dan Eble:
>> On Oct 12, 2020, at 02:21, Jonas Hahnfeld <email@example.com> wrote:
>>> Am Sonntag, den 11.10.2020, 12:12 -0400 schrieb Dan Eble:
>>>> I can see, after the fact, a merge from release/unstable into master that
>>>> updated the version. I guess I need to check the release/unstable branch
>>>> before I merge an MR with new regression tests to master. Is that right?
>>> Yes, . . .
>> Is there any possibility to tweak this process so that regular contributors
>> to master don't have to monitor a separate branch?
> If this is of concern to you, please propose something that would work
> for you and get feedback from Phil. While I happen to be involved, it's
> eventually not me who builds and tags the releases.
> Personally I don't see much harm in moving a few issues and MRs across
> milestones from a short period of "contention". It causes some
> additional notification emails, but not more than other activity does.
I'm not too bothered by it, but I mentioned it because in the distant past, I
received disapproving feedback after pushing a patch with a regression test
using a \version which was correct at the time of review, but not at the time
of the push.
I don't regard my experience with git as sufficient to propose anything.