Modify

Opened 21 months ago

Last modified 21 months ago

#10990 new task

Deprecate this in favor of TracIniAdminPanelPlugin

Reported by: stoecker Owned by: jun66j5
Priority: normal Component: IniAdminPlugin
Severity: normal Keywords:
Cc: hasienda Trac Release:

Description

I took over the maintaining of TracIniAdminPanelPlugin and checked if IniAdminPlugin has some features the panel does not have. I found none, but the TracIniAdminPanelPlugin is much more feature rich.

Maybe the IniAdminPlugin should be dropped in favour of the more modern one?

Attachments (0)

Change History (12)

comment:1 Changed 21 months ago by rjollos

  • Owner changed from rjollos to jun66j5

Jun is maintaining this plugin, so it is up to him as to whether to "officially" mark it as deprecated.

comment:2 Changed 21 months ago by rjollos

Jun, I changed the component owner so that new tickets will assigned to you.

comment:3 Changed 21 months ago by jun66j5

Looks good than IniAdminPlugin. But, TracIniAdminPanelPlugin doesn't support Trac 0.11. Worse, it breaks compatibilities with Trac 0.12 now.

tracworkflowadminplugin/0.12/tracworkflowadmin/web_ui.py#L31 would be helpful for i18n on both 0.12 and 1.0.

$ ~/venv/trac/0.12/bin/python
Python 2.4.3 (#1, Jan  9 2013, 06:49:54)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import inieditorpanel.default_manager
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/jun66j5/src/trac/trac-hacks/traciniadminpanelplugin/trunk/inieditorpanel/default_manager.py", line 43, in ?
    class IniEditorBasicSecurityManager(Component):
  File "/home/jun66j5/src/trac/trac-hacks/traciniadminpanelplugin/trunk/inieditorpanel/default_manager.py", line 67, in IniEditorBasicSecurityManager
    explicit access level defined. Defaults to readonly.""", doc_domain="inieditorpanel")
TypeError: __init__() got an unexpected keyword argument 'doc_domain'
>>>

comment:4 Changed 21 months ago by stoecker

With 0.11 you're right. It supports only 0.12 and up. And yes, trunk only supports 1.0, but there is a 0.12 branch (I corrected requires for trunk). I adedd a reference to the 0.12 branch on the wiki page.

Maybe instead of fully deprecating it, we should simply add a more prominent note that for 0.12 and up the panel is available and for 0.11 this plugin?

comment:5 follow-up: Changed 21 months ago by rjollos

If you aren't willing to fully support 0.12, then I would suggest that we don't deprecate IniAdminPlugin. It's not difficult to support 0.12, and just good practice to continue to support the LTS version of Trac in my opinion.

comment:6 in reply to: ↑ 5 Changed 21 months ago by rjollos

Replying to rjollos:

If you aren't willing to fully support 0.12, then I would suggest that we don't deprecate IniAdminPlugin.

More specifically, maybe we should continue to support IniAdminPlugin until 0.12 is no longer the LTS version of Trac. So, IniAdminPlugin would be available for Trac 0.11 and 0.12; TracIniAdminPanelPlugin would be available for 0.12 (with only major fixes / security issue supported, as described here) and 1.0+.

comment:7 follow-up: Changed 21 months ago by stoecker

If you aren't willing to fully support 0.12, then I would suggest that we don't deprecate IniAdminPlugin. It's not difficult to support 0.12, and just good practice to continue to support the LTS version of Trac in my opinion.

What do you understand under "fully support"? Not even the trac core gets new features in old versions. I think it is pretty normal that old releases only get bug-fixes, while new ones get new features. The 0.12 version does everything the 1.0 version can except proper i18n. At least I used the 0.12 until a week ago without any troubles.

comment:8 in reply to: ↑ 7 Changed 21 months ago by rjollos

Replying to stoecker:

What do you understand under "fully support"?

That was rather vague of me. I generally try to keep the trunk compatible 0.12 and sometimes even 0.11 until it becomes too cumbersome to do so, so I suppose that I'd define "fully support" as keeping the trunk (i.e. main development line) compatible so that 0.12 users receive all new features. Lately, supporting 0.11 with some plugins is becoming a lot of work, so I've been dropping support for 0.11. I haven't found it difficult at all to keep the trunk compatible with 0.12 for other plugins and I think this is the best situation for the community and end-users, but I understand that not everyone has time to worry about previous versions of Trac.

I thought that IniAdminPlugin had i18n support in a 0.12-compatible version, but I'll have to take another look.

Anyway, for this plugin, I feel that whether or not we decide to say "IniAdminPlugin is officially deprecated for 0.12" should come down to whether or not IniAdminPlugin provides anything that TracIniAdminPanelPlugin does not, such as i18n support.

That's just a suggestion though. I don't have the time to provide significant support for either plugin (which is why I handed IniAdminPlugin off to Jun), so as always, it's up to the maintainers.

comment:9 follow-up: Changed 21 months ago by stoecker

I simply can't care for 0.12, as I don't test on 0.12. That works for bug-fixes, but not for new features which usually mean large code changes.

The 0.12 source has some i18n parts, but they never really could have worked and also there was never a translation.

The 0.12 version BTW is still much nicer than IniAdminPlugin, at least I switched about 2 years ago I think :-) The author should have sent patches instead of reimplementing it. Don't know why people always restart everything without even trying to improve what is already there.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 21 months ago by rjollos

  • Cc hasienda added; anonymous removed

Replying to stoecker:

The 0.12 version BTW is still much nicer than IniAdminPlugin, at least I switched about 2 years ago I think :-) The author should have sent patches instead of reimplementing it.

Oh, very good to know. I didn't realize it was essentially a fork.

Don't know why people always restart everything without even trying to improve what is already there.

I feel exactly the same. I've wondered if it is because people don't know of the AdoptingHacks policies, or if they just consider that too much trouble. I'd like to improve on this situation over time, and plan to raise it as a topic on the mailing list and ask for suggestions, but first, I must focus on bringing trac-hacks up to a usable state with the upgrade to 1.0.1 ;)

comment:11 in reply to: ↑ 10 Changed 21 months ago by hasienda

Replying to rjollos:

Replying to stoecker:

Don't know why people always restart everything without even trying to improve what is already there.

I feel exactly the same. I've wondered if it is because people don't know of the AdoptingHacks policies, or if they just consider that too much trouble. I'd like to improve on this situation over time, and plan to raise it as a topic on the mailing list and ask for suggestions, but first, I must focus on bringing trac-hacks up to a usable state with the upgrade to 1.0.1 ;)

I agree. Same for AccountManager and UserManager, WikiCalendar and WikiTicketCalendar, TracForms and WikiForms, just to name some I do remember instantly. I care to continue, or even re-join development lines, if it is sensible at all. Let's keep and spread that notion even more after the site upgrade, sure. Adopting hacks must become the definitive standard and forking the rare exception. This emphasizes the value of having control over the repository permission management too, unlike what is the situation for externally hosted plugins.

comment:12 Changed 21 months ago by stoecker

Discussion gets "out of topic", but I don't believe you can change that behaviour. For most people reimplementing is easier, as they don't need to understand foreign code and usually they also have the feeling that the can do better and without all the little issues and bugs of original software (which they can't, but they think so). Doing proper patches needs a lot more experience.

Add Comment

Modify Ticket

Action
as new The owner will remain jun66j5.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.