Request for actions (maintainership status unknown)

Saw your fork https://bitbucket.org/mitar/trac-htgroupeditor mentioned in the wiki page, so maybe you're interested in this initiative as well. I remember various contributions of yours, so would be glad to co-operate once again. Let's see, what could be done.

Response from the official email address: "I no longer work for Arqiva. Please send any e-mails to the Head of Media Products ...@arqiva.com."

I've done so instantly, awaiting more feedback. I discharged the email intentionally, since I've no permission to publish. Looks like I'll have to jump through some more loops, because that person is not mentioned on the cooperation's website.

Thank you for making the effort.

Replying to mitar:

Thank you for making the effort.

Oh, you're welcome. No more replies today, but I most likely the author is gone, considering no activity at all within the last year. It's a pity, that this is quite common. But at least by current adoption policy I'll get enabled within a few weeks to proceed.

No question, acct_mgr-0.3 will be a remarkable milestone. I'm looking forward to bring in this code, making acct_mgr-0.4 even more attractive and useful with your help.

Have you been thinking of moving development to some distributed versioning system? It is much easier to work with pull requests than with patches which get old very fast.

Hm, yes, I've done some development on bitbucket, similar to yours. But the core of my development infrastructure is a local copy of t-h.o SVN inside a Mercurial repo. I use Mercurial Queues a lot, but have no problem to work with patches - just import them into the MQ patch stack and export from there into patch files, that I do attach to tickets for discussion.

Either way, I have to review changes regardless of the form. Patch, changeset, all(most) the same, so I do largely adapt to others style for cooperation, rather not dictating, how they would like to do their contribution (just a statement, no critics intended).

I'll have a look at your repo soon. Full integration with AcctMgr as I see it is superior over more and more discrete plugins, and this will require some manual adaption anyway.

I'm looking forward to work with you and certainly learn from you.

The problem with patches, as I see it, is that it puts additional pressure on the maintainer to integrate it quickly, or additional load on contributor, to refresh the patch as needed.

But yes, let's not go into the too meta-discussions.

So, if you need any help, say so.

Have you seen those plugins:

• https://bitbucket.org/mitar/trac-globalregister/overview
• https://bitbucket.org/mitar/trac-recaptcharegister/overview

Replying to mitar:

[...] But yes, let's not go into the too meta-discussions.

Yes. :-)

So, if you need any help, say so.

Sure. Done so before. Thanks for offering.

Have you seen those plugins: * https://bitbucket.org/mitar/trac-globalregister/overview

No, but looks interesting. Only I'm unable to include it into AcctMgr as it is because of the current license. I like GPL, but AFAIK it's incompatible with the even more liberal licenses used for many Trac plugins. I've the same problem with TracFormsPlugin. Sadly I've already encountered some refuse to assist because some devs avoid GPL code all together. And I do understand at partially the rejection of the viral nature of this license as too limiting from another point of view. Since it's your code, would you consider i.e. a dual-licensing option for getting it into AcctMgr?

* https://bitbucket.org/mitar/trac-recaptcharegister/overview

Yes, I'm aware of some alternative captcha implementations, but again this particular one is GPL3 and has to stay separate to not taint AcctMgr's original license. Again, personally I'd like to do much more integration to save admins from installing a myriad of patches for hacks on top of plugins extending...

But this is largely outside of my influence, when it comes to legal issues. As a Debian guy I'll certainly not work against a license, even not downplay or underestimate consequences of doing so.

Sure, I can give it also under public domain, if you want. ;-)

But I am not so sure about the idea of including all different functionalities into the core. I think this is really hard to maintain then. It is better that AcctMgr? would have a great plugin system, great API, and then on some page collect information about plugins. For example, better it would be to have API for captchas and then recaptcha plugin would be only one for that. And this my globalregister plugin really does not need to be included in the core.

I think it would be better to have limited functionality in core and then for each functionality such table. I think this is much better idea then one-solution-to-cover-all. It is also in line with Trac's philosophy.

If you want, you could also add to the table and "endorsed" column, where you can select which plugins are endorsed by you and for example where you have commit access to be able to fix things or something like this.

I see you follow wiki edits too and I'm glad you even like some of the recently added information.

Certainly making a good API and encouraging plugins is a strong point counting for Trac and I like it as well. I just wanted to show, that I'm open to integrate small enhancements and extensions, when making a plugin would be too much. And avoid patches.

So I agree happily with you in making good reference tables to collecting related plugins with description and maybe even a rating/recommendation, endorse existing API and sparingly add new parts turning suggested interfaces and patches into valuable optional plugins.

Since there has been no response from robert_martin, I've tagged this plugin and FineGrainedPageAuthzEditorPlugin as needsadoption.

See also #9947, which I opened with the hope of eventually integrating the FineGrainedPageAuthzEditorPlugin into AccountManagerPlugin.