Bug #10714

"testing" branch is always seen as active by Jenkins

Added by intrigeri 2015-12-05 14:48:25 . Updated 2016-03-08 19:03:15 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.2
Start date:
2015-12-05
Due date:
% Done:

100%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

… because it has commits on top of stable, currently:

  • commit:36461295f860e341e03e7e4d4ed0a792fda64f89 <— anonym, I can’t find in our release process what makes us do that after releasing something based on testing; any hint?
  • commit:453f5da4924ee8b01f29eb86cb6076b2a2455d10 <— bertagaz, same question as above
  • commit:8cc9c3dd93a9fe39392495e9bba749bbe21034be <— bertagaz, same question as above

The effect is that our Jenkins setup tries to build testing, which is unmaintainted except during freezes, and as a result release managers are constantly and needlessly spammed.

Subtasks

History

#1 Updated by intrigeri 2015-12-05 14:48:53

  • Assignee set to bertagaz
  • Target version set to Tails_2.0

There are questions for anonym and bertagaz in there, let’s start with bertagaz :)

#2 Updated by bertagaz 2015-12-07 02:44:44

  • Assignee changed from bertagaz to anonym

intrigeri wrote:
> There are questions for anonym and bertagaz in there, let’s start with bertagaz :)

I think that’s the result of the 1.7 release timing vs the fragile tagging. We didn't manage to make it before the release. Not sure modifying testing was relevant though, guess the point was to have it in sync about the fragile tags. It’s a bit old and blurry in my memory by now. :/

One of my commit is fixing the badly configured config/base_branch file.

Assigning it to anonym to get its input now.

#3 Updated by intrigeri 2015-12-07 03:15:45

  • Target version changed from Tails_2.0 to Tails_2.2

> I think that’s the result of the 1.7 release timing vs the @fragile tagging.

I assume you’re talking of commit:453f5da4924ee8b01f29eb86cb6076b2a2455d10 here since the other is mentioned below. FTR I don’t think we should merge stable into testing ever outside of freeze times (otherwise it triggers the bug this ticket is about), hence my question.

> One of my commit is fixing the badly configured config/base_branch file.

Yes (I read the diff before asking you what lead you to do it). In general it’s a good thing to do. In this case it’s clearly not, hence my question.

Whatever, it seems it’s too late to reverse-engineer why it happened, so I won’t insist.
We’ll live with this situation until January 25 anyway.

=> anonym, let’s follow the release process “to the rule” for 2.0, and we’ll see if this happens again post-2.0 release, OK?

#4 Updated by anonym 2016-01-27 15:34:56

intrigeri wrote:
> > I think that’s the result of the 1.7 release timing vs the @fragile tagging.
>
> I assume you’re talking of commit:453f5da4924ee8b01f29eb86cb6076b2a2455d10 here since the other is mentioned below. FTR I don’t think we should merge stable into testing ever outside of freeze times (otherwise it triggers the bug this ticket is about), hence my question.
>
> > One of my commit is fixing the badly configured config/base_branch file.
>
> Yes (I read the diff before asking you what lead you to do it). In general it’s a good thing to do. In this case it’s clearly not, hence my question.
>
> Whatever, it seems it’s too late to reverse-engineer why it happened, so I won’t insist.
> We’ll live with this situation until January 25 anyway.
>
> => anonym, let’s follow the release process “to the rule” for 2.0, and we’ll see if this happens again post-2.0 release, OK?

I had not seen this ticket until now, and, sorry, I did the same non-standard merge dance again for Tails 2.0. In my mental model, which so far has excluded this part of the Jenkins setup, doing what I do makes sense since it ensures that all branches are pair-wise conflict-free. Any way, I get the problem now, and promise to follow the instructions to the point next time, but I guess we’ll have to live with this until the 2.2 freeze, around February 25. :/

#5 Updated by anonym 2016-01-27 17:04:22

anonym wrote:
> […] I guess we’ll have to live with this until the 2.2 freeze, around February 25. :/

Actually, I just did the merge commit:c947fa61 which should fix this now.

#6 Updated by anonym 2016-02-11 23:34:30

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100

Seems to work, there’s no build_Tails_ISO_testing job. Closing!

#7 Updated by anonym 2016-03-08 19:03:15

  • Status changed from Fix committed to Resolved