Project status
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
Re: Project status
by Vlad Skvortsov
::
Rate this Message:
FWIW, this is a brief list of requirements/expectations that I pose on
such a system. I just want to emphasis that my primary environment is FreeBSD/MacOS/Linux, so this might be a little bit skewed. As for the scale, I expect the system to be sufficient for small groups of developers. My main requirement: the system should be self-contained. If required, one should be able to update issues as simple as editing text files with any ASCII text editor and commit the changes / get updates with 'svn' (with currenly available systems, I find myself uncomfortable working on a plane since crucial part of the information I need is only accessible through the web). Since svn allows 'disconnected' operation, the issue tracking system (which contents are closely related to the code stored in svn) should also allow such mode of operation. There should be no 'single point of control' for the issues database. Under this I mean that most existing systems (well, the ones I've seen) pose themselves as the only gateway to access the data. If the web server with such a gateway (in a form of GUI) goes down, you're screwed up. We do already have one bottleneck (subversion server) and I don't see a reason to add another one. This leads us to the architecture that is built on several "applications" dealing with their own working copies of the issues database and a subversion server as a datasource. One application might be a web frontend to the system (and there might be another backup one, etc). Another application is a backup system that just makes 'svn up' in remote location. The third one might be an e-mail integration application (sending updates to specific addresses and/or updating issues by attaching arriving mail). Other 'applications' are sets of scripts on developers' desktops dealing with issues in their working copies directly. Here we come to the problem of database consistensy in terms of metadata and business logic in different points of execution within such distributed system. This is vague for me yet, but I'd say that the goal is to make these rules declared, not hardcoded, and stored right with the issues data so that different implementations of the 'applications' deal with the data in consistent way. Still much to think about. Wherry, Matt wrote: >BTW: > >If the issue of interest here is subversion integration, rather than some of the more esoteric or useful planned features, has anyone had a look at trac? > >http://www.edgewall.com/trac/ >http://www.edgewall.com/trac/license.html > >The Scipy and numpy guys seem to be using it in conjunction with svn to some success. To see it in action, see http://projects.scipy.org/scipy/scipy. > >It looks nice. Simple. Nice. > >M > >-----Original Message----- >From: Wherry, Matt >Sent: 08 May 2006 11:15 >To: dev@... >Subject: RE: [subissue] Project status > > >I'd also like to contribute, but I've a lot of time commitments ( No work time allocated, and 3 kids at home ), although if there's anything low load, I'd be happy to pitch in. > >M > >-----Original Message----- >From: Jean-Louis JUAN [mailto:jean-louis.juan@...] >Sent: 04 May 2006 12:42 >To: dev@... >Subject: Re: [subissue] Project status > > >Hello, > >As I see, we are all interested by this project and waiting that someone >to lead it !! >Can anyone take the "responsability" or do we need to reach the main >leader ? > >Are we enough members to do the job ? > > >Juan Heyns a écrit : > > >>I would also be interested in being involved. I had a lot of hope for >>this project but are disappointed by the current thread of messages I >>have in my mailbox. >> >>Ciao >>Juan >> >> >> >> >> >>>>>Cage Jonathan <JCAGE@...> 05/04/06 10:32 am >>> >>>>> >>>>> >>I too have been watching this one and was disappointed to learn of >>it's demise. If either of you _do_ start something off I would be >>interested in >>collaborating as well. >> >>Cheers, >>Jon >> >>-----Original Message----- >>From: drew@... [mailto:drew@...] >>Sent: 04 May 2006 02:54 >>To: dev@... >>Subject: Re: [subissue] Project status >> >>* Vlad Skvortsov (vss@...) wrote: >> >> >>>Drew Myers wrote: >>> >>> >>> >>>>Hi, >>>>I'm new to the list, as I just found this project listed on tigris. >>>>After looking through the mail archives though, it appears this >>>>project >>>>is no longer active. Is that accurate? >>>> >>>> >>>I've been watching this for quite a long time, but it seems there is >>>no movement. So I've started my own implementation of similar idea. >>> >>> >>Do you want some help? Is it hosted anywhere? This is truly >>something I think is worth doing, and will probably implement it >>myself if I can't >>find another project already in-progress. >> >>Thanks, >> >>drew >> >> > >This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. > >Danish - Deutsch - English - Español - Français - Italiano - Japanese - Nederlands - Norsk - Portuguese - Svenska: www.cardinalhealth.com/legal/email > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscribe@... >For additional commands, e-mail: dev-help@... > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscribe@... >For additional commands, e-mail: dev-help@... > > > > -- Vlad Skvortsov, vss@..., vss@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Project status
by Drew Myers
::
Rate this Message:
I agree with Vlad in that whatever solution we develop, it definitely
should not be dependent upon a single client interface. Ronny and I have spoken a bit via email about this topic. As an example, TortoiseSVN already handles some degree of issue tracking, when the issue tracking is done via a set of rules they've set forth. While TortoiseSVN is significant, and perhaps one of the most popular clients for Subversion, I still think Vlad is right...the issue tracking should not be limited to a single interface. However, I'm not sure that extends to administration of the issue-tracking system. If the administrative interface to 'subissue' is web-based, but various clients can interact via some issue-tracking API, with all the metadata stored within the subversion repository itself, then, to my mind, that's a clean solution. You may disagree. If you haven't seen the spec the TSVN guys have laid out, here's a link: http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch05s24.html If nothing else, perhaps this will give us some solid grist for the mill :). drew -- Never offend people with style when you can offend them with substance. - Sam Brown, Washington Post, 1977 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Project status
by Felix Collins-2
::
Rate this Message:
Wherry, Matt wrote:
> BTW: > > If the issue of interest here is subversion integration, rather than some of the more esoteric or useful planned features, has anyone had a look at trac? Yep, I am using it in a medium scale enterprise. See my email of the 8th. Regards, Felix --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Project status
by Jean-Louis JUAN
::
Rate this Message:
Vlad Skvortsov a écrit :
> FWIW, this is a brief list of requirements/expectations that I pose on > such a system. It seems that some of yours requirements are already presents in the initials goals of subissue. But I am completly agree with your point of view. As a quality engineer, I expect from subissue to reach a maximum of the goals defined by the CMMi (process area CM): tracking the bugs and issues is one of the major requirements. [jean-louis.juan.vcf] begin:vcard fn:Jean-Louis Juan n:Juan;Jean-Louis org;quoted-printable;quoted-printable:AtosOrigin Syst=C3=A8me Int=C3=A9gration;Cellule Qualit=C3=A9 adr;quoted-printable;quoted-printable:BP 475;;1, Rue Amp=C3=A8re;Lab=C3=A8ge Cedex;;31315;France email;internet:jean-louis.juan@... title;quoted-printable:Ing=C3=A9nieur Qualit=C3=A9 tel;work:05.61.39.24.30 tel;fax:05.61.19.16.65 note;quoted-printable:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A= Ce message electronique est confidentiel. Il peut contenir des=0D=0A= informations protegees par le secret professionnel, le secret de=0D=0A= fabrication ou autres regles legales. Si vous recevez ce message par=0D=0A= erreur, il vous est interdit de le reproduire ou de le distribuer en=0D=0A= tout ou en partie, ou de le divulguer de quelque maniere que ce soit a=0D=0A= quelque personne que ce soit. Nous vous prions de bien vouloir en=0D=0A= informer Atos Origin, par telephone ou par retour d'e-mail puis de=0D=0A= detruire le message et toutes copies de votre systeme informatique. Le=0D=0A= contenu de ce message ne reflete pas necessairement ni les opinions=0D=0A= d'Atos Origin ni celle des membres de son groupe. Bien que l'emetteur=0D=0A= de ce message ait fait tout son possible pour maintenir son systeme=0D=0A= informatique sans virus, il ne peut garantir que cette transmission ne=0D=0A= comporte aucun virus et il ne pourra etre tenu pour responsable de=0D=0A= quelque dommage que ce soit resultant de la transmission d'un virus.=0D=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A= This electronic transmission is confidential. It may contain=0D=0A= information that is covered by legal professional privilege, work=0D=0A= product immunity or other legal rules. If you have received this=0D=0A= transmission in error, you must not copy or distribute this message or=0D=0A= any part of it or otherwise disclose its contents to anyone. Please=0D=0A= notify Atos Origin Legal Services by telephone or return E-mail, and=0D=0A= then delete this transmission and any copies of it from your computer=0D=0A= system. The views expressed in this electronic transmission do not=0D=0A= necessarily reflect those of Atos Origin SA or any member of its group.=0D=0A= Although the sender endeavours to maintain a computer virus free=0D=0A= network, the sender does not warrant that this transmission is virus=0D=0A= free and will not be liable for any damages resulting from any virus=0D=0A= transmitted.=0D=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D version:2.1 end:vcard --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Project status
by Vlad Skvortsov
::
Rate this Message:
Drew Myers wrote:
>I agree with Vlad in that whatever solution we develop, it definitely >should not be dependent upon a single client interface. > >Ronny and I have spoken a bit via email about this topic. As an >example, TortoiseSVN already handles some degree of issue tracking, when >the issue tracking is done via a set of rules they've set forth. While >TortoiseSVN is significant, and perhaps one of the most popular clients >for Subversion, I still think Vlad is right...the issue tracking should >not be limited to a single interface. > >However, I'm not sure that extends to administration of the >issue-tracking system. If the administrative interface to 'subissue' is >web-based, but various clients can interact via some issue-tracking API, >with all the metadata stored within the subversion repository itself, >then, to my mind, that's a clean solution. You may disagree. > > for different groups of users. The only way to control access to data is to direct it through single gateway that enforces policies established. The 'administrative interface' in this case is the control interface for such a gateway. In my model data is distributed between different consumers (by the means of svn) thus the only point of control is the repository itself with its hooks. I believe that administrative settings (ACLs, user roles, etc) should be kept in a repository as well and be enforced by hooks dealing with the same repository. So if one needs, any number of administrative interfaces could be built within the same model: those will access data in the same repository (provided having enough permissions, enforced by repository hooks). So, may be what I thought of doesn't fit into others' mode of operation regarding the business logic of issue tracking system. My focus is currently on small groups (because my group needs that) that can just hack administrative settings with 'vi' and do not need any administrative interfaces *for now*. This is according to the general engineering philosophy that I stick with: "Build something small that works, then try to scale." Anyway, it seems that the project founder wants to get back to Subissue some time in the future, so there are too many cooks in the kitchen, probably... >If you haven't seen the spec the TSVN guys have laid out, here's a link: >http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch05s24.html > >If nothing else, perhaps this will give us some solid grist for the mill >:). > > >drew > > -- Vlad Skvortsov, vss@..., vss@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
