[Trac] Re: Trac in trouble, take two.
Jani Tiainen kirjoitti: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I got lot of answers and I try to summarize what I learned from them. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. So, I can have partially open environment but there is no complete ready to use solution. Still looking for solution that's easy to use and allows: User A can access tickets that have been marked as a public. User A is authenticated from some authentication store, like htpasswd. These are self-registered (and approved by some admin) User B can access tickets that have been marked as a public or private. User B is authenticated from LDAP. User C can access tickets that have been marked as private. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. MasterTicketsPlugin does basic work of this. Specially I would need this for public/private tickets so that people can't close public ticket without handling private ticket (usually developer stuff) first. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) For multiple repositories there is (initial) support altough it's not my primary case. For simple multiple projects in single environment (and sub projects of them) there is not solution yet? Trouble #4: Web based environment creation. There is few plugins/scripts that I could take a look at. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Something that is not working at all in near future. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. BlackMagickTicketTweaksPlugin seem to allow arbitary permissions. It's good that things exists in plugins but there should be prebundled single click install to include loads of things presetted so that enduser just could disable unnecessary features. -- Jani Tiainen Tein sein mihin näillä lahjoilla pystyin. Tein sen, en yhtään enempää. - Martti Servo Napander --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Noah Kantrowitz wrote: Well work that idea out in more detail. How do you share things, and how do you not share things. Things like plugins probably have to be global just as an implementation detail, but what about other stuff. User preferences should be shared between projects? Etc etc. What about UI, how do you handle submitting a new ticket. Start writing up use cases from other multi-project systems, and showing how to implement them (what options to set) in this model. OK, will do. -- Gary --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
There are plugins for much of this. I'm only to speak to a few specific issues as most of these have been addressed by others in this thread: On Wed, Oct 01, 2008 at 08:51:25AM +0300, Jani Tiainen wrote: snip/ Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) There is a multirepository branch that is supposedly in good shape (I don't have need [yet] for a multirepository trac so I haven't used it). I'd love to know when/if this is slated for trunk. Trouble #4: Web based environment creation. There are actually a few of these. TracForge does this. I've also written a trac project templating system, th:TracLegosScript, one component of which is a TTW project creator. Its not really ready for prime-time as there are missing features (importantly, DB type and authorization checking) but most of what I care about is there and I'd be happy to elevate ticket priorities if anyone wishes any of the missing features. There are a few more that I can't remember now. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Personally, I'd like to see an IUserDataProvider interface to make this more flexible. So the LDAP plugin could provide this, OOTB trac could implement what it currently does as an implementation of this interface, and a multi-project solution could implement whatever it wants (possibly delegating to a master environment). I'm also pro keeping the notion of multiple projects out of trac core. What I would like to see is more infrastructure so that it is easier to write plugins that interface between trac projects. I'm happy to ticket this if its generally wanted and not too contraversial. As a note, I think trac's role is as a good infrastructure to build the ideal bug tracking system. I think trying to get trac core to be OOTB an amazing bug tracker is a bad idea, as folks have different needs (and even projects for the same folks have different needs). This has all been discussed before and I think people are starting to work towards making it easier to get OOTB trac to be easily modified to what a trac administrator wants -- a platform that is easily customizable via plugins, etc. Jeff Hammel The Open Planning Project http://topp.openplans.org IRC: jhammel, k0s --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen [EMAIL PROTECTED] wrote: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I would be more than happy to hear some solutions for my (and thus my boss) troubles. I've listed them here in order of priority. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) Trouble #4: Web based environment creation. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. I was going to reply to you point by point, but instead I'll just say that we do the majority of those bullet points with Trac. We aren't doing multiple authentication yet, though there are plans to, and there's really nothing stopping anyone else from doing that. In fact, one could write a single PasswordStore that simply tries a list of other PasswordStores in a specified order. The only other one we aren't doing anything with right now is #2, which I think is the most legitimate complaint here (I mean, they're all legitimate points, but most of them can be accomplished with Trac). I've played with Redmine, and there are a number of things that it does make easier, but a lot of it does not fit my needs. One thing Trac makes easier (and this may be partly due to the fact that it's written in Python, which I am more familiar with) is tweaking it to make it do exactly what I want. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Erik Bray wrote: On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen [EMAIL PROTECTED] wrote: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I would be more than happy to hear some solutions for my (and thus my boss) troubles. I've listed them here in order of priority. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. We use apache to do multiple source authentication. If you hate http basic auth, you can use the AccountManagerPlugin to put a form based auth over it. The way it works is that you give it a url that uses basic auth. When you submit the login form, it uses urllib2 to check against the specified url. This gives you all the performance benefits of apache's more mature code, like it's ldap caching for instance. If you would like an example apache config, just ask. Here is how it works. We use one passwd file per project. If the ldap auth fails, then it checks the projects htpasswd file. We do this with WSGIAuthUserScript to check the htpasswd file. This makes it easy to setup up tons of projects. If you don't have a lot of projects, you could do it in straight apache. mod_perl is another alternative. In fact, we used that before mod_wsgi had the AuthUserScript feature. The major benefit of the mod_wsgi approach is that when you add projects, you don't need to restart apache. With a straight apache approach, a restart would be needed. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) Trouble #4: Web based environment creation. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. I was going to reply to you point by point, but instead I'll just say that we do the majority of those bullet points with Trac. We aren't doing multiple authentication yet, though there are plans to, and there's really nothing stopping anyone else from doing that. In fact, one could write a single PasswordStore that simply tries a list of other PasswordStores in a specified order. The only other one we aren't doing anything with right now is #2, which I think is the most legitimate complaint here (I mean, they're all legitimate points, but most of them can be accomplished with Trac). I've played with Redmine, and there are a number of things that it does make easier, but a lot of it does not fit my needs. One thing Trac makes easier (and this may be partly due to the fact that it's written in Python, which I am more familiar with) is tweaking it to make it do exactly what I want. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
On Oct 1, 4:25 pm, Robert C Corsaro [EMAIL PROTECTED] wrote: Erik Bray wrote: On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen [EMAIL PROTECTED] wrote: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I would be more than happy to hear some solutions for my (and thus my boss) troubles. I've listed them here in order of priority. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. We use apache to do multiple source authentication. If you hate http basic auth, you can use the AccountManagerPlugin to put a form based auth over it. The way it works is that you give it a url that uses basic auth. When you submit the login form, it uses urllib2 to check against the specified url. This gives you all the performance benefits of apache's more mature code, like it's ldap caching for instance. If you would like an example apache config, just ask. it would be nice if you could post it. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) Trouble #4: Web based environment creation. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. I was going to reply to you point by point, but instead I'll just say that we do the majority of those bullet points with Trac. We aren't doing multiple authentication yet, though there are plans to, and there's really nothing stopping anyone else from doing that. In fact, one could write a single PasswordStore that simply tries a list of other PasswordStores in a specified order. could you pls detail a little bit how you do 3-4? kr, rupert. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Erik Bray kirjoitti: On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen [EMAIL PROTECTED] wrote: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I would be more than happy to hear some solutions for my (and thus my boss) troubles. I've listed them here in order of priority. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) Trouble #4: Web based environment creation. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. I was going to reply to you point by point, but instead I'll just say that we do the majority of those bullet points with Trac. We aren't doing multiple authentication yet, though there are plans to, and there's really nothing stopping anyone else from doing that. In fact, one could write a single PasswordStore that simply tries a list of other PasswordStores in a specified order. The only other one we aren't doing anything with right now is #2, which I think is the most legitimate complaint here (I mean, they're all legitimate points, but most of them can be accomplished with Trac). I've played with Redmine, and there are a number of things that it does make easier, but a lot of it does not fit my needs. One thing Trac makes easier (and this may be partly due to the fact that it's written in Python, which I am more familiar with) is tweaking it to make it do exactly what I want. Well, I would be happy to hear what is needed to make those points work, even partially. Most critical being #1. I've played with Redmine a bit and it works very well with subproject things, simple cross referencing (same as MasterTicketPlugin) and it's very nice issue tracking system. But rest of Redmine is crap. And it's ruby thingy which is ugly itself. :D (That's about trashing Redmine). -- Jani Tiainen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Whatsup Jani Feel like making a cooperative effort on patching on the issues that you touched? I'm also thinking about more thorough access control implementation among other things. On Oct 1, 8:51 am, Jani Tiainen [EMAIL PROTECTED] wrote: Trouble #1: Partially open environment. Recently there has been Trouble #3: Multiproject/multirepository support. We have few projects Trouble #6: Selective permissions (roles), specially for tickets. Like I --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Gary Oberbrunner kirjoitti: Jani Tiainen wrote: I've played with Redmine a bit and it works very well with subproject things, simple cross referencing (same as MasterTicketPlugin) and it's very nice issue tracking system. But rest of Redmine is crap. And it's ruby thingy which is ugly itself. :D (That's about trashing Redmine). I'm mostly interested in subproject support and ticket xrefs (blocking etc). I haven't tried Redmine yet, but the demo certainly looks enticing. Obvious ripoff of Trac in many ways, but beyond it in several (e.g. the things I need above, as well as gantt charting and more). Jani, can you say more about what you find crappy about Redmine, from your experience? Ignoring ruby vs. python language wars of course -- this discussion should be about the best tool for the job. From my limited experience there is several factors, most notably Redmine is closed system. You either do it Redmine way or you don't do it at all. It's not extensible as Trac (though, there is efforts made to do that but I doubt it will be working any near future). Also lack of developers (only one or two main developers) makes feature implementations much slower. Lot of things are ripoff from Trac. Wiki is most crappiest thing, no hierarchy and such. Issue tracking in Redmine is pretty cool, specially you can have different workflows for different roles. Multiproject/subproject thing is very nice, even it's not ultimate or all covering solution but it works for most parts. One funny feature (I understood that's more like limitation of Ruby, not Redmine itself) is that it's not trivial to install several separate instances. So all projects must live together in one space... For end user point of view, it provides lot of features out of the box with webui to customize settings. You don't need to know how to fetch, install and handle plugins etc. -- Jani Tiainen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Noah Kantrowitz wrote: ... So, in summary, #5 is the only real issue on this list and that has been on our roadmap forever. Everything else is just a failure to either read the documentation or to find the right plugin. Well, to be fair I think #3, if interpreted as subproject support, has been outstanding for quite some time (See http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment, http://trac.edgewall.org/wiki/GenericTrac, http://trac.edgewall.org/ticket/130 etc.) But maybe that's not Jani's meaning? -- Gary Oberbrunner --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
On Wednesday 01 October 2008 13:00:20 Jani Tiainen wrote: Reporter - Person who reported ticket (usually customer). Since we get reports by call/email this is more like free textfield. Manager - Person who is responsible in ticket general. Usually project manager. Assignee - Person who ticket is assigned to. Usually that poor developer or tester. Over here Poor Developer and Tester are two different people: developer has to test his fix, of course, but comprehensive testing to make sure the fix didn't break anything else is done by someone else. Also, public release is done when a fix is important, or there's enough minor fixes to warrant a release. Which is similar, but not entirely unlike a milestone: apart from triggering buzzwordiosyncrasy in half the people I know, milestone implies a goal set in advance. Dima -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
-Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gary Oberbrunner Sent: Wednesday, October 01, 2008 11:18 AM To: trac-users@googlegroups.com Subject: [Trac] Re: Trac in trouble. Noah Kantrowitz wrote: ... So, in summary, #5 is the only real issue on this list and that has been on our roadmap forever. Everything else is just a failure to either read the documentation or to find the right plugin. Well, to be fair I think #3, if interpreted as subproject support, has been outstanding for quite some time (See http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment, http://trac.edgewall.org/wiki/GenericTrac, http://trac.edgewall.org/ticket/130 etc.) But maybe that's not Jani's meaning? I have also explained many times on this list why we have put off multiple project support (including subprojects), but just for kicks: People are very quick to ask for multiple project support, citing tools like GForge or Redmine that can do it so it must be easy. This fails to take a very important part of the Trac philosophy into mind; we go as far as humanly possible to not enforce any project management philosophies on the end user. The fundamental problem with mutli-project support is that if you ask 10 people what they want from it, you get back 10 different critical feature lists. This leaves us in a quandary. Constructing a single design that allows all of those styles is incredibly tricky and not something that can be done overnight. If someone has suggested such an overarching design, I have yet to see it. The simple solution to this for right now is to leave multiple project handling in the domain of plugins and scripts for right now. This means each plugin can experiment design-wise without impacting the users of another plugin. Over time I suspect we will see a small number of these plugins become the de-facto standard, and then at that point it is much easier to talk about integrating the few winning designs into Trac core. So, in short, if you think mutli-project support is easy and know how it should be done, go prove me wrong. Really, I won't be offended. Make something that everyone acknowledges is The Right Way To Do It and we can move forward, but without that we have bigger fish to fry. --Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
If you want multiple owners can you simply use the grouping system? Put everyone in a group and assign the ticket to the group? I haven't tested it but it seems like it 'should' work. Then you'd be able to track the changes on a per user basis instead of having two users sharing an ID. Toole, Brian wrote: How are you wanting the multiple owners to work? Do you mean multiple owners for a given ticket component? I'm not sure if this is exactly what you're looking for, but here's what I've done: We currently have one position (Report Writer) that is a time-share between two people, so since we do most of our ticket assignments based on Component, I assigned our Report Writer component to both people, so whenever a ticket comes through with that component, unless manually/specifically assigned to someone else, both of our Report Writers get the ticket. From there, I just modified the view tickets query code to allow for 'Contains' as well as the defaults of 'Is' and 'Is Not', and set 'Contains' as the default query method. Brian Toole Oracle Programming Specialist Web and Administrative Systems University of Portland Portland, OR 97203 (503) 943-7196 [EMAIL PROTECTED] -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jani Tiainen Sent: Wednesday, October 01, 2008 9:14 AM To: trac-users@googlegroups.com Subject: [Trac] Re: Trac in trouble. Erik Bray kirjoitti: On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen [EMAIL PROTECTED] wrote: I'm trying to keep Trac in our corporation environment but day after day it's coming more difficult due feature needs from users. I've tried several solutions but I haven't found anything even nearly working and what's worse someone found Redmine and it's working more or less perfectly for one of our projects and now they are pushing Redmine to all over the place. I would be more than happy to hear some solutions for my (and thus my boss) troubles. I've listed them here in order of priority. Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. Trouble #2: Cross-reference and xref actions. There is need to have blocks relation that is enforced. Trouble #3: Multiproject/multirepository support. We have few projects that are actually combination of several (separate) repositories but also there is few libraries that should be linked (and again, cross referenced, see trouble #2) together tightly. (Not loose coupling like external links) Trouble #4: Web based environment creation. Trouble #5: Userinformation retrieval from our LDAP server. Specially active accounts (since sometimes people come and people leave) and e-mail addresses. Trouble #6: Selective permissions (roles), specially for tickets. Like I could name QA and management persons that are allowed to close tickets that are sent to qa state. I was going to reply to you point by point, but instead I'll just say that we do the majority of those bullet points with Trac. We aren't doing multiple authentication yet, though there are plans to, and there's really nothing stopping anyone else from doing that. In fact, one could write a single PasswordStore that simply tries a list of other PasswordStores in a specified order. The only other one we aren't doing anything with right now is #2, which I think is the most legitimate complaint here (I mean, they're all legitimate points, but most of them can be accomplished with Trac). I've played with Redmine, and there are a number of things that it does make easier, but a lot of it does not fit my needs. One thing Trac makes easier (and this may be partly due to the fact that it's written in Python, which I am more familiar with) is tweaking it to make it do exactly what I want. Well, I would be happy to hear what is needed to make those points work, even partially. Most critical being #1. I've played with Redmine a bit and it works very well with subproject things, simple cross referencing (same as MasterTicketPlugin) and it's very nice issue tracking system. But rest of Redmine is crap. And it's ruby thingy which is ugly itself. :D (That's about trashing Redmine). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from
[Trac] Re: Trac in trouble.
On Oct 1, 1:28 pm, Dimitri Maziuk [EMAIL PROTECTED] wrote: On Wednesday 01 October 2008 13:00:20 Jani Tiainen wrote: Reporter - Person who reported ticket (usually customer). Since we get reports by call/email this is more like free textfield. Manager - Person who is responsible in ticket general. Usually project manager. Assignee - Person who ticket is assigned to. Usually that poor developer or tester. Over here Poor Developer and Tester are two different people: developer has to test his fix, of course, but comprehensive testing to make sure the fix didn't break anything else is done by someone else. Also, public release is done when a fix is important, or there's enough minor fixes to warrant a release. Which is similar, but not entirely unlike a milestone: apart from triggering buzzwordiosyncrasy in half the people I know, milestone implies a goal set in advance. Dima -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison --http://www.bmrb.wisc.edu instead of CC, since we don't use email notification, we use the Keywords for this, and add the 3-letter designation of the person we have internally: ABC, Other Keywords. then our queries/reports use the Keywords containsdirective. We actually needed to do this since we have 1 external resource that doesn't have access to our system. the owner is then the manager or team lead reposible for getting his next set of tickets and source code drops via csv exports and zipped source releases via email, but that is another story..sigh. As for some of your other issues. A lot of these seem to be solvable in the Apache/subversion realm, rather than trac. For example the multiple projects related issues seem like they should be solved buy proper use of subversion externals, and allowing trac to browse externals. your post commit script needs to be a little smarter is all to update tickets on commits to those external repo's. The authentications are certainly solvable with apache. Good use of workflow and masterTickets would probably address a lot of your other issues. The final part might be to create a custom permissions plugin. someone reposted the how to a while back, I reposted it in this thread: http://groups.google.com/group/trac-users/browse_thread/thread/79b11813a0cd25ab/e1710f4f7dc76cf3?hl=enlnk=gstq=custom+permissions#e1710f4f7dc76cf3 I take no credit for that, and have not personally tried it on the latest version, but should work. you then can do even more customizations with the workflow because you have custom permissions :D finally, you might want to also look at privateTickets and, for me as important, the PrivateWiki plugins to addtionally shape who sees what information. Groups are your friends in all this if you have a lot of users. I really don't understand how you can have multiple owners of an issue. We have multiple parts of a ticket, which each part can be done by different people. in which case we address this by a combination of master tickets, and workflow, but the keywords (or some other custom field) can be used in the same way using the contains filter. I looked at redmine, and I liked it, out of the box as soon as I wanted to do more fancy things, I had bugzilla flashbacks and a migraine. Look at what the OForge and Agilo folks have done, simply awesome total customizations. This sounds a lot like I saw this really cool app, and it was written in Java, OUR app is now going to be in Java cuz Java makes it all COOL and EASY, when it turns out, not really, the devs were just really good at Java, and knew how to make the platform do exactly what they wanted and They made it cool while making it look easy. (not picking on Java here, just an example, although I have been know to Java bash :D ) The final piece here is, of course, whether or not it's YOUR job to IT/ Admin this, or just use the system that's in place. if you're the Ticket system administrator, you should have some say in the direction it goes, have your superior offload the responsibilities to another, or quit :D If it's somebody else' problem, great, let them live with it, then keep asking for features that you had/needed/liked/ gained efficiency with in Trac, if they deliver, great, if not, you can gripe why'd we switch again? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Noah Kantrowitz wrote: I have also explained many times on this list why we have put off multiple project support (including subprojects), but just for kicks: People are very quick to ask for multiple project support, citing tools like GForge or Redmine that can do it so it must be easy. This fails to take a very important part of the Trac philosophy into mind; we go as far as humanly possible to not enforce any project management philosophies on the end user. The fundamental problem with mutli-project support is that if you ask 10 people what they want from it, you get back 10 different critical feature lists. This leaves us in a quandary. Constructing a single design that allows all of those styles is incredibly tricky and not something that can be done overnight. If someone has suggested such an overarching design, I have yet to see it. The simple solution to this for right now is to leave multiple project handling in the domain of plugins and scripts for right now. This means each plugin can experiment design-wise without impacting the users of another plugin. Over time I suspect we will see a small number of these plugins become the de-facto standard, and then at that point it is much easier to talk about integrating the few winning designs into Trac core. So, in short, if you think mutli-project support is easy and know how it should be done, go prove me wrong. Really, I won't be offended. Make something that everyone acknowledges is The Right Way To Do It and we can move forward, but without that we have bigger fish to fry. Interesting. I didn't realize it was so controversial! It seems to me that implementing http://trac.edgewall.org/ticket/1048, which is basically my suggestion from http://lists.edgewall.com/archive/trac/2005-May/002932.html, and the leading suggestion from #130 as well, would be easy and would satisfy at least some of these requirements, without precluding other different multi-project models -- so IMHO it escapes your quandary about needing one overall architecture that satisfies all comers. Also doing this in a plug-in is quite difficult. I guess I just don't see the downside to adding a Project table and related fields. (And btw this is exactly how Redmine does it; see http://forge.typo3.org/repositories/entry/team-forge/redmine/db/schema.rb). Quoting from that email: ... a good way to do this would be to continue to use a single sqlite database, but add a Projects table, and a 'project' field to tickets, versions, milestones, and anything else that's per-project. The default project (project id 0) could be the null project for compatibility, then anyone not using this feature would see no change. The Projects table could specify repository subdirs for each project; in our case they'd all be the same (top-level). Then just tweak a bunch of sql queries to use the proper Project where needed. Later on ticket model changes could allow tickets to be part of multiple projects if desired and so on -- that part is easily handled by a plugin. -- . . . . . . . . . . . . . . . . . . . . . . . . . Gary Oberbrunner[EMAIL PROTECTED] GenArts, Inc. Tel: 617-492-2888 955 Mass. Ave Fax: 617-492-2852 Cambridge, MA 02139 USA www.genarts.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
-Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gary Oberbrunner Sent: Wednesday, October 01, 2008 12:50 PM To: trac-users@googlegroups.com Subject: [Trac] Re: Trac in trouble. Noah Kantrowitz wrote: I have also explained many times on this list why we have put off multiple project support (including subprojects), but just for kicks: People are very quick to ask for multiple project support, citing tools like GForge or Redmine that can do it so it must be easy. This fails to take a very important part of the Trac philosophy into mind; we go as far as humanly possible to not enforce any project management philosophies on the end user. The fundamental problem with mutli-project support is that if you ask 10 people what they want from it, you get back 10 different critical feature lists. This leaves us in a quandary. Constructing a single design that allows all of those styles is incredibly tricky and not something that can be done overnight. If someone has suggested such an overarching design, I have yet to see it. The simple solution to this for right now is to leave multiple project handling in the domain of plugins and scripts for right now. This means each plugin can experiment design-wise without impacting the users of another plugin. Over time I suspect we will see a small number of these plugins become the de-facto standard, and then at that point it is much easier to talk about integrating the few winning designs into Trac core. So, in short, if you think mutli-project support is easy and know how it should be done, go prove me wrong. Really, I won't be offended. Make something that everyone acknowledges is The Right Way To Do It and we can move forward, but without that we have bigger fish to fry. Interesting. I didn't realize it was so controversial! It seems to me that implementing http://trac.edgewall.org/ticket/1048, which is basically my suggestion from http://lists.edgewall.com/archive/trac/2005-May/002932.html, and the leading suggestion from #130 as well, would be easy and would satisfy at least some of these requirements, without precluding other different multi-project models -- so IMHO it escapes your quandary about needing one overall architecture that satisfies all comers. Also doing this in a plug-in is quite difficult. I guess I just don't see the downside to adding a Project table and related fields. (And btw this is exactly how Redmine does it; see http://forge.typo3.org/repositories/entry/team- forge/redmine/db/schema.rb). And, as many people have noted in this thread, redmine is generally quite inflexible. There is always a downside to everything, adding more code is a higher maintenance burden if nothing else. I do agree that I think that model is a step in the right direction for single-environment mutli-project, but it isn't the full picture (yet). --Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
Noah Kantrowitz wrote: And, as many people have noted in this thread, redmine is generally quite inflexible. There is always a downside to everything, adding more code is a higher maintenance burden if nothing else. I do agree that I think that model is a step in the right direction for single-environment mutli-project, but it isn't the full picture (yet). OK, how can I help get trac to the full picture? I'm willing to invest some time, because otherwise we will have to switch away from Trac and that itself will cost me some time. -- Gary --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
-Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gary Oberbrunner Sent: Wednesday, October 01, 2008 1:43 PM To: trac-users@googlegroups.com Subject: [Trac] Re: Trac in trouble. Noah Kantrowitz wrote: And, as many people have noted in this thread, redmine is generally quite inflexible. There is always a downside to everything, adding more code is a higher maintenance burden if nothing else. I do agree that I think that model is a step in the right direction for single-environment mutli- project, but it isn't the full picture (yet). OK, how can I help get trac to the full picture? I'm willing to invest some time, because otherwise we will have to switch away from Trac and that itself will cost me some time. Well work that idea out in more detail. How do you share things, and how do you not share things. Things like plugins probably have to be global just as an implementation detail, but what about other stuff. User preferences should be shared between projects? Etc etc. What about UI, how do you handle submitting a new ticket. Start writing up use cases from other multi-project systems, and showing how to implement them (what options to set) in this model. --Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac in trouble.
rupert thurner wrote: On Oct 1, 4:25 pm, Robert C Corsaro [EMAIL PROTECTED] wrote: Erik Bray wrote: Trouble #1: Partially open environment. Recently there has been increasing need to have private and public parts of same project. Public part would be open for end users and developers, private part is for developers only. There must be way to cross reference these (see trouble #2). This also includes authentication from several sources. First ldap if user is found, if not some other mechanism that allows user self registering. We use apache to do multiple source authentication. If you hate http basic auth, you can use the AccountManagerPlugin to put a form based auth over it. The way it works is that you give it a url that uses basic auth. When you submit the login form, it uses urllib2 to check against the specified url. This gives you all the performance benefits of apache's more mature code, like it's ldap caching for instance. If you would like an example apache config, just ask. it would be nice if you could post it.Of course. I wrote this a while ago. Tell me if any of it doesn't make sense or if information is missing. http://code.optaros.com/trac/oforge/wiki/OForgePermissions --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
