Changes between Version 3 and Version 4 of TracMultipleProjects/ByProductAndSearch

Timestamp:

Jun 29, 2005, 11:13:19 AM (19 years ago)

Author:

anonymous

Comment:

—

TracMultipleProjects/ByProductAndSearch

@@ -1 @@
-= Handling Multiple Products and Projects =
+= Handling Multiple Projects =
 
 We have been looking very closely at Trac and how we would use it in a multi project environment.  Our conclusions are a little different to any of the proposals made so far.  The Trac philosophy is to keep things as simple as possible while preserving flexibility and that is what we are trying to do.
 
-We have a large code base.  Much of that code is shared among a large number of products.  There is also a complex relationship between projects and products.  For example, a project may change common code and result in several product releases.  In other cases there is a one to one product/project mapping.
+We have a large code base.  Much of that code is shared among a large number of projects.  There is also a complex relationship between projects and milestones.  For example, a milestone may change common code and result in several project releases.  In other cases there is a one to one milestone/project mapping.
 
-What the above means is that the relationship between a project, products, timeline etc. can get quite complex.  The issue is how to deal with that while providing a clean and understandable system which normal people can cope with.  Neither of the other proposals for handling this (TracMultipleProjects/MultipleEnvironments and TracMultipleProjects/SingleEnvironment) deal with this complexity.  We believe that TracMultipleProjects/MultipleEnvironments is a non-starter for this.  There are some good ideas in TracMultipleProjects/SingleEnvironment which are extended by this proposal.
+What the above means is that the relationship between a milestone, projects, timeline etc. can get quite complex.  The issue is how to deal with that while providing a clean and understandable system which normal people can cope with.  Neither of the other proposals for handling this (TracMultipleProjects/MultipleEnvironments and TracMultipleProjects/SingleEnvironment) deal with this complexity.  We believe that TracMultipleProjects/MultipleEnvironments is a non-starter for this.  There are some good ideas in TracMultipleProjects/SingleEnvironment which are extended by this proposal.
 
-We are going to define some terms so as to minimise confusion:
+Requests like the one in #1048 and #586 are too simplistic as they only address multiple projects which have nothing in common.
 
- * Product: An item which is shipped to customers
- * Project: A body of work which goes into products
+== Trac Data ==
 
-We need to support multiple products and multiple projects.  It is our
-view that projects map onto milestones which is very convenient as
-multiple milestones are already in Trac.  This is the first big difference between this proposal and TracMultipleProjects/SingleEnvironment - the main selector is a product and not a project (I understand that this could be controversial so it would be a good idea to allow this to be configurable between product and project).
+Gary Oberbrunner made these suggestions on the mailing list:
 
-Requests like the one in #1048 and #586 are too simplistic as they only address multiple products which have nothing in common.
+ * a new table, "project", looking like this:
+{{{
+    id          integer PRIMARY KEY,
+    name        text,
+    description text
+}}}
+ * make tickets, milestones, and wiki entries (and maybe components?) have a project id, so for instance you could have project "A" with milestone "v1.0" and project "B" with milestone "v1.0" but they are distinct milestones.
+ * the default project ID, 0, means "no project", i.e. current behavior.
+ * update various pages and sql queries to allow project selection, i.e. "where project_id = selected_project_id" or sometimes "where project_id = selected_project_id or project_id = 0" to also show the default (non-project-specific) items.
+ * add a new page for project maintenance (create, update, delete) (Or do it via trac-admin)
 
-The bit which is harder is how to support multiple products.  We believe
-that the following is required:
+We would like to extend this so that:
+
+ * Milestones can be linked to more than one project.  This would require an extra table to link milestones and projects.
+ * Milestone names would live in a flat namespace because of the above.  I.e., Garys milestone naming proposal only works if there is a one to one relationship between project and milestone.
+ * Queries should support selecting multiple projects.
 
 == Ticket Changes ==
 
- * A product field drop down list.
- * A product version field drop down list which depends on the product field (i.e., each product has it's own set of versions).  The current version field would become this field.
- * The existing component field has to be dependent on the product.  Each product will have it's own set of components.
- * The milestone field also has to be dependent on the product (selecting a product would only show milestones which are relevant to that product)
+ * A project field drop down list.
+ * A project version field drop down list which depends on the project field (i.e., each project has it's own set of versions).  The current version field would become this field.
+ * The existing component field has to be dependent on the project.  Each project will have it's own set of components, or, the component field could be optional so that those with multiple projects can remove it.
+ * The milestone field also has to be dependent on the project (selecting a project would only show milestones which are relevant to that project)
 
-Somehow milestones have to be associated with products (maybe more than
-one product).  Adding a milestone would entail selecting a list of
-products affected by that milestone.
+Somehow milestones have to be associated with projects (maybe more than one project).  Adding a milestone would entail selecting a list of projects affected by that milestone.
 
 == Timeline ==
 
-We don't believe that there is a simple relationship between a product
-and a timeline.  We think that instead of switching the timeline based
-on the selection of a product that there should be query support added
-to the timeline page.  These queries should allow the user to select a
-number of paths into the subversion repository to select repository
-checkins, a product choice to select tickets and milestones, and a Wiki
-path (or number of Wiki paths) to select Wiki pages (see Wiki section
-below).  These queries should also be saved so project teams can build
-reports which are useful for their project.  Using these queries most
-users requirements should be covered.  Maybe the queries should be saved
-by product or milestone - that would be good but not strictly necessary.
+We don't believe that there is a simple relationship between a project and a timeline.  We think that instead of switching the timeline based on the selection of a project that there should be query support added to the timeline page.  These queries should allow the user to select a number of paths into the subversion repository to select repository checkins, a project choice to select tickets and milestones, and a Wiki path (or number of Wiki paths) to select Wiki pages (see Wiki section below).  These queries should also be saved so project teams can build reports which are useful for their project.  Using these queries most users requirements should be covered.  Maybe the queries should be saved by project or milestone - that would be good but not strictly necessary.
+
+In an ideal world there would be a way to link subversion commits to a project.  This could be done using the bugtraq string which TortoiseSVN adds to a commit.  The bugtraq id links to a ticket which is against a project.  Perfect timelines then!  The downside of this is that *every* commit *has* to specify a ticket.  The Trac code which indexes repository revisions would have to search commit messages for the bugtrac id and link it to the ticket.  I guess Trac could then log the commit in the ticket as well.
 
 == Roadmap ==
 
-This is rather simpler than for the timeline.  Given that there needs to
-be a defined relationship between products and milestones selecting a
-product should be all that is needed.
+This is rather simpler than for the timeline.  Given that there needs to be a defined relationship between projects and milestones selecting a project should be all that is needed.
 
 == Browse Source ==
 
-No need to change anything here as it is and should remain a view of the
-entire repository content.
+No need to change anything here as it is and should remain a view of the entire repository content.
 
 == Wiki ==
 
-I think that by using the subpages or whatever it is you call pages
-which have a path (like !TracDev/...) with the project name at the top
-level would neatly support multiple project documentation.  The query
-for the timeline would use this path name to select product
-documentation changes.
+I think that by using the subpages or whatever it is you call pages which have a path (like !TracDev/...) with the project name at the top level would neatly support multiple project documentation.  The query for the timeline would use this path name to select project documentation changes.
 
-== Tickets Affecting Multiple Products ==
+== Tickets Affecting Multiple Projects ==
 
-Ticket #130 talks about assigning one ticket to multiple products.  I believe that this would be complex and prone to error.  It is very difficult to know which products a piece of common code will affect.  It would be very useful to be able to have tickets depend on other tickets (see ticket #31) so that as problems are found on different products which are caused by common code they can be linked to a single ticket.
+Ticket #130 talks about assigning one ticket to multiple projects.  I believe that this would be complex and prone to error.  It is very difficult to know which projects a piece of common code will affect.  It would be very useful to be able to have tickets depend on other tickets (see ticket #31) so that as problems are found on different projects which are caused by common code they can be linked to a single ticket.