Hello, On Mar 9, 2010, at 15:22 , Andreas Jellinghaus wrote: > here is my position on each issue: > * mailing lists: I don't see a big benefit from having one list > instead of two. Thus I would like to keep thinks as they are, > as it will confuse users and require lots of reconfiguration > if we change things (e.g. mail2news at gmane, the mail filters > everyone has in their email client, etc.) One option, as said, was "direct people to opensc-devel from some time onwards". OpenSC et al don't have such a huge userbase and a solid development/user separation that the artificial separation between two lists would do any good. The goal would be to guide traffic to the most viable list.
> * documentation: I think we need documentation with each package. > currently we do that using a wiki for each project. if we move > towards a central wiki, then we still need documentation for each > project, for example docbook files inside the source. (not sure if > there is a better alternative to writing documentation with > docbook-xml, I'd be happy about comments and suggestions...) Sure. What kind of documentation? "Free form documentation" like wiki will of course remain. How doxygen or manpages are maintained in a separate source tree is outside of the scope of my intentions (except that if it is available, the output shall be published on the web and referred to from the wiki) > * we also need a source code viewer for each project, a source code > repository, and a bug tracking system. we could do that with trac, > and our current svn repositories. Source code viewer is a nice thing, a repository is required. Bug tracking has shown to not work. Initially, years ago, when trac was put in place, I said that "we need bug tracking" as there was none. The idea of a "subproject bug tracking" has not worked out well (or at all). I thus I don't agree. I don't believe that opensc-project.org should be a dysfunctional sourceforge or apache foundation clone, it needs to provide the infrastructure needed to push out packages under "OpenSC" umbrella name that allows the users to "do stuff with smart cards". In trac terms, components must be defined for all the subprojects and that's it. > but maybe we want to switch to something modern like git, and use gitweb > for source code viewing.we could use git with ssh and smart card > authentication that way. and there is a git shell to limit accounts to > using git only, so no security issue here. I'm not talking about a revolution here but simple short term evolution of the current situation. We don't really need link level strong authentication to access an open source code repository. "Eating our own dog food" can be accomplished by signing the changes by some means or by signing releases etc (Yes, git provides signed tags but that's not really necessary by itself either) Somebody in Estonia once said: "How the fsck am I supposed to file a bug that my id-card is not working if the bug tracker requires id-card authentication???" (as this was/is the setup) > for the bug tracker, why not switch to bugzilla? this can handle many > projects in one instance fine (but I'm not sure about trac - I thought > versions are global, even if you have components, so it wouldn't suite > us). bugzilla has the advantage of requiring registration, so we would > have an email address we can respond to. and there is testopia, a plugin > for setting up test procedures, which might be nice! Have you *really* *used* bugzilla? If you want features, separation, ultrareports and whatnot, I would suggest Jira instead. There's one goal Trac sets right: "Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies." There are two different approaches to issue tracking: 1. Keep track of open issues with the goal of eventually fixing them ASAP 2. Keep track of open issues with the goal of keeping track of issues and generating reports. Approach 2 justifies itself in big corporate settings but not in the size and scale and (hopefully) spirit of OpenSC. > * wiki: why stay with trac? if we want to move to a new wiki, which replaces > the old wikis and the current web page, we can choose any wiki. what is the > current suggestion for that? freedesktop.org uses moinmoin for example, > other people use mediawiki, or twiki or dokuwiki or ... ? Because there's a lot of content already in trac. Even though there are arguments that "things that try to do everything" are worse than separate specialized tools, what IMHO don't apply here. I might be exaggerating but I believe that trac is the most popular project environment for open source software, for a reason. And because the resources to work with trac exist (me) but the resources to change the software and setup to a 100% new platform does not exist. Also see above, your own arguments against retiring opensc-user. > I like the trac syntax. but better spam prevention etc. would be nice, and > we would only need a wiki, not all the other stuff. If trac is maintained it needs minimal effort to keep it spam free. The problem with all the mini sub-tracs is that nobody cares to deal with them. >> - Remove outdated static html content on opensc-project.org > > well, not everything is up-to-date. but in general I think we should have > all that content: project decriptions, download links, a news section, > history of the projects, contact information, faq. Yes, this type of information must be prominently presented to the visitor. > so if we move to a wiki, we need all that. sure, we can update it, improve > it and so on. but in general it should not be lost. It will remain in svn. -- 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
