trac-hacks / tracnukeuserplugin Goto Github PK

Hi,

I'm an administrator for trac-hacks.org. We've created an organization on GitHub and are inviting authors of trac-hacks plugins to join the organization. Your repository could be transferred into the organization as described in the GitHub docs. You'd retain full control over the repository, but the hope is that it will be easier for users on GitHub to fine trac-hacks plugins, including yours, by viewing the trac-hacks organization.

In the future, if you choose to no longer maintain the plugin, the organization would be able to provide commit access to new developers. This would only be done with your permission, as has been the policy for plugins hosted on trac-hacks.org. If you've already decided to no longer maintain the plugin, we would particularly appreciate you transferring the plugin to the trac-hacks organization so that we can help find new maintainers for it.

Finally, creating the trac-hacks organization is a work in progress. I appreciate if you have any suggestions on how to best support the community of trac plugin developers on GitHub. I'll be writing a blog post soon with more information and will follow-up here with a link to that post.

Kind regards,

• Ryan

Looking at your code here I see you've found a bug that has been fixed during the last months of development and will gain common use by next stable release acct_mgr-0.4

So this will still not hurt to keep it for older plugin applications, but you may want to adapt your developer comment in the code.

Steffen

Thanks for responses to my earlier request, so I'm encouraged to follow-up:

I'm evaluating the possibility for integration with AccountManagerPlugin. It's license is BEERWARE, not effectively much different, but maybe still a bit more liberal than BSD (or "3-clause BSD" as you may have intended to assign that one). Do you see a chance for re-licensing your code, so that upstream development could happen within AccountManagerPlugin?

I'm not finished and determined yet, but this would be a per-requisite for integration. But you're free to push your intention, i.e. to keep it as a separate plugin. I'm listening.

I've just flagged the plugin with 'needsadoption' at trac-hacks.org for now.

Not seen such a code placement. Better keep __init_.py empty and move code to another file, say console.py (following Trac core naming convetions) or similar. You can preserve current way of component activation by keeping a single line in __init__.py like so:

from nukeuserplugin.console import *