Hi Ludovic,
Ludovic Courtès <l...@gnu.org> wrote:
> Mark H Weaver <m...@netris.org> skribis:
>
>> Hmm, good point. Perhaps we should postpone the Bash fix until the next
>> core-updates cycle. [...]
>
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it on the next cycle.
> That would allow us to merge ‘core-updates’ more quickly for sure!
Okay, let's delay the bash fix until the next cycle.
>> I tagged 'wip-binaries' and merged it into master, but there's an
>> undesirable side effect. After the merge, "git describe" from 'master'
>> now returns "bootstrap-20190815-222-g32e18e9b94".
>
> I think that’s OK.
>
> Ideally, we’d have mentioned the commit used to build the binaries in
> the commit that actually adds those binaries to boostrap.scm.
Agreed, that was an important omission on my part.
> Maybe that can still be done with a Git graft?
I think it's easier than that. I personally see no need to preserve the
branch 'core-updates-next', which has a different role than usual and is
arguably misnamed. It's only 3 commits. Of those 3, one has a faulty
commit log, and another should be postponed. I could simply push the
revised commits to 'core-updates' directly.
What do you think?
Mark
