Am Dienstag 09 März 2010 14:58:41 schrieb Martin Paljak: > 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.
not sure how many discussions on -devel are interesting for pure users. > 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) more or less everything we have in the wiki. maybe we can remove a bit of the stuff in opensc wiki, but in other wikis, there is no unneeded content. for example: complete and detailed copyright/author/contributor lists. quickstart, overview, list of supported readers/cards with details and so on. trac has a plugin to export pages as docbook. maybe that can help such a migration? http://trac-hacks.org/wiki/Page2DocbookPlugin > 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'm also ok with removing bug tracking. > 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. well, we can keep it simple, like freedesktop.org for example - a wiki as frontpage (they use moinmoin), a git or svn web page (they have cgit and websvn) etc. ah, I see some projects have their own wiki at http://project.freedesktop.org/, and their files are published with standard http at /releases/ not sure how they manage their file space (i.e. how the release manage pushes a tar.gz to their web page). I'm not proposing to clone sourceforge or something like that, opensc is a simple web page, and that is good. it works well, and nearly everything can be done by several people - no single point of failure. whatever changes we choose to implement, I would like to keep it that way (that at least two people can do everything, thus we have no central point of failure). > I'm not talking about a revolution here but simple short term evolution of > the current situation. well, if we change things, we can discuss svn or git or ... too, if people feel we could improve things. I wouldn't start using svn today with all the distributed version control systems we have now. on the other hand I don't want to force such a change, unless people are interested too. at least for me a dcvs would simplify development. the ssh suggestions was meant in a "eating our own dog food" way, and will most likely cause a lot less problem than our current https/client cert setup. using passwords on http(s) is an option, but not very good from a security point of view. [bugzilla bashing] if we use a bug tracker, I don't care much if it is bugzilla or something else, but I would like the usual email verification thing to keep out spammer and have some working email address to contact. trac doesn't do that, bugzilla was simply the first thing to come to my mind. > >> - 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. so what do we want exactly? * disable all the bug trackers? fine with me. * move documentation from trac wikis to each project as text/docbook/whatever? fine with me. but that isn't much help, unless someone has time not only to convert the existing documentation, but to improve it too. * install a new source code browser? well, if we want to have one, but get rid of each projects trac instance, we have to install something new as long term replacement. * make each trac read-only? well, that solves the spam issue, and we can keep the tracs till we are 100% sure we don't need them any more. but it doesn't improve anything much per se. * create a new central wiki to replace the static web page? well, fine with me. not sure why you insist that much on trac (well, trac but stripped down to be a wiki only), and i would favor some wiki with user validation (email/password/captch-whatever) to keep out spam. but if trac is the fast and easy way to do that, fine with me too. but that too is only usefull, if the content of the central web page is improved. installing some software and converting the current text is the small part I guess, so if you want to spend time on a much better web page, it is only fair that you can choose the software you find easiest to use. * I brought up the possibility of using git (or something else) instead of svn. no necessary change, if people want that, we can do that. if not, we keep things as they are. (not 100% sure how the latest apache/ssl changes affect us, if more people hit problems with ssl / renegoniation, we will need to move from client cert auth to http(s) with user/password for authentication.) I re-read your first email, and I'm mostly worried that changes could lead to information lost. I don't care about the tickets, but I care about the information in our wikis and on the web page. sure, most of it isn't up-to-date or polished. but "consolidate trac instances" could be a hell lot of work, if all information is migrated to a new trac wiki or to per-project documentation. I don't want to see past work on that content lost, even if it isn't up to date. our big problem is that few work is done on the documentation (central web page and per project trac), and I don't see how that re-organisation will change that. everyone can edit the wiki pages and all developers have write access to web svn so they can edit the central web pages too. but if you want to spend time on it, I'm all for that, and welcome whatever direction you take. but the result needs to be at least as good as the current state - which isn't great, but not exactly terrible either from my point of view. outdated and maybe plagued by spammers, but at least has a lot of basic information. > 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. I removed the spam quite fast, even before your first email on opensc-devel. so what is your issue here? I get emails for ticket changes and new user registration. if we could get email for wiki changes too, it would be quite easy to see if there is spam, and delete/undo those changes even faster. any idea if there is an option or plugin to get wiki changes as email with a diff? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
