616499 - Contribute reorg-tools

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Gervase Markham [:gerv]]

[This bug is to suggest a b.m.o. customization/fix for upstreaming. If it is approved, I will create and attach a proper patch.]

We wrote a number of command-line tools for the last big Bugzilla reorg 2 years ago. They are in contrib/reorg-tools in the bmo repository. They do useful things like:

- syncing flags between products
- syncing milestones and versions between products
- moving components from one product to another
- fixing queries after components have been renamed

We should put them in Bugzilla's contrib/ directory, with appropriate READMEs and warnings about possibly being out-of-date.

Gerv

Comment 1

[Max Kanat-Alexander]

I'll take them in contrib, sure, but they have to work against trunk.

Comment 2

[Max Kanat-Alexander]

Although I wonder, maybe instead they should be the start of an extension called Reorganize?

Comment 3

[Frédéric Buclin]

(In reply to comment #2)
> Although I wonder, maybe instead they should be the start of an extension
> called Reorganize?

I don't think so. At least the last two items could make it in the core code.

Comment 4

[Gervase Markham [:gerv]]

mkanat: once people contribute things to /contrib, neither they nor the Bugzilla team are required to keep them working with later versions of Bugzilla, right?

If that's true, then aren't you basically saying that if we'd contributed this code two years ago, it would be fine sitting as-is in the /contrib directory now, but today it's not allowed to have exactly the same code sitting in the same place?

I think this code, even if it only was tested against 3.4, would be much more useful than nothing to people who wanted to do some of these same things in their Bugzilla. 

Gerv

Comment 5

[Frédéric Buclin]

(In reply to comment #4)
> I think this code, even if it only was tested against 3.4, would be much more
> useful than nothing to people who wanted to do some of these same things in
> their Bugzilla. 

Intentionnally adding a broken script is bad. I would go even further, and say that unmaintained and broken scripts in contrib/ should go away if not fixed in a timely manner. We cannot afford to break an installation just because we are lazy to fix scripts, or because nobody understsands how a script works.

Comment 6

[Gervase Markham [:gerv]]

The entire point of contrib/, as I understand it, is that the code is contributed by outside parties, not reviewed, not necessarily working, and is "use at your own risk". If we start applying the same rules to contrib/ as we do to the rest of Bugzilla, we might as well just say it's all part of the core.

The README in the contrib/ folder even says this:

"This directory contains contributed software related to Bugzilla. Things in here have not necessarily been tested or tried by anyone except the original contributor, so tread carefully.  But it may still be useful to you. Read the files themselves for detailed usage information on any specific script."

If an admin doesn't understand a script in contrib/, they should not be running it. The description above seems to fit the reorg-tools well.

Gerv

Comment 7

[Max Kanat-Alexander]

Hey Gerv. I see where you are coming from, but I don't want to ship broken code with Bugzilla. It will cause more trouble for most people than it will help people. I'm more or less with LpSolit and would possibly even support removing broken things from contrib/ if they've been broken for a long time and nobody's stepping up to do anything about them.

We do offer lighter review guidelines on contrib/ stuff, if you're wondering what the difference would be between it and core.

Comment 8

[Gervase Markham [:gerv]]

Well, they aren't going to get updated until we need them again. :-| So instead, I've added a reference to them on https://wiki.mozilla.org/Bugzilla:Addons#Server-side_Utilities .

Gerv