Opened 11 years ago

Closed 2 years ago

#160 closed enhancement (wontfix)

Fix Plugins Trac Components to Work for All Plugins

Reported by: fireproofsocks's profile fireproofsocks Owned by:
Milestone: Priority: low
Component: Trac Keywords:


Migrating from #wp16524:

When developing a plugin, it's normal to set up a bug-tracker of some sort. I have found no documentation on how to do this using THIS bug tracker: trac. I've noticed that SOME plugins have support here, but nobody I've talked to knows how to get their custom plugins added to this bug tracker, which means that most of the plugins in the repository have no official bug tracking in place. That's a huge disservice to the community because only a fraction of those developers have the wherewithal to set up their own bug trackers.

This ticket is to request:

  1. Access to trac for all plugin developers
  2. Thorough documentation on how to get this set up for any new plugin authored
  3. Ideally, incorporate this in a standardized way for all plugins so the authors don't have to do any extra footwork.

Change History (14)

#1 @bpetty
11 years ago

  • Cc Moskjis mikeschinkel@… mitchbundy frederic.demarle@… bpetty added

While the original ticket discussed many alternatives to listing 3rd party issue trackers, this was decided in IRC to finally just fix up so it's possible to use for plugins.

This will need a patch to Trac most likely to handle some type of auto-complete field for the component/plugin as well as integration with the plugin directory.

#2 @nacin
11 years ago

Integration with the plugin directory is easy via XML-RPC. We already do similar stuff for the themes Trac. So we can A) bulk-add every existing plugin, and B) periodically or immediately add any new plugins.

#3 @bpetty
11 years ago

Yeah, the biggest issue I can see is likely going to end up being plugin selection UI, and anywhere within Trac that provides UI around filtering/displaying/reporting components. Definitely not going to provide a dropdown with 30,000+ plugins.

#4 @nacin
11 years ago

I would suggest trying to avoid a dropdown all together. Creating a new ticket can initially be just a "choose a plugin" interface, which I would suggest uses After that, we can make the field read-only/unchangeable.

#5 @mltsy
11 years ago

  • Cc mltsy added

#6 @siobhyb
11 years ago

  • Cc siobhanbamber@… added

#7 @noplanman
10 years ago

  • Cc armando@… added

#8 @SergeyBiryukov
9 years ago

  • Keywords needs-patch removed

Removing 'needs-patch' from components that are not open sourced yet, to help focus on tickets that actually need a patch.

This ticket was mentioned in Slack in #meta by sam. View the logs.

8 years ago

#10 @samuelsidler
8 years ago

  • Component changed from Plugin Directory to Trac

-> Trac

#11 @obenland
6 years ago

#281 was marked as a duplicate.

#12 @dd32
4 years ago

Let's be honest - We're never going to use/support to be used as ticketing for plugins.

Realistically, we should disable new ticket creation, and probably close all existing tickets.

Of the 2852 tickets, 1277 are open. Majority are listed against plugins not-listed and are >= 1 year old.

There's also a bunch of broken pages, for example:

#14 @dd32
2 years ago

  • Keywords pending-systems removed
  • Resolution set to wontfix
  • Status changed from new to closed

Tickets on have been disabled for a few months now.

This ticket is finally wontfix.

Note: See TracTickets for help on using tickets.