Bug #17557

“Update other base branches” feels wrong

Added by CyrilBrulebois 2020-03-26 00:53:00 . Updated 2020-03-26 17:35:43 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Following the release process for 4.5~rc1, I’m not sure this is right:

Update other base branches
==========================

1. Merge the release branch into `devel` following the instructions for
   [[merging base branches|APT_repository/custom#workflow-merge-main-branch]].

since testing is a few commits ahead of devel:

Update PO files.
Restore testing's base branch.
Freeze APT snapshots for 4.5~rc1.

and merging testing in there would result in a freeze of packages in the devel branch?!

Subtasks

History

#1 Updated by CyrilBrulebois 2020-03-26 00:54:49

It seems to me the whole section should be skipped when preparing a release candidate.

I’ll block on a confirmation before proceeding any further.

#2 Updated by intrigeri 2020-03-26 08:22:40

  • Parent task set to Bug #17376
  • Type of work changed from End-user documentation to Contributors documentation

#3 Updated by anonym 2020-03-26 11:18:19

CyrilBrulebois wrote:
> Following the release process for 4.5~rc1, I’m not sure this is right:

It looks right to me; we always want devel to have all the good new stuff!

> merging testing in there would result in a freeze of packages in the devel branch?!

Yes, for a brief moment devel will have the frozen snapshots from testing, but the thawing in step two undoes that, and it’s done before you push in step 5, so the problem is fixed before it ever has a chance to manifest.

After the 4.5~rc1 is out we will base our bugfixes on testing, abd whenever they are merged into testing, we will also merge testing → devel. The thawing commit from step 2 will make this possible too.

#4 Updated by CyrilBrulebois 2020-03-26 12:15:16

So we freeze testing which we merge into devel only to unfreeze it right afterwards?

The only thing we get into devel by doing this double dance is updating PO files. Why don’t we do that in devel first, and then fork testing once and for all?

#5 Updated by anonym 2020-03-26 12:56:56

CyrilBrulebois wrote:
> So we freeze testing which we merge into devel only to unfreeze it right afterwards?

Yes.

> The only thing we get into devel by doing this double dance is updating PO files. Why don’t we do that in devel first, and then fork testing once and for all?

This way we can always merge bugfixes → testing and then merge testing → devel so we have the fixes in devel too. What would we gain from keeping testing and devel properly forked?

#6 Updated by CyrilBrulebois 2020-03-26 17:35:43

  • Status changed from Confirmed to Rejected
  • Assignee deleted (anonym)

Well, that’s just not what I was expecting, and having stopped at the first step, I didn’t go as far as seeing the back and forth that was coming up. To answer your question, I’d guess “clarity for baby RMs”, which is likely not a good reason.

Closing, thanks for the check/explanation.