243652 - Remove all unused tinderbox trees

Status: RESOLVED FIXED

(Webtools Graveyard :: Tinderbox, enhancement, P2)

Description

[Bryan]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: 

Hi,
The 1.0 tinderbox should br removed since there will be no more develpoment on 
it. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Mozilla 1.0.2 has been released. a long time ago.

Comment 1

[Bryan]

[e-mail] should look at this.

Comment 2

[timeless]

what do you mean?

how do you know there will be no more development on it?

Comment 3

[timeless]

ok. while the reporter was very vague, i finally figured out what he meant.

i'd be willing to write code to hide tinderboxes. i don't see much reason to 
delete things (nor can i)...

Comment 4

[Chris McAfee]

why does code need to be written?  Isn't this just .. turning off the
clients and removing the old data?

Comment 5

[timeless]

1.0 doesn't have any clients, but you might want to prevent people from 
resurrecting the tinderbox, and i could only write code to hide a tinderforest 
as i don't have access to the tinderbox server...

Comment 6

[Chris McAfee]

I think this bug thread is about an access/deny list mechanism,
if so let's resummarize this.  I agree, you will want to kill off
projects (tinderboxes) and you're also gonna want to have some
control over which tinderboxes show up where.

Comment 7

[Dave Miller [:justdave]]

see also bug 243651

Comment 8

[Dave Miller [:justdave]]

I'd be in favor of dumping all the data, too, if we don't need it anymore. 
Mecha's starting to get a bit shy on disk space again, and 90% of the data on
that drive belongs to Tinderbox.

Comment 9

[Bryan]

It is not used anymore.

Comment 10

[timeless]

bryan: see the problem is that there are two products involved:

tinderbox (available in versions 1, 2 and 3)
mozilla (available in versions 1.0, 1.4, 1.5, 1.7, ...)

I couldn't tell at first glance that you meant killing a consumer of tinderbox 
instead of the actual server.

Comment 11

[Bryan]

Hi, 
I am talking about just removing that tinderbox.
Not all of them on that server.

Comment 12

[Dave Miller [:justdave]]

Justin is now the QA for this component.

Comment 13

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 14

[J. Paul Reed [:preed]]

Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to [e-mail] reflects reality.

If there is a bug you really think we need to be looking at, please *email* [e-mail] with a bug number and explanation.

Comment 15

[Chris Cooper [:coop] (he/him)]

Morphing bug into a general clean-up bug.

justdave: is there a way to remove outdated trees from the list displayed by showbuilds.cgi?

Here's the list that I would consider removing:

# Aviary-1.0
# Aviary-1.0.1
# BlueBird
# Browser
# Firefox-1.0
# Firefox-Cairo
# Mozilla1.0
# Mozilla1.4
# Mozilla1.5
# Mozilla1.6
# Mozilla1.7
# MozillaTree
# Phoenix
# SeaMonkey-Branch
# SeaMonkey-Embed
# SeaMonkey-Embedding-Branch
# SeaMonkey-OEM
# SeaMonkey-Testerbox
# Testing
# XULRunner-Mozilla1.8.0

Comment 16

[Reed Loden [:reed]]

(In reply to comment #15)
> justdave: is there a way to remove outdated trees from the list displayed by
> showbuilds.cgi?

Sure. You can delete the directories on the server (and from one of the files, I think).

Comment 17

[Chris Cooper [:coop] (he/him)]

I'd like someone to verify my list too before this happens.

Comment 18

[Reed Loden [:reed]]

The "Testing" tinderbox is currently being used by Sun (http://tinderbox.mozilla.org/Testing/). Probably should leave it alone.

Comment 19

[Dave Miller [:justdave]]

Yeah, only way I know to remove them right now is to delete their directory.  I'm pretty sure stuff older than X number of days already gets nuked anyway, so if nothing's been posted to a tree in longer than that (I think X is either 14 or 30 depending on the tree), there's likely nothing there to lose anyway.

Comment 20

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #17)
> I'd like someone to verify my list too before this happens.
> 
Do we still have to manually review and remove the directories listed above, or are they automatically aging off?

Comment 21

[Chris Cooper [:coop] (he/him)]

John: the directories might be getting culled on the server (I don't know), but all the listed trees still appear in http://tinderbox.mozilla.org/showbuilds.cgi

Comment 22

[Dave Miller [:justdave]]

The following trees currently have no data in them within the active data retention window (which is somewhere between 7 and 30 days depending on the tree)

BlueBird
Browser
Firefox-1.0
Firefox-Cairo
MiniMo
Mozilla1.0
Mozilla1.4
Mozilla1.5
Mozilla1.6
Mozilla1.8.0-l10n-template
Mozilla1.8-l10n-bn-IN
Mozilla1.8-l10n-fa
Mozilla1.8-l10n-hi-IN
Mozilla1.8-l10n-ml
Mozilla1.8-l10n-ne-NP
Mozilla1.8-l10n-rw
Mozilla1.8-l10n-sr
Mozilla1.8-l10n-ta
Mozilla1.8-l10n-template
Mozilla-l10n-ast-ES
Mozilla-l10n-bn-IN
Mozilla-l10n-ca-AD
Mozilla-l10n-cs-CZ
Mozilla-l10n-cy-GB
Mozilla-l10n-da-DK
Mozilla-l10n-de-DE
Mozilla-l10n-el-GR
Mozilla-l10n-en-ZA
Mozilla-l10n-eu-ES
Mozilla-l10n-fa
Mozilla-l10n-fi-FI
Mozilla-l10n-fr-FR
Mozilla-l10n-he-IL
Mozilla-l10n-hi-IN
Mozilla-l10n-hu-HU
Mozilla-l10n-it-IT
Mozilla-l10n-ja-JP
Mozilla-l10n-ja-JPM
Mozilla-l10n-ko-KR
Mozilla-l10n-mk-MK
Mozilla-l10n-ml
Mozilla-l10n-ne-NP
Mozilla-l10n-nl-NL
Mozilla-l10n-pl-PL
Mozilla-l10n-ro-RO
Mozilla-l10n-ru-RU
Mozilla-l10n-rw
Mozilla-l10n-sk-SK
Mozilla-l10n-sl-SI
Mozilla-l10n-sq-AL
Mozilla-l10n-sr
Mozilla-l10n-ta
Mozilla-l10n-tr-TR
MozillaRelease
Phoenix
SeaMonkey-Branch
SeaMonkey-Embed
SeaMonkey-Embedding-Branch
SeaMonkey-OEM
XULRunner-Mozilla1.8.0

Comment 23

[Reed Loden [:reed]]

(In reply to comment #22)
> Mozilla1.8-l10n-bn-IN
> Mozilla1.8-l10n-fa
> Mozilla1.8-l10n-hi-IN
> Mozilla1.8-l10n-ml
> Mozilla1.8-l10n-ne-NP
> Mozilla1.8-l10n-rw
> Mozilla1.8-l10n-sr
> Mozilla1.8-l10n-ta
> Mozilla1.8-l10n-template
> Mozilla-l10n-ast-ES
> Mozilla-l10n-bn-IN
> Mozilla-l10n-ca-AD
> Mozilla-l10n-cs-CZ
> Mozilla-l10n-cy-GB
> Mozilla-l10n-da-DK
> Mozilla-l10n-de-DE
> Mozilla-l10n-el-GR
> Mozilla-l10n-en-ZA
> Mozilla-l10n-eu-ES
> Mozilla-l10n-fa
> Mozilla-l10n-fi-FI
> Mozilla-l10n-fr-FR
> Mozilla-l10n-he-IL
> Mozilla-l10n-hi-IN
> Mozilla-l10n-hu-HU
> Mozilla-l10n-it-IT
> Mozilla-l10n-ja-JP
> Mozilla-l10n-ja-JPM
> Mozilla-l10n-ko-KR
> Mozilla-l10n-mk-MK
> Mozilla-l10n-ml
> Mozilla-l10n-ne-NP
> Mozilla-l10n-nl-NL
> Mozilla-l10n-pl-PL
> Mozilla-l10n-ro-RO
> Mozilla-l10n-ru-RU
> Mozilla-l10n-rw
> Mozilla-l10n-sk-SK
> Mozilla-l10n-sl-SI
> Mozilla-l10n-sq-AL
> Mozilla-l10n-sr
> Mozilla-l10n-ta
> Mozilla-l10n-tr-TR
> MozillaRelease

We still support the trunk and 1.8, plus MozillaRelease is used by build, so the above trees might want to stay.

> Mozilla1.8.0-l10n-template
> XULRunner-Mozilla1.8.0

These can be chucked when we mothball 1.8.0.

I'd say kill everything else.

Comment 24

[Robert Kaiser]

A collection of the Mozilla-l10n-* trees listed here are indeed obsolete due to the changes to simpler (shorter) locale codes we have done, e.g. Mozilla-l10n-de-DE has been replaced by Mozilla-l10n-de, IIRC, even already when we were working towards 1.8 - and the mentioned trees with "SeaMonkey" in their names can all be killed, only Mozilla1.8-SeaMonkey, SeaMonkey-Ports and SeaMonkey are still active (Mozilla1.8.0-SeaMonkey is also unused now).

Comment 25

[Chris Cooper [:coop] (he/him)]

Dave: Your list is good. We've explicitly turned off the XULRunner 1.8.0 tinderboxes months ago. As Reed mentioned, the only tree we need to keep is MozillaRelease. The rest can be removed at your leisure.

(In reply to comment #22)
> BlueBird
> Browser
> Firefox-1.0
> Firefox-Cairo
> MiniMo
> Mozilla1.0
> Mozilla1.4
> Mozilla1.5
> Mozilla1.6
> Mozilla1.8.0-l10n-template
> Mozilla1.8-l10n-bn-IN
> Mozilla1.8-l10n-fa
> Mozilla1.8-l10n-hi-IN
> Mozilla1.8-l10n-ml
> Mozilla1.8-l10n-ne-NP
> Mozilla1.8-l10n-rw
> Mozilla1.8-l10n-sr
> Mozilla1.8-l10n-ta
> Mozilla1.8-l10n-template
> Mozilla-l10n-ast-ES
> Mozilla-l10n-bn-IN
> Mozilla-l10n-ca-AD
> Mozilla-l10n-cs-CZ
> Mozilla-l10n-cy-GB
> Mozilla-l10n-da-DK
> Mozilla-l10n-de-DE
> Mozilla-l10n-el-GR
> Mozilla-l10n-en-ZA
> Mozilla-l10n-eu-ES
> Mozilla-l10n-fa
> Mozilla-l10n-fi-FI
> Mozilla-l10n-fr-FR
> Mozilla-l10n-he-IL
> Mozilla-l10n-hi-IN
> Mozilla-l10n-hu-HU
> Mozilla-l10n-it-IT
> Mozilla-l10n-ja-JP
> Mozilla-l10n-ja-JPM
> Mozilla-l10n-ko-KR
> Mozilla-l10n-mk-MK
> Mozilla-l10n-ml
> Mozilla-l10n-ne-NP
> Mozilla-l10n-nl-NL
> Mozilla-l10n-pl-PL
> Mozilla-l10n-ro-RO
> Mozilla-l10n-ru-RU
> Mozilla-l10n-rw
> Mozilla-l10n-sk-SK
> Mozilla-l10n-sl-SI
> Mozilla-l10n-sq-AL
> Mozilla-l10n-sr
> Mozilla-l10n-ta
> Mozilla-l10n-tr-TR
> Phoenix
> SeaMonkey-Branch
> SeaMonkey-Embed
> SeaMonkey-Embedding-Branch
> SeaMonkey-OEM
> XULRunner-Mozilla1.8.0

Comment 26

[Dave Miller [:justdave]]

OK, everything listed in comment 25 has been nuked.

Comment 27

[Dave Miller [:justdave]]

My method of detecting empty trees was flawed and missed a few.  Here's some additional ones I found:

Aviary1.0
Aviary1.0.1
Bugzilla2.16
Bugzilla2.18
Joey
Mozilla1.7
SeaMonkey-Testerbox

All of these except the Bugzilla ones and Joey were in Coop's original list, and I personally know that those two Bugzilla ones are no longer being used, so I've removed all of the above as well, except for Joey.

Comment 28

[Axel Hecht [:Pike]]

You killed a few l10n tinderboxens that you had just setup for locales that are currently in incubator. I didn't have the cycles to comment here earlier, that's what happens. Not sure why you dismissed Robert's comment 24, who's in our l10n community, and coop's list for granted.

I'll file new bugs to get those boxens recreated, hoping that it takes less than a quarter this time.

I'll probably add a few more boxens to the list of non-needed, though, as we're starting to WONTFIX locales for the branch.

Comment 29

[Chris Cooper [:coop] (he/him)]

(In reply to comment #28)
> You killed a few l10n tinderboxens that you had just setup for locales that are
> currently in incubator. I didn't have the cycles to comment here earlier,
> that's what happens. Not sure why you dismissed Robert's comment 24, who's in
> our l10n community, and coop's list for granted.

You'll notice my initial list was much condensed and didn't touch anything later than 1.8.0 or anything l10n. I figured (as I assume Dave did) that empty trees meant "not used."

Is there a reason these needed trees didn't have any files in them? Is there something broken on the build side that I should be looking at?

Comment 30

[Dave Miller [:justdave]]

(In reply to comment #28)
> I'll file new bugs to get those boxens recreated, hoping that it takes less
> than a quarter this time.

You can list them here if you want, it's damage as a result of this bug.  Also, because of the way I set them up last time I did them for you, there's not such a pain in the ass to do anymore, and I should be able to get them for you on a day or less turnaround.

Comment 31

[Dave Miller [:justdave]]

(In reply to comment #28)
> Not sure why you dismissed Robert's comment 24, who's in our l10n community

Didn't know I dismissed it.  Re-reading it again now, I still don't see anything he said in that comment that doesn't jive with what I actually did.  I kept the ones he said needed to be kept, and the ones he explicitly said were obsolete were on the list that got nuked.

Comment 32

[Axel Hecht [:Pike]]

The following locales need tinderboxens on the trunk again:

bn-IN, fa, hi-IN, kn, ml, mr, ne-NP, rw, si, sr, ta, te

This does not include the South African locales, which are not that much worked on right now, and I added Sinhala (si), which is going just for Firefox 3 now.

Long list. Some of them might actually still go for Firefox 2, too, so we'll need to create those boxens before we start building them on the branch.

Chofmann, can you sheppard those in on demand?

Comment 33

[Axel Hecht [:Pike]]

Reopening so that I can track dependent bugs for adding new localizations to the build.

Comment 34

[Dave Miller [:justdave]]

OK, so you want a Mozilla-l10n-ab(-CD) and a Mozilla1.8-l10n-ab(-CD) for each of those listed in comment 32?

Comment 35

[Axel Hecht [:Pike]]

I'm not sure how many of those will actually go onto 1.8 still, but trunk builds, yes. If it's one go, then "si" is the only one that's definitely not going on 1.8.

Sorry that I don't have more precise info on the 1.8 status, it's either a bunch too many today and on the safe side, or a few of them in a week or two.

Comment 36

[Dave Miller [:justdave]]

OK, I should have the non-1.8 ones up in a couple hours (would be up in the next 10 minutes except I have to split to take my kids somewhere right now, so it'll get done as soon as I get back).  I'll go ahead and wait for your sayso on the 1.8 ones.

Comment 37

[Dave Miller [:justdave]]

(In reply to comment #32)
> The following locales need tinderboxens on the trunk again:
> 
> bn-IN, fa, hi-IN, kn, ml, mr, ne-NP, rw, si, sr, ta, te

OK, the above ^ are live now.

Comment 38

[Axel Hecht [:Pike]]

We're having builds up on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-si, resolving FIXED again. We'll come up with new bugs for the follow up changes.