On Mar 11, 2010, at 09:35 , Peter Stuge wrote: > Andreas Jellinghaus wrote: >> I'd prefer a software with user registration/email verification >> these days > > I don't know why email verification isn't working in the > opensc-project.org Trac, but it works well in some Tracs I run. :\ It worked for me, but required a fresh session to be finally accepted as a verified e-mail. Needs investigation.
> Andreas Jellinghaus wrote: >> how should that documentation be written and maintained, if you >> implement your plan with the new trac/wiki? > > One idea is to have $projectname/$pagename wiki pages in a single > Trac. Then you can also search all of them at once. :) That's exactly what I had in mind. > Martin Paljak wrote: >>> so if people file a ticket in "opensc" trac for "libp11" component, >>> with a bogus version, as they cannot select the libp11 versoin, that >>> will be easier than doing the same thing in the "libp11" trac? >> >> Uh. There's no versioning information set for libp11. > > I think this is a good point by Andreas. I think the version > information can be helpful. Of course. The questions is how and where this information is kept in such a combined situation. For example, tags have already been used by people to add extra information to tickets. (see the Tags tab on trac) > I know it feels a bit awkward maybe, but versions can also be >> recorded in keywords. > > True, but it's *a lot* nicer to have a dedicated, clearly labelled, > field for it. Then it might actually be filled out correctly > sometimes. True. Version tag can be constructed like libp11_1.2.3 for example. I don't think that a long list of ancient versions for a package serves any purpose (as there currently is). Maybe there's a plugin for a "component versions" or "versioned components" needs as well. > In real life a bug with some version of open source software is >> replied with: Did you try with the latest version? Did the problem >> go away? Yes - problem solved and nobody cares about the version >> (as the default answer is always "it is fixed in latest version") >> No: version does not matter, as the bug is probably present up to >> the latest version. > > This is true as far as the developers in the project are concerned, > but it is a nice service for the packagers and users to have accurate > information about which bugs were fixed in which version. > > Maybe someone can't upgrade right now for whatever reason and need to > know about some particular bug. True. This can be achieved by a) known issues list for a release and/or b) list of fixed bugs for succeeding releases. This information is not lost. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
