563818 - Please provide an identifiable way for all named branches that are already released.

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect, P5)

Description

[Murali Nandigama [:murali]]

Here is the problem.

If I run 'hg branches' on say, 1.9.2. branch ... I get the following output

$ hg branches

default                    34167:9abae22747f5
GECKO1924_20100413_RELBRANCH 34166:4823974e174a
COMM1925_20100427_RELBRANCH 34153:233f6fe8d45e
COMM1925_20100422_RELBRANCH 34108:ea89c2dcc247
GECKO1925pre_20100414_RELBRANCH 34084:e2b60cacdf3e
COMM192_20100302_RELBRANCH 33791:534ab9fb1b1b
GECKO1922_20100315_RELBRANCH 33784:de4aae5d060a
GECKO1921_20100126_RELBRANCH 33772:3319b9ba2a4e
COMM192_20100119_RELBRANCH 33612:551a0b06dd2c
GECKO192_20100105_RELBRANCH 33607:4bd1755a1619
GECKO192_20091230_RELBRANCH 33465:5ddc5265569e
GECKO192b5_20091204_RELBRANCH 33331:f2093504a56b
GECKO192b4_20091124_RELBRANCH 33146:f0bddcf1c5d3
GECKO192b3_20091115_RELBRANCH 32959:371f864893e6
GECKO192b2_20091108_RELBRANCH 32829:600eaa990173
GECKO192b1_20091014_RELBRANCH 32662:fff9ebf58957
GECKO192b1_20091015_RELBRANCH 32560:dfa77b6d1883
GECKO192a2_20090915_RELBRANCH 31818:73205b1995c5
GECKO192a1_20090806_RELBRANCH 31198:dc02eff6d8c0
GECKO191b2_20081125_RELBRANCH 25666:b42a1594f613
FENNEC_A1_BRANCH           20482:cab97aca485d
GECKO191b1_20081007_RELBRANCH 20102:c4ebfef7afa6
scalable_gc_free_lists_378918 15492:76caed42cf7c (inactive)


Among these named branches, some are still relevant, in the sense that any changes checked into 1.9.2 branch [ default ] have to propagate to those named branches as well.

The rest of the named branches belong to already "out of the gate" builds.

I would like to know from the branch name , if it is already released or still relevant for back-port landings.

May I propose some thing like 

GECKO192b2_20091108_RELBRANCH 32829:600eaa990173 ( released ) for all named branches that belong to a released build


Thanks
Murali

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

AIUI the '( inactive )' on scalable_gc_free_lists_378918 is done by marking the branch closed with hg, and so '( released )' isn't possible. We could close branches which have released, but may have to reopen them again for a chemspill release. Sometimes branches are also shared, eg SeaMonkey doing a release off the same relbranch that Firefox used. So inactive may not be as reliable an indicator as you want.

In general only the most recent relbranch is relevant. It sounds like you want a programmatic way to determine this. Can I ask what that's for ? Perhaps we can approach the problem from another direction.

Comment 2

[LegNeato]

I think once we don't need branches we should close them (assuming the closing isn't super involved). There is no reason to keep them open once a newer one has shipped. For example, when we ship GECKO1924_20100413_RELBRANCH we close GECKO1923_*, etc.

It would be nice to have a handy webtool for release drivers to manage this sort of thing (if we go this direction).

Comment 3

[LegNeato]

Of course, that means we will have the latest released branch as well as the branch currently in development (per project), but I think that's better than the current situation.

Also, I don't believe other projects land anything on relbranches that aren't their own (and if they do it should be stopped). If closing a branch prevents tagging or branching from it then we can't close older releases as completely ignore comment 2.

Comment 4

[Murali Nandigama [:murali]]

> Can I ask what that's for ? Perhaps we
> can approach the problem from another direction.

Here is the relevant back ground. 

I am in the process of writing a "backportChecker" application which runs every 12 hours on a specific branch, identifies all landings and generates a list of all landed files and the bugs associated with those landed files.

After that I want to programmatically determine [using "hg branches" command and parsing the resulting output] what are relevant active named branches and make sure that these landings on the branch also propagated to the named branches. If not, shoot a mail to the DEV  whose changes have not landed on all relevant branches.

In order to do this, I can not simply presume that latest RELBRANCH is the relevant branch. That RELBRANCH may have been already released yesterday and since there is not other planned release now, it stays as the latest. 

So, I need one of these three mechanisms. 

1) My original request 
2) A BRANCHES-README.txt file at the branch ROOT level which contains all the 'hg branches' output with keywords next to them saying current / closed / released / inactive etc.
3) You would always have a latest named-branch  that would always be relevant and only be relevant in addition to [ default ]

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Lots to respond to there, but perhaps it's useful to take a step back.

If we ignore COMM* branches used by Thunderbird/SeaMonkey, then the scenarios are
* we shipped the 1.9.2.x, and 1.9.2.x+1 is a scheduled release
 ** build1 will come from default, no backports to check
 ** build2 etc will come from the relbranch created for build1, we should check backports between default and the relbranch
* 1.9.2.x+1 is a chemspill and we reuse the relbranch for the previous release, we should check for backports

I played around with hg a little. Closing a branch is a simple as 
   hg up -r <BRANCH>
   hg commit -m "some message" --close-branch
The branch is reopened by a later checkin, without a warning on checkin or push, which is a shame as I'd been hoping that we could prevent accidental checkins to relbranches. Anyway, we could probably close a relbranch immediately after a buildN, or the final release, to keep the branches list down. The backport checker could exit early if there are no active named branches, and as soon as the first change for a relbranch lands it'll have something to do. This misses the case where someone forgets to land on the relbranch before someone remembers, if you get my drift.

Have you thought about how you're going to handle test and other NPOTB landings on default that needn't propagate to the relbranch ? What about patches which are approved for 1.9.2.x+2 which land on default but shouldn't land on the relbranch for 1.9.2.x+1 ? We had a few of those between Fx 3.6.4 build1 and build2 and it made diffing default and the relbranch a pain, even though that's the strongest check. Are we going to ensure the same patch lands on default and relbranch ?

Re shared relbranches, there was a case around Firefox 3.6rcN/Fennec 1.0 where the relbranch was changing in 'interesting' ways. Also SeaMonkey (and possibly Thunderbird) use the same release automation as Firefox, so their tagging changesets end up on Firefox (Gecko) relbranches when they co-release. Now that their main codebase is in another repo we don't see their version bumps or other changes like we did for CVS.

Comment 6

[Murali Nandigama [:murali]]

How difficult it would be [ administratively ] to maintain a ROOT level branches-readme.txt to explain what are the expired named branches ? This would help in more than one way for retrospective.

Comment 7

[[e-mail] (:bhearsum)]

There's no clear plan either, but regardless this is low priority.

Comment 8

[Murali Nandigama [:murali]]

Ben, there is a great upshot in creating automated tools that periodically check the landings on default branches and make sure they are propagated to relevant open named-branches that are spawned out of the default branch. With the current way named branches are, knowing what are relevant named-branches is mostly an insider-information to few people that are in the know. 

However, as you said , it may not be a higher level priority considering other issues on the RE plate.

Comment 9

[Aki Sasaki (not active)]

Do you still need this Murali?

Comment 10

[Murali Nandigama [:murali]]

If provided, we can write a cool tool that would identify code landing mishaps in named branches that are relevant.

Comment 11

[Serge Gautherie (:sgautherie)]

Ftr, see bug 640510 about closing old branches.

Comment 12

[[e-mail] (:bhearsum)]

I haven't seen anyone wanting this in over a year -> INCOMPLETE