Page MenuHomePhabricator

Removal of EOL release branches broke SemanticMediaWiki CI
Closed, ResolvedPublic

Description

Starting with [0] our integration with Travis is broken (compared to [2]) because someone thought that cleaning branch release tags [2] seems like a "good" idea. I'd like to ask the responsible person to restore those tags (REL1_19 ... ) as external users like us depend on a stable infrastructure and arbitrary changes to github as the one above causing unnecessary maintenance burden and developer time (like now writing this issue) for a volunteer project.

Not only is this breaking master repositories but also back-port release branches that rely on a functioning Travis integration.

PS: To anyone with the "Why don't you use release tags?" question, we run tests on the latest patch release and there are automatically fetched with the branch tag (aka REL1_23 ... REL1_29) without having to modify the Travis setup for a variety of repositories (+15) each time a new patch is released.

[0] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/builds/296134316
[1] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/builds/294740916
[2] https://user-images.githubusercontent.com/1245473/32325978-7c4099b4-c014-11e7-866f-b2f88bfb46f5.png

Event Timeline

that was @demon in T92503: Remove EOL MediaWiki release branches i believe.

I'm just back from vaction, and now this! Who is going to fix this [0]? I don't think you expect me to do it right!

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/2794#issuecomment-341878397

Which unsupported branches are you currently testing against? Based on https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/builds/296134316 it looks REL1_23, REL1_25, REL1_26, and REL1_28. Is that correct?

REL1_28 still exists, so that's not a problem. REL1_25 & REL1_26 saw last releases a year ago, and REL1_23 this year. I've created all 3 branches for now based off of the latest release tag to unbreak things for now.

Deleting most of the super old branches was a good idea to unclutter things, but I don't think it was anyone's intention to break anything. Maybe only deleting branches that haven't had a release in the past 1-2 years would work? Also for EOL branches that won't see anymore releases, you should probably switch to the last tag since nothing is going to get backported anymore (1.28 is a separate discussion that I'll file a ticket for).

Legoktm renamed this task from Removed branch tags on github breaks Travis integration! to Removal of EOL release branches broke SemanticMediaWiki CI.Nov 4 2017, 11:12 PM

tl;dr: Sorry about the breakage! We did not mean to inflict that pain on you (hard for us to know as it's a CI outside of our CI). Please don't assume malice what can be easily be unintentional.

I've created all 3 branches for now based off of the latest release tag to unbreak things for now.

Thanks Kunal!

Deleting most of the super old branches was a good idea to unclutter things, but I don't think it was anyone's intention to break anything.

It is never our intention to break anything (or, if it is, you'll know it because we warned you ;) )

Maybe only deleting branches that haven't had a release in the past 1-2 years would work? Also for EOL branches that won't see anymore releases, you should probably switch to the last tag since nothing is going to get backported anymore (1.28 is a separate discussion that I'll file a ticket for).

Given that ^ is going to be a separate task, is there anything left for us to do here?

I filed:

On the MediaWiki/releng side I think we need to determine how long after a release goes unsupported before the branch will be deleted, and we can document it in the release checklist.

On the MediaWiki/releng side I think we need to determine how long after a release goes unsupported before the branch will be deleted, and we can document it in the release checklist.

to get the ball rolling proposal: Day of EOL OR 1 month after the last point release, whichever is greater.

The day of EOL is too soon - if something went wrong with the latest release and we need to issue fixes for regressions we need the branch. I was thinking more like a year or two after EOL. One of my other ideas was just to revisit this issue again 10 years from now and do another massive clean up then :-)

It is an extra effort for volunteer driven projects to change all the numerous testing setups (REL to tag) every time an EOL is reached just to get the very same code in. Thus I think that retaining the branches longer for volunteer projects appears not too be much of a burden. At SMW we are talking about 15+ repos.

I was thinking more like a year or two after EOL.

That should probably be fine. Let's go with a year? There shouldn't be much use of an EOL'd release a year (2 new releases time) after it's gone EOL in many places/CIs around the net.

demon triaged this task as Medium priority.Jan 12 2018, 10:57 PM

I was thinking more like a year or two after EOL.

That should probably be fine. Let's go with a year? There shouldn't be much use of an EOL'd release a year (2 new releases time) after it's gone EOL in many places/CIs around the net.

Where should we document this?

Where should we document this?

Closest I can come up with is https://www.mediawiki.org/wiki/Release_checklist as it mentions announcing eol.
Obviously requires folks to be aware of that page and follow that page.

hashar assigned this task to Legoktm.
hashar subscribed.

The issue surfaced when we deleted the old release branches which was done via T92503. The branches then got restored by @Legoktm which effectively fixed this task. Hence I am marking it resolved.

We currently have:

origin/REL1_23
origin/REL1_25
origin/REL1_26
origin/REL1_27
origin/REL1_28
origin/REL1_29
origin/REL1_30
origin/REL1_31
origin/REL1_32
origin/REL1_33
origin/REL1_34
origin/REL1_35
origin/REL1_36

It implies we are no more deleting release branches. Then once a version is end of life, there is little need in running tests for them and downstream users should indeed remove their hardcoded values, but I digress.

Whether we should delete old branches is tracked by T188084.