On Mon, Oct 29, 2012 at 7:03 PM, Olemis Lang <[email protected]> wrote:
> On 10/29/12, Gary Martin <[email protected]> wrote: > > > [...] > > I don't want to be moving away from Trac [...] > > > > +1 ... though I'd really like to see some gradual transition onto an > ORM in the middle handling DB access e.g. like SqlAlchemyIntegration > [1]_ . > > > It would certainly be difficult for plugin authors to support multiple > > plugin models. > > > [...] > > > > To make that > > work we would probably need to make sure that changes are generally > > transparent and always easy to convert [...] > > > > +1 > > > Going back to the problem with multiproduct, I'm happy to see us > > swapping to using the immutable product prefix. I am not yet convinced > > of the argument of providing an extra field for the convenience of > > allowing us to easily make the prefix mutable. > > The prefix must not be mutable if it will be used to identify product > resources . Notice that in Trac there are other relations outside DB > schema , the most notorious being TracLinks . > > > Withholding the ability > > to change the prefix will be simplifying for the users of the system so > > that they do not have to get used to referring to tickets through a new > > prefix on the whim of another user. While we could provide the ability > > for the old prefix to continue to be usable for identifying the > > appropriate resource under the new prefix, the potential confusion in > > discussions of tickets just seems unwarranted. The workaround exists of > > creating a new product and moving the tickets into it. > > > > +1 . Changes to product prefix should be an admin task carried out > using external scripts , trac-admin commands or alike ... > > > As for the question of notifications, I agree that we don't want > > multiple emails associated with a a change of product but I think it > > would be nice for resources that were associated at the time of the > > change to be able to report that the event has happened. On the other > > hand, the activity feed should really only show one event at any given > > scope. > > At present batch modifications contribute a single event to the timeline . > > > I am not convinced that that the bulk modify apparatus is the > > correct approach for this in the long term. > > > > It looks handy to reuse existing batch modifications . > > .. [1] Trac SQLAlchemy Bridge > (http://trac-hacks.org/wiki/TracSqlAlchemyBridgeIntegration) > > -- > Regards, > > Olemis. > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: > Ok, I think we agree on most points. I do no see going away from Trac in short term compelling either. It is just something to think about. For products we have a couple of enhancements in mind; I would defer the discussion until then (next week hopefully). Peter
