Integration into Trac

[Peter Suter]

Has there ever been a serious attempt at integrating this into Trac?

What would be the steps?

• License:
  • What's the licensing situation of this plugin? Is it compatible with Trac's license? gpl-license? That would be a showstopper. Do the authors and contributors want to relicense their code?
• Someone familiar with the plugin should prepare a series of patches for ​submitting to Trac.
  • Probably the first one should only contain a DB migration to add the project field?
  • And an admin panel to enable the use of that field?
  • Then one patch per important feature. What would those be?
• Then create a ​newticket.
• Most importantly someone familiar with the plugin has to be available over a longer period of time to push the effort forward by updating and adapting these patches.

[falkb]

Replying to Peter Suter:

• License:
  • What's the licensing situation of this plugin? Is it compatible with Trac's license? gpl-license? That would be a showstopper. Do the authors and contributors want to relicense their code?

Take whatever license is necessary to put the code of this plugin into official Trac, there shall not be a barrier about that.

[falkb]

Replying to Peter Suter:

• Then one patch per important feature. What would those be?

visible features:

• only show activities of certain projects in timeline: e.g. attachment/wiki/SimpleMultiProjectPlugin/timeline_projects_filter.png
• only show milestones and versions of certain projects on roadmap page: e.g. attachment/wiki/SimpleMultiProjectPlugin/roadmap_projects_filter.png
• only offer milestones and versions of the chosen project in newticket form
• only offer projects in newticket form which are not already closed
• hide all projects and their tickets, milestones and versions from users without permission to that projects

internal:

• a map of projects (project state: open/closed)
• a map which milestone belongs to which project
• a map which version belongs to which project
• a map which users and groups belong to which project (permission)

That's it. The plugin struggles with a custom ticket field "project". This would get a huge simplification if that ticket file is not a custom but a standard ticket field. I bet the code would reduce to at least 25% of the old code.

[Peter Suter]

Replying to falkb:

Take whatever license is necessary to put the code of this plugin into official Trac, there shall not be a barrier about that.

The authors / copyright owners will have to agree and change it to only use ​this license.

visible features:

Thanks for the overview!

The plugin struggles with a custom ticket field "project". This would get a huge simplification if that ticket file is not a custom but a standard ticket field. I bet the code would reduce to at least 25% of the old code.

I think it would be great if you could submit a series of patches to Trac that does exactly that.

[falkb]

Replying to Peter Suter:

The authors / copyright owners will have to agree and change it to only use ​this license.

I added crossroad to the CC list. He is the initial author. crossroad, please, agree as well. If crossroad doesn't comment here, we still have his email address (see his wiki page).

I think it would be great if you could submit a series of patches to Trac that does exactly that.

I don't have the knowledge about Trac to do that. Sorry about that. Somebody who is familiar with the Trac core should do that.

[Peter Suter]

I don't have the knowledge about Trac to do that. Sorry about that.

• ​db_default.py: Increment the db_version to 46 in line 20, add the Column('project') to the ticket table and add a new project table.
• ​upgrades/: Add a new file db46.py that looks similar to ​this, but adding the new column to the ticket table, and the new project table.
• ​admin.py: Copy one of the existing panels like e.g. ComponentAminPanel to ProjectAdminPanel and search / replace "component" -> "project".
• Similarly copy and adjust ​admin_components.html to admin_projects.html.
• ​model.py: Similarly copy and adjust the Component model to Project.
• Search the source for other occurrences of "component", e.g. in ​api.py and check if "project" should be handled similarly.
• ​Run all tests and write (or ​copy) new ones.

It's quite a bit of work but it shouldn't be that difficult.

[falkb]

First of all the core team must give the OK for this integration to prevent a shot in the dark if someone starts with that integration.

It always more seemed to me a multi-project solution based on multiple Trac instances (each one with its own trac.db) is desired.

[Peter Suter]

In #12373 Cinc-th proposed a plan to move to BSD license by rewriting all code. How far did that get?

First of all the core team must give the OK for this integration

I disagree. Working patches against Trac and a will to adjust them are the best way to successfully integrate plugins or big features into Trac. At least that's my experience with GitPlugin, BatchModifyPlugin, AnnouncerPlugin, etc.

[falkb]

Replying to Peter Suter:

First of all the core team must give the OK for this integration

I disagree. Working patches against Trac and a will to adjust them are the best way to successfully integrate plugins or big features into Trac. At least that's my experience with GitPlugin, BatchModifyPlugin, AnnouncerPlugin, etc.

There are two contrary approaches to add multi-project functionality to Trac.

• The main approach is that one which keeps 1 project per trac.db and puts all those Trac instances together in one meta-trac. It always indicates to me this is the one the main core developers go for.
• My approach is to still use just one trac.db and to add just another ticket field "project" for scaling the tickets with a new dimension project, which makes the other approach superfluously.

I never start things which just have a small chance to be integrated, this would just be a waste of my spare time. So I asked on the mailing-list and on IRC if anybody would support my attempt but got no or no positive reply. That is why I never started to integrate, and now I simply haven't got the time/will for it anymore.

[Peter Suter]

There are two contrary approaches to add multi-project functionality to Trac.

• The main approach is that one which keeps 1 project per trac.db and puts all those Trac instances together in one meta-trac. It always indicates to me this is the one the main core developers go for.
• My approach is to still use just one trac.db and to add just another ticket field "project" for scaling the tickets with a new dimension project, which makes the other approach superfluously.

Right. The old ​trac:TracMultipleProjects/MultipleEnvironments vs. ​trac:TracMultipleProjects/SingleEnvironment question. I personally think Trac should have a built-in (but optional) single-environment solution, with a project ticket field. The multiple environments approach is and can remain orthogonal to that. And I assume nobody in the Trac core team would be fundamentally opposed to that. (As long as it's optional and doesn't get too complex.)

I never start things which just have a small chance to be integrated, this would just be a waste of my spare time. So I asked on the mailing-list and on IRC if anybody would support my attempt but got no or no positive reply. That is why I never started to integrate, and now I simply haven't got the time/will for it anymore.

That's too bad, but I fully understand. Everyones spare time is precious. (I think in the Trac community "no reply" can often mean "nobody sees a problem with that, so go ahead". That's really unfortunate, but probably also a consequence of the limited spare time of volunteers.)

Feel free to close this ticket.

[falkb]

I leave it open as reminder if anyone else wants to do the porting

[Massimo]

This is our most important plugin, as we track all of our projects in one single Trac. So almost everything in our Trac is based on this plugin. The count of projects is increasing, some old projects are being retired but never removed. The current count of projects is 47. What is the current Trac core solution for that? Should we host 47 Trac instances with separate Wikis and all that?

Seriously, is there any plan to add Multi Project functionality to Trac? The implementation of SimpleMultiProjectPlugin is quite complete to do the job. Thanks falkb for that. I could provide testing efforts if you like to start some integration.

[Ryan J Ollos]

To implement MultiProject in Trac we need to start from scratch. This plugin implements a bunch of template filters that won't even work in the latest Trac release. It hacks multiproject into Trac, which isn't actually that useful for implementing MultiProject in the Trac core. That, and the code quality is very far from where it needs to be. Bloodhound has far more useful pieces that could be used if we were to go down the path of implementing MultiProject in Trac, which is 100's of hours effort. If it was easy, we would have done it already.

[falkb]

To add a ticket field "project" would solve 95% of all Needs. The rest are silly filters here and there, nothing which would be witch craft. I do not understand why 10 years can pass by without understanding this makes Trac unusuable for 90% of all companies.

[anonymous]

I agree integrating the code from this plugin is not the best approach. I would also not integrate Bloodhound. It seems like overkill. One can start very simply from scratch: ​trac:ticket:13024 has all the required patches to add a "project" field.

They were also rejected, with the reasoning that more discussion / design decisions are needed, but sadly this never happened.

Maybe because there is already consensus among the proponents that adding a simple project DB field alone would be enough? No concrete problems with this approach were ever mentioned anywhere, and there are no obvious problems or downsides. The silly / fancy frills can be left to plugins of course. We think this would clearly help many users of Trac and Trac plugins could grow enormously more useful.

So it is a bit unclear what needs to be discussed / designed / decided?

[falkb]

Replying to anonym:

Maybe because there is already consensus among the proponents that adding a simple project DB field alone would be enough? No concrete problems with this approach were ever mentioned anywhere, and there are no obvious problems or downsides. The silly / fancy frills can be left to plugins of course. We think this would clearly help many users of Trac and Trac plugins could grow enormously more useful.

The only "concrete problem" I know is people who just have 1 project have a new "useless" ticket field. But this is already true for most users with ticket field "component". I saw several sites using trac where the components field is not used or just treated very stepmotherly. Probably it makes sense to simply give the opportunity to redefine the field name "component" to "project" during Trac Installation.

So it is a bit unclear what needs to be discussed / designed / decided?

It's like everywhere in the Open Source world (and I've seen it in many KDE Projects I once was involved as well), it just depends on someone who has enough time and willing to integrate it. We once just had given 2 weeks by our boss to create SimpleMultiProjectPlugin and Trac still successfully runs here as production system for many projects in one Trac instance.

[Massimo]

Replying to Ryan J Ollos:

To implement MultiProject in Trac we need to start from scratch.

I'm not familiar with the code base, so here I trust you. But from user point of view I would agree the others that say, it's only a project field required, that filters versions and components, and some filtering on the timeline and milestones.

This plugin implements a bunch of template filters that won't even work in the latest Trac release.

I'm more upset about that sentence. I thought we have managed the biggest step with the migration from Genshi to Jinja2, where almost all templates and plugins were affected. Now reading that even the plugin will stop to work in some of the next upgrades, that would break our whole workflow that is based on projects. I would even say, this is our most important plugin. So here I would resign and take the wishes back to have something like this in the core, if just the plugin will stay maintained, regardless of the bad codebase.

Bloodhound has far more useful pieces that could be used if we were to go down the path of implementing MultiProject in Trac, which is 100's of hours effort. If it was easy, we would have done it already.

So far I didn't even read about Bloodhound or just skipped it in the beginning of evaluating Trac. Reading at ​http://bloodhound.apache.org/ the last update was 2014. Not much information, just that it supports Multiple Products which is equivalent to Multiple Projects. That all doesn't sound a good alternative to Trac itself, maybe the reason why I ignored that in the past. How does Bloodhound add the Multiple Products? It sounds like it was the main intention for starting that project, another additional reason emphasizing the importance of Projects/Products in a bugtracker.

[Massimo]

Replying to falkb:

Probably it makes sense to simply give the opportunity to redefine the field name "component" to "project" during Trac Installation.

Please not, we still have components. And if not I would not have a problem using the components in a project context without renaming it... I think the mapping product|project → component|module → feature|bug where product is equivalent to project and feature is equivalent to the ticket itself, is the most basic hierarchy of any team, even the 1-man developer having 2 shell scripts published.

We once just had given 2 weeks by our boss to create SimpleMultiProjectPlugin and Trac still successfully runs here as production system for many projects in one Trac instance.

You are the main author of the plugin? Are you keeping your installation up to date with the Trac releases, running 1.4 right now and are you willing to further maintain that plugin in the future?

[falkb]

Replying to Massimo:

I think the mapping product|project → component|module → feature|bug where product is equivalent to project and feature is equivalent to the ticket itself, is the most basic hierarchy of any team, even the 1-man developer having 2 shell scripts published.

OK, I aggre.

You are the main author of the plugin?

Yes, thomasd and I wrote it (based on free code of crossroad), although just me published it on trac-hacks.org and cared for bugfixing it over the years.

Are you keeping your installation up to date with the Trac releases, running 1.4 right now

No, we are still on Trac-1.0.4, and we won't get time anymore in the company here for further development.

and are you willing to further maintain that plugin in the future?

I kept bugfixing a few years alive in my sparetime but I don't have time for that anymore, sorry.