On Mar 9, 2010, at 23:37 , Andreas Jellinghaus wrote: > Am Dienstag 09 März 2010 14:58:41 schrieb Martin Paljak: >> 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 Git gets one thing right (with signed tags): you don't need highly secured channels if the goals is validated data. You need to secure the data and it is OK to push the data even over untrusted channels.
SSL and reasonably secure passwords give the same result in this case. For authentication purposes - we can't authenticate web requests with SSH and we can't require client certificates from all visitors. > > [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. As suggested by Gregg, there's an alternative: Move to GIT, use github, keep opensc-project.org for maybe the list address (but it would be easier to use google groups) and for the wiki, github also provides something unless somebody wants to maintain a new wiki installation (and migrate the contents and so on). If taken as "functional units" it is really really easy to outsource the whole opensc-project.org and get rid of the maintenance requirement. Trac is a well working software that already has a lot of content, it only needs to be improved to make it work better for opensc, with the current setup, IMHO. >>> 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. Disable all but one bug tracker. Keep www.opensc-project.org/opensc/newticket, create components for smaller projects. > * 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. Move wiki content from other wikis to www.opensc-project.org/opensc/wiki (in a structured way) > * 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. In the long term? Probably ditch opensc-project.org and move to git/github. > * 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. After steps 1 and 2 are done, turn on read only mode to other tracks for a while, to keep the content online but to be sure there's no spam headaches or other similar issues. After a grace period close them or only leave svn browser visible. > * 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. Replace the current static home page to display/forward to http://www.opensc-project.org/opensc/wiki and to re-work the mentioned wiki page to display information in a more useful and obvious way (prominently displaying the same information that is currently available on main page as well) > * 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.) Which is fine. Keep in mind that trac provides a unified username experience which is not true/easy for a mix of other software/solutions. > > 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. opensc-project.org duplicates information and is a mess with a lot of "lists of stuff that is not working". There's a lot of documentation in terms of typed in text but instead of linking to authoritative source on the wikia and forming a logical whole, a lot of information is duplicated so you never know what is correct and what is outdated. What mostly needs to be worked on is how we serve the information to the users and what kind of information. An example "Application support" on the main wiki page and the PGP link. A naive person inside me believes that when I see a list titled "application support" I can copy-paste it to some document to my boss and say "hey look, we get all this stuff when we use opensc" ... actually having a "no, does not work, go look somewhere else" information inside that page. I've tried to give this a bit of shape with tags but it is far from perfect. But it is not point on working on it unless there's a common understanding on how and why a wiki should be used for. > 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. IMO, the main problem is outdated and messy 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? It seems that you had the impression of "trac is hard, it means a lot of spam" understanding. Which is not true > 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? You can subscribe to timeline (wiki diff is not included but the a diff) via RSS. -- 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
