Re: Updating to latest Bioconductor release

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> (You mean wip-r, right?)

Oof, yes, of course :)

>> Many of the commit messages were incomplete (didn’t mention all changed
>> inputs) and used the wrong heading “gnu: Update r-foo to 1.2.3.” instead
>> of the more greppable “gnu: r-foo: Update to 1.2.3.”.
>
> Just to understand for the next time: when should the commit upgrading
> the %bioconductor-version be done?  First one or last one?
>
> (I am speaking of this kind of commit: 
> ac6a55e68a6ed675a55abc5339f776613648cb9d)

It doesn’t really matter; usually I do this first, so that for all
following commits the fallback URL is going to be the correct new URL.
I haven’t thought much about this, so there may be reasons involving
“guix time-machine” that are for or against that position.

It should, in my opinion, be done together with the other change to the
version string.

>> I also saw that r-rsubread fails to build.
>
> That's the thing where I do not understand the concept of WIP branch
> if it is not possible to rewrite history.
>
> Only one commit should do the fix. now
> e57bf84eb80d6ad23710f2cad3d4fdb44ce1aca5 updates but fails.  How to
> proceed without adding another commit ending to master?  Is the fix
> added to wip-r and then before rebase to master, do the local rebase
> (with reorder and squash) and push?  I am sorry if my question about
> the Git workflow is naive, I am not used to work such way. :-)

We can and should rewrite history in the wip-r branch.  So if you have a
fix you can add a new commit on top of wip-r branch and mark it so that
someone later can reorder and squash it before the merge into the master
branch.

To avoid stepping on each other’s toes we should be adding commits to
the top and then agree on a freeze to reorder and squash those commits
in the end.

-- 
Ricardo