Modify

Opened 9 years ago

Closed 6 years ago

#12373 closed task (wontfix)

Development roadmap

Reported by: Cinc-th Owned by: falkb
Priority: normal Component: SimpleMultiProjectPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.12

Description

Hi falkb,

I'd like to discuss a little bit the future development roadmap to get an idea what you have in mind for the plugin.

I think about doing the following next:

  • Implement #12031, allow several projects to have the same milestone (I need that one, too)
  • Remove the component panel in the Manage Projects section
  • Refactor model.py which is rather huge by now

We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.

  • The current tree should be tagged so people have a stable plugin to use while doing work in trunk.

For the long term it's maybe worth thinking about moving to BSD license because Trac and most of the plugins are following this license and so it would help to share code. This will happen more or less automatically when new code is added only as BSD.

Attachments (0)

Change History (11)

comment:1 in reply to:  description ; Changed 9 years ago by falkb

Hi Cinc-th,

Replying to Cinc-th:

Hi falkb,

I'd like to discuss a little bit the future development roadmap to get an idea what you have in mind for the plugin.

That's a good idea. Well, I'm mainly interested in

  • having default values per project (#11543),
  • and I don't like how the project filter list steals so much space on the Roadmap page. Currently, actually the page width reduces by the width of that list! (#11162). Alternatively, one could fix it somehow in a way that the project filter list just inserts in the space it really uses, just the page part of its height so to speak. But currently, I don't have a working solution. :(

Though I'm driven by what I need for Trac here at work, and it's actually quite sufficiently running well, so there's not much will for taking time for it at present... :)

I think about doing the following next:

  • Implement #12031, allow several projects to have the same milestone (I need that one, too)

Sounds good, although we should also provide it for the field "version" as well then, because a milestone usually releases a certain version. (BTW: Here, we actually mainly heading for versions as target of a plan for software, and a milestone is just a special event in the plan on a higher level of planning a project (ISO quality management stages).)

  • Remove the component panel in the Manage Projects section

I have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.

  • Refactor model.py which is rather huge by now

Not my focus but why not, if it keeps simplicity and doesn't break things.

We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.

Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.

  • The current tree should be tagged so people have a stable plugin to use while doing work in trunk.

Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.

For the long term it's maybe worth thinking about moving to BSD license because Trac and most of the plugins are following this license and so it would help to share code. This will happen more or less automatically when new code is added only as BSD.

I don't much care about all those Open Source licenses. Never heard about problems with certain ones... I think I reused the license that was used by crossroad (the former maintainer).

comment:2 in reply to:  1 ; Changed 9 years ago by anonymous

Replying to falkb:

Though I'm driven by what I need for Trac here at work, and it's actually quite sufficiently running well, so there's not much will for taking time for it at present... :)

Same here.

I think about doing the following next:

  • Implement #12031, allow several projects to have the same milestone (I need that one, too)

Sounds good, although we should also provide it for the field "version" as well then, because a milestone usually releases a certain version. (BTW: Here, we actually mainly heading for versions as target of a plan for software, and a milestone is just a special event in the plan on a higher level of planning a project (ISO quality management stages).)

If it works for milestones an implementation for versions is probably easy to do.

  • Remove the component panel in the Manage Projects section

I have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.

Is the other plugin public so I may have a look into it? At first sight I'd say the new SMP feature doesn't do anything hackish. Just some Genshi filtering stuff.

We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.

Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.

Ok, so I drop that one. I have no means to test either. Will make a copy to a 0.11 branch before starting to break stuff for that version (which will for sure happen...).

  • The current tree should be tagged so people have a stable plugin to use while doing work in trunk.

Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.

Only reason is to be able to tell people to use the latest tag if for some reason the trunk doesn't work for them. I don't want to educate someone in a ticket comment how to checkout a specific working subversion revision ;-).

For the long term it's maybe worth thinking about moving to BSD license because Trac and most of the plugins are following this license and so it would help to share code. This will happen more or less automatically when new code is added only as BSD.

I don't much care about all those Open Source licenses. Never heard about problems with certain ones... I think I reused the license that was used by crossroad (the former maintainer).

Ok. Will continue to submit features as BSD and we'll see if we end up as BSD in the end.

comment:3 in reply to:  2 ; Changed 9 years ago by falkb

Replying to anonymous:

Replying to falkb:

  • Remove the component panel in the Manage Projects section

I have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.

Is the other plugin public so I may have a look into it? At first sight I'd say the new SMP feature doesn't do anything hackish. Just some Genshi filtering stuff.

I checked again, it's not local anymore. My colleague uploaded it already as ComponentHierarchyPlugin. It also adds a column where things get mixed up then. I think that was the reason to keep SMPP with its own component page. The blank row seems to be a different problem what I first need to find out here... sorry for the confusion.

We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.

Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.

Ok, so I drop that one. I have no means to test either. Will make a copy to a 0.11 branch before starting to break stuff for that version (which will for sure happen...).

I think I have dropped 0.11 support a while ago, already (it actually never fully have worked and there was a ticket for it)

  • The current tree should be tagged so people have a stable plugin to use while doing work in trunk.

Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.

Only reason is to be able to tell people to use the latest tag if for some reason the trunk doesn't work for them. I don't want to educate someone in a ticket comment how to checkout a specific working subversion revision ;-).

This convinces me!

comment:4 in reply to:  3 Changed 9 years ago by falkb

Replying to falkb:

I checked again, it's not local anymore. My colleague uploaded it already as ComponentHierarchyPlugin. It also adds a column where things get mixed up then. I think that was the reason to keep SMPP with its own component page. The blank row seems to be a different problem what I first need to find out here... sorry for the confusion.

Aaaaah, I was wrong. Wait, it'll be uploaded soon...

comment:5 Changed 9 years ago by falkb

@Cinc-th: now you can try ComponentHierarchyPlugin

comment:6 Changed 9 years ago by anonymous

Hi Cinc-th, could you imagine to patch the Trac core to bring the multiple project feature to the standard system? CU, falkb

comment:7 Changed 9 years ago by falkb

Login was missing, sorry

comment:8 Changed 8 years ago by Cinc-th

Tagged the current version as 0.0.4.

I think the next version should be 0.5.0. It's time to reflect the feature set in the versioning ;-).

comment:9 in reply to:  8 Changed 8 years ago by falkb

Replying to Cinc-th:

Tagged the current version as 0.0.4.

I think the next version should be 0.5.0. It's time to reflect the feature set in the versioning ;-).

Currently I don't have the time to look at work in progress but I'm very curious how that 0.5.0 snapshot will look like. :-) I'm going to try it as soon as you tagged it (and maybe put to the stable branch?).

comment:10 Changed 8 years ago by Cinc-th

There are currently some minor regressions in the trunk wrt to saving settings and stuff. I'm currently working on that. Aside from that all features are still in place afaics.

For the future I'd like to use Tracs user management for access control to projects by defining groups and membership using the user admin panel. That will probably need some rethinking of how stuff is done.

comment:11 Changed 6 years ago by falkb

Resolution: wontfix
Status: newclosed

topic burried after 2 years now. No activities anymore.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain falkb.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.