Hello Jani, Jani Tiainen wrote: > Christopher Lenz kirjoitti: > >> Am 21.11.2007 um 16:42 schrieb Jeroen Ruigrok van der Werven: >> >>> * Enhanced underlying data model (GenericTrac) >>> >> -1. There isn't even consensus on whether that's a viable direction. >> (Personally, I'm not a fan.) >> > > I feel same. Trac is quite highly specialized to do certain things, and > it does it pretty well. I don't see point to push "generic". Rather I > would see usage of some ORM (Alchemy) but as said somwhere there has >
I think there's a misconception coming from the term "generic", here. That proposal has nothing to do about making Trac look and behave the same for every resource it handles. It doesn't even necessarily imply that all the data models have to follow the same structure. The idea here is more fixing the (many) shortcomings of the current data model, and by doing that, take benefit of the potential reuse opportunities (+ introduce a project field, "en passant"). Think about the data model for attachment: there's no reason attachment data has to be hard-wired into the ticket data model or the wiki data model. The fact that the attachment data model was rather "generic" (by containing a "realm" field) made it independent of a specific resource and it was possible at a little cost to reuse the attachment functionality in more modules than the wiki and ticket modules, like I did for the milestone module in 0.11 or like osimons did for his fullblog plugin. Now the same can be said for the ticket comments. Currently, the way ticket comment information is stored (or any ticket change information for that matter) is 1/ rather messy, 2/ can't be reused for other modules. Having a more "changeset oriented" way of storing the ticket changes would greatly simplify the ticket module code. I think that there are ways to have the comments stored independently, in a way similar to the attachments (messages, like in Roundup?), and that will make it possible to have comments on other resources as well. This does *not* at all mean that having the possibility to comment on wiki pages will make them look like a ticket. Not at all. For example, it could take the form of a discussion page, like with mediawiki, only more structured. Same for changeset commenting, it could take any form that seems the best adapted for code review tasks. Having some sort of common API inspired by the versioncontrol API for dealing with the resource content will be very useful to provide the possibility to look at the history of changes (or diffs or annotation of content, cf. wiki blame) for any resources. This could be done for wiki pages since the beginning and since 0.11 for tickets. But doing that for e.g. milestone changes is simply impossible with the current data model. This is particularly important I believe in every project where it's important to have full audit abilities on every change made in the system, or just out of curiosity (like in "who the hell did add all those features to the 0.12 milestone" ;-) ). So please, don't make any hasty judgment on this topic, and believe me when I say there's /plenty/ of room for possible improvements to the current data model, as I know its quirks quite well... Finally, note that this data model refactoring discussion is mostly orthogonal to the SQLAlchemy proposal. SQLAlchemy helps you to define and access your data, it doesn't tell you or impose any constraint on *what* the data model should be. So SA will work with the current model as well as with any other. That being said, it probably won't hurt to be more familiar with the strengths/weaknesses of SA before designing a new data model. >>> * Basic support for multiple projects (TracMultipleProjects/ >>> SingleEnvironment) >>> >> -1. Multiple project support has been on the list for Trac2 since day >> one. We should try to get the 1.0 line in solid shape sooner rather >> than later, and use that as a basis for moving towards multiple >> projects. Not move multi-project to 0.x because we can't even get 1.x >> shipped. >> > > I think it's ticket #130 in t.e.o and last time I checked it was still > on list for 1.0 not for 2.0. I might be wrong though. > > This is two sided thing. It has very high demand and thus people are > finding a ways to overcome this - even plugins. There lies danger that > someone succeeds to make widely accepted solution by community. > Well, I moved it to 1.0, in a way to acknowledge the pressing demand for that major feature, as soon as I had a rather clear view about how to implement it. Also, I don't see how plugins could do anything here. For multiple project with different environment plugins can help, take TracForge as an example. But certainly not for multiple project support within a single environment, as support for that needs to be added to every core module. > >>> * Vastly improved versioncontrol subsystem (see VcRefactoring) >>> >> -0. I'd prefer to see this limited in scope, the proposal is very >> broad as is. >> > > Very broad and seems to be concentrating to fix problems with Mercurial... > Mercurial, Git, Bazaar, Monotone, anything branch oriented. > Also wonder how upcoming 1.5 merge changes tracking would affect Trac > SCM backend(s)... > None at all. We don't support merge tracking, although svnmerge.py support was on one of my TODO list (I've fortunately lost /that/ list). > >>> * Better user/session system >>> o Optional form-based login >>> o Pluggable user-directory provider (#2456) >>> o Nicer CC-list / "ticket monitoring" (#1459) >>> * Improved notification architecture (TracDev/Proposals/Journaling, >>> #1890) >>> >> -1. This proposal rubs me the wrong way, rather similar to >> GenericTrac. I also don't see a clear/strong benefit in this change. >> > > Well few points: I'm using AD to authenticate my users, I have e-mails > etc. in AD (ldap that is) > > There is no way to push that existing information to Trac. I had to do > rather ugly SQL scripts to import e-mail data to make "assign-to" field > as dropdown. And since there is no generic user data repository, I had > to repeat that action for all my 50+ projects. Now when new developer > steps in someone need to reproduce steps by hand. > Improvements on those aspects are worth considering for 0.12, if possible. +0, as I don't feel like contributing lots in this area myself, besides eventually fixing the IGroupProvider issue already mentioned. > CC-list is well.. A list. It works but it causes enormous change noise, > it's error prone (it's easy to delete someone other email from that too) > and hard to edit if list grows as has happened to some tickets in t.e.o. > The "change noise" issue was fixed a while ago (on trunk), and the "error prone" and "hard to edit" aspects are dealt with my latest patch on the ticket. It's only a UI change though, the data model issues remain unchanged. > I would see this being user property (Ticket/Wiki I want to follow) > rather than ticket property. > Yes, that's an idea as well. Did you realize that you just promoted some "generic" Trac idea? (Ticket/Wiki I want to follow) ;-) >>> * Better help/documentation system (#2656) >>> >> +1. Personally, I think this one is desperately needed. Let's stop >> polluting the wiki of every Trac-using project with documentation, and >> implement a proper, scalable solution, which also allows plugins to >> add help-style documentation. >> > > +1, this is something that bothers me too. Specially when you upgrade > Trac all upgraded help information is not visible if you don't > explicitly upgrade your wiki, which is IMO very bad option. > > What do you suggest here, trigger a wiki upgrade automatically along a normal upgrade? I think it's probably better to leave a message reminding about this at the end of an upgrade. >>> Eventually: >>> >>> * Migrate to SQLAlchemy for database interfacing and connection >>> pooling (see >>> sandbox/sqlalchemy) >>> >>> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is >>> currently >>> revamping a lot of its internals and the SQLAlchemy branch has been >>> dormant >>> for a long while it seems a bit difficult to correctly shove this >>> inside >>> Trac at this point in time. >>> >> -0. It'd be awesome if we could get rid of the Trac connection pooling >> code by using SA, but otherwise unless someone picks up this branch >> pretty darn soon, it should not be on the table for 0.12. >> > > +1 This is something I have some personal interest and maybe some extra > spare-time to work on. It should also enable me to use my favourite DB > backend - Oracle :) > Great! For Oracle, I'm a bit concerned how we will be able to handle text fields of arbitrary length, but I'm looking forward to that as well. >>> What date did we have in mind for 0.12? I sincerely doubt we want to >>> have as >>> long a wait as we had for 0.11. >>> >> Depends on when 0.11 is released, and on this thread and related >> discussions in the future. I don't think anyone actually thinks that >> this kind of release cycle is a good idea. We just need to agree on >> limiting the scope, and find a consensus on the subset to limit it to. >> > > I think that way too. Well it could so that there is intention to > release new versions about every 6 months, so feature set won't grow too > large. I rather would see that each release would contain few key > features not any gigantic blob. Being for example only i18n for 0.13. I > don't see point to restrict releases to any certain time frame. At least > upto version 1.0 which in theory is considered to be "stable" release > cycles can be very short if needed Well, a too fast release cycle has its inconvenient as well. Ideally we'd like to support as few line of developments as possible (e.g. drop 0.10.x support as soon as, say, 0.11.1 is out). I have the feeling that a 6 months time frame is the minimum for enabling that. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
