Hi Kristis, Glad you like my proposal :-). I'll make my reply in two parts, first the reasons by which I'd like it to be this way (so it's easier to follow the needs) and then the way I think this new feature should/could/would be cool to behave.
Is it necessary to see this information "in the bugtracker" ? Well, it is in my case because of the way we work; I don't know whether other offices organize themselfes us we do, but I guess it shouldn't be uncommon. Here we have two main teams: devolopers and consultants. We developers do what we're meant to do, while consultants are the ones whoe keep contact with end-users. They know what the application should do at every single case, no matter how weird that case is, and they know the needs and desires of end-users; however, they don't have any inner-computer knowledge. When consultants discover a bug to be fix or a new feature to be implemented they inform us through Mantis (making them use Mantis was a great PITA, so we try to pass everything through it). After we're done with the issue it's time consultants test it, and here comes the main dish. To avoid interferences we have different servers for developers and testers. We don't want the test server to be updated every two days by whichever developer thinks his issue is developed (in fact, not every developer has access to the test server), instead we update it in a regular basis (usually once a week) and tag the published version as a test version. Now consultants need to know which issues' fixes are already available for testing, and I thought adding notes to issues related with tagged files would be an easy, quick, automatic and difficult-to-mistake way. Now the second part, behavior. I don't think it's necessary to find out which files have changed nor which the previous tag was. In the very momment a commit is performed you know: 1) the file(s), 2) it's version(s) and 3) the issue(s) it's related with. I assume this information can be stored or easily retrieved later on, so recovering the example I first stated: After 1st commit file1.txt, version 1.1 file2.cpp, version 1.10, noted on bugs 820,815 file3.java, version 1.6, noted on bug 800 After 2nd commit file1.txt, version 1.1 file2.cpp, version 1.10, noted on bugs 820,815 file3.java, version 1.7, noted on bug 830 I would have the following data available <file, version, bug>: <file2.cpp, 1.10, 820> <file2.cpp, 1.10, 815> <file3.java, 1.6, 800> \ <file3.java, 1.7, 830> --> file3.java is related to bug 800 on its 1.6 version and to bug 830 on its 1.7 version. This would also reflect branches, since version numbers differ across them. Now, every tagging action is made upon <file, version> pairs. Provided I have the <file, version, bug> data, I can search the matching <file, version> pairs and get related bug numbers; this would take into account branches and file modifications. On the other hand, it's also true that unmodified files tend to accumulate tags, since we tag a whole set, and that would add a new note to related bugs every time we tag them, but I don't care about that (dunno if you guys know a reason to do, though). About renaming tags, I think we could follow the same procedure. When renaming a tag we know the affected <file, version> pairs, so we can add a new-tag note or a modified-tag note to related bugs. I hope this helped to clarify things. Regards, Abraham P.S.: Should I update bug 1174 myself with this info? Do I have proper perms? Abraham Marín Pérez <[EMAIL PROTECTED]> Responsable de I+D SILVANO CONSULTORES Tfno.: 93.412.79.12 -- Fax: 93.410.92.90 http://www.silvanoc.com/ Kristis Makris <[EMAIL PROTECTED]> 30/05/2008 20:35 Para: [EMAIL PROTECTED] cc: [email protected] Asunto: Re: [scmbug-users] Adding notes on "tagged" issues Hi Abraham, You ask a very good question. The information you want to see is certainly useful. http://bugzilla.mkgnu.net/show_bug.cgi?id=1174 Is it necessary to see this information "in the bugtracker" ? The short answer to your question is that it is not supported. The long answer is that it can be supported with a lot of work. The VDD Generator can produce such information. It produces it as a separate report. This report is not shown in the SCM system or the bugtracker. It is a separate document. Additionally, Robert has been making progress developing Web Reports that can produce various types of such information. Here are some thoughts. It is possible to support this information you are asking for. But it will require some effort as to include parts of the VDD Generator logic directly into the tagging hooks. The reason is that on tagging the glue must first discover the changes between releases (e.g. to determine in your example that only file2.cpp and file3.cpp were changed). Additionally, you assumed there is only one branch of development. It is possible that a file is changed on multiple branches (e.g. main development branch, maintenance branches, developer experimentation branches), committed against the same bug. Would having multiple such tagging comments on the same bug be acceptable for you ? Could it be confusing ? Also, you assumed that the previous tag can be easily detected (e.g. in the tagging operation). e.g MYPROJECT_BUILD_1_0 is the next tag of ... MYPROJECT_BUILD_0_9 ? MYPROJECT_RELEASE_0_5_3 ? Detecting the previous tag name could be automated somewhat, but it could be incorrect. E.g. the "last tag applied" may be a retagging of a much, much more previous tag (like what used to be a personal developer tag). Do you want to require the programmer to always supply the previous tag name in the log message when tagging ? That could be taxing on the developer, but possible. Also, some SCM systems, like CVS, don't provide support for supplying a log message during tagging. They would need special support from Scmbug to allow the programmer to specify the previous tag. This can be a lot of work. What if a tag is renamed ? Will we have to go back to the bug-tracker and find all those tag comments and change them ? That's a lot of work too, but it's possible. Given all this, what do you feel would be most useful ? On Fri, 2008-05-30 at 13:10 +0200, [EMAIL PROTECTED] wrote: > Hi everyone, > > I've been playing with scmbug for a while and noticed its great > potential. However, there's one very particular thing I'd love to do, > although I don't know whether it's sopported or isn't. Here I go: > > Let's take a project with three files: > > myProject/file1.txt, version 1.1 > myProject/file2.cpp, version 1.8 > myProject/file3.java, version 1.5 > > and let's say that, requested by some bugs, I modified a couple of them, > resulting on the following: > > myProject/file1.txt, version 1.1 > myProject/file2.cpp, version 1.10, noted on bugs 820,815 > myProject/file3.java, version 1.6, noted on bug 800 > > Commit message for version 1.10 of file2.cpp appeared as a note on bugs > 820 and 815, and so happend with version 1.6 of file3.java on bug 800. > Clear til here. > > Now I tag my project, lets call it MYPROJECT_BUILD_1_0. What I'd like is > adding a note stating this fact on bugs linked with the versions of the > tagged files. In other words, having the stated, an "Included in > MYPROJECT_BUILD_1_0" note should appear on bugs 800, 815 and 820. > > And yet more complicated, that note is to be added only to bugs linked > with actual tagged versions. To ilustrate it with an example, let's say a > new bug is issued and file3.java is modified according to this, so the > project state now is: > > myProject/file1.txt, version 1.1 > myProject/file2.cpp, version 1.10, noted on bugs 820,815 > myProject/file3.java, version 1.7, noted on bug 830 > > If I tag the project as MYPROJECT_BUILD_1_1, the notification should > appear in bugs 815, 820 and 830, but not in 800, since it corresponds to a > version of file3.java not included in current tag. > > > > So, after all this stuff, my question is: is this supported? and if it > isn't, could it be done without great pain? > > Best Regards, > > Abraham Marín Pérez <[EMAIL PROTECTED]> > Responsable de I+D > SILVANO CONSULTORES > Tfno.: 93.412.79.12 -- Fax: 93.410.92.90 > http://www.silvanoc.com/ > > _______________________________________________ > scmbug-users mailing list > [email protected] > http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
signature.asc
Description: Binary data
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
