Same, not dev but multiple projects would be nice. + 1 On Nov 21, 2007 8:52 PM, Christopher Allan Webber <[EMAIL PROTECTED]> wrote:
> > ...well, I'm no Trac developer but as a user I'm going to +1 the > multiple projects bit. It's the thing most lacking from Trac for > us... > > Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> writes: > > > -On [20071121 17:24], Alec Thomas ([EMAIL PROTECTED]) wrote: > > * Basic support for multiple projects > (TracMultipleProjects/SingleEnvironment) > >> > >>This is long overdue and still one of the most requested features. > >>However, we don't want to do a half-arsed job so we should *really* > >>*really* think about what we're going to do and how. This could also > >>break a lot of plugins and we've already done that for 0.11 so it might > >>be an idea to hold off on this for a while. > > > > Mmm, you could argue it two ways unfortunately. > > From what I understand from Noah we have a page detailing what changes > needed > > to be made for the plugins. Odd Simon pointed me towards the direction > of > > http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11 So that would take > away > > most of the pain. I do not think there's much escaping maintaining > separate > > versions of plugins currently. The quicker we get the multiple projects > code > > done the sooner we can leave the 'instability' behind. Otherwise the > soonest > > we will support multiple projects will be around early 2009. (Right now > a > > feature voting feature sounds nice. ;)) > > > > At work we are currently using Jira since we needed multiple project > support. > > Jira's way of dealing with this is not bad from my first impressions. > > > > I'd say +1 for multiple projects in 0.12. > > > > * Better user/session system > > o Optional form-based login > > > > Should I see this as a page before the entire Trac installation that > requires > > you to authenticate before you can proceed? > > > > If so, that should not be too much work. +1 > > > > o Pluggable user-directory provider (#2456) > > > > To summarize: LDAP and like-wise directory backends. Quite nice to have > > indeed. This would make deploying Trac in Windows environments with AD > even > > more easier. (Unless I of course misunderstood the ticket.) > > > > Currently I am indifferent to it, +0. > > > > o Nicer CC-list / "ticket monitoring" (#1459) > > > > Indeed, +1. > > > > I guess it will boil down to: only authenticated users can add > themselves to > > the cc: list. Otherwise I would see no solution to solve the anyone can > edit > > the field problem. > > > > * Improved ticket query system (so that it can be used instead of SQL > reports > > system in 99% of the use cases) > > > > I remember that at one point we had the desire to deprecate /report and > use > > /query instead. Is this related to making that move, finally? > > > > Right now I am at +0 for it. It is needed, yes, but it is not > teethgrinding > > bad right now that would make it a high priority target for 0.12. > > > >>As we've discussed recently, I think we should be aiming for a 6 > >>month-ish cycle. > >> > >>To that end perhaps we should be sticking to one, two, maybe three > >>"significant" improvements, as well as the usual bug-fixes. > > > > I agree. We need to focus on a few things. I will be clearer towards > > everybody. I think it will also limit the source code churn that got > 0.11 in > > trouble. > > > > * Enhanced underlying data model > > > > If we decide to do multiple projects for 0.12 we will tackle this at the > same > > time. So I would say +1 for 0.12. > > > > * Vastly improved versioncontrol subsystem > > > > Looking at this work it seems that it is worthwhile to have support for > > multiple projects in place first, using Subversion as our base. And from > there > > we can make the next version of Trac (0.13 or 0.20 or so) target > refactoring > > the version control backend. To me that seems like a more logical step > from an > > architectural point of view. > > > > I'd be -1 for 0.12. > > > > * Wiki Engine refactoring > > > > -1 for 0.12. > > > > * Improved notification architecture > > > > Not sure right now what I think of this. > > > > * Improved API for request handlers > > > > Seems to be tied in with 'Vastly improved versioncontrol subsystem', so > -1. > > > > -- > > Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai > > イェルーン ラウフロック ヴァン デル ウェルヴェン > > http://www.in-nomine.org/ | http://www.rangaku.org/ > > Things are not what they seem; Nor are they otherwise... > > > > > > > > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. > > -- Met vriendelijke groeten Vandamme Samuel http://www.sava.be --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
