On 14.01.2010, at 17:07, Andreas Jellinghaus wrote: > Am Donnerstag 14 Januar 2010 15:28:49 schrieb Jim Rees: >> Andreas Jellinghaus wrote: >> >> if we need to fix the server for this: we could drop all certificates >> and issue username/password for each developer instead. >> >> Ugh. That would be embarassing for what is at least partly an >> authentication project. How about ssh key pairs? > > yes, we could switch to ssh instead of http for write access. > > if we do that, we could as well switch from svn to git (or other system. > but martin is a git fan and so am I) if we want. git has "gitossis" which > is a secure shell for fine grained access control to git repositories > (and allowes nothing else). maybe svn has a similar way so I can restrict > access control to svn repositories. I would suggest git as it would remove the annoyin "gatekeeper" role from OpenSC development. Instead, a proper release maintainer role could emerge that would have some kind of more formal release plan.
> also (a bit unrelated, but we had this openid/trac discussion), if we overhaul > our server setup, we could throw away trac too. the only features used so far > are the wiki, the ticket system and the source code viewer. Ah well, that's like "only using the transportation features of a car" :) Wiki, ticket system and source code viewer are basically the core features of Trac, that brings together the three into a interwoven environment. Removing trac might "feel" simpler (to you) but it's not a good move (unless a viable alternative is proposed) > there are nice > source code viewers out that to fill that part. Trac works very well if you use SVN. There is a git plugin too, but it "feels" strange. But it works. > the ticket system is mostly > unused, I don't remember people looking at the open tickets and fixing them That's because there has been: - No easy access to tickets (registration/spam issue) - No development/release plan other than "bursts" -> no visible point in tickets, both for people willing to report issues and people capable in fixing them. OpenID authentication works as an easy way to remember people. > often. and the trac ticket system is bad, as we don't get an email of a bug > reporter, and thus often have a new bug without any way to contact the > reporter for details. Bold text "If you want the issue fixed, leave an e-mail address or check back here" added to the new ticket screen would help remedy this situation. > and the wiki - well, putting the documentation in the source would simplify > the makefiles and maybe make editing documentation easier. at least we would > no longer have the spam issue. and except for opensc nearly noone uses the > wiki anyway (for many smaller projects there have been no changes in years, > for openct almost every change was done by me). That's a "management issue" I've seen in corporate settings where I have deployed Trac - project boundaries that work in a collaboration environment don't map 1:1 to source package/client/formal whatever borders. Small "projects" don't encapsulate enough "value" to be useful -> they "die". When properly set up, Trac does not suffer from spam (almost) at all. I've not touched anything on opensc-projects.org as I use mod_wsgi/virtualenv etc not mod_python, which you have set up. I can change that. > so there are a several options what we could do. > > but if we have a big problem with the https setup with client certificates > right now, we should switch to https with user/pw setup - that is easily > done, already implemented for one developer. The password interface stopped working some time ago (I think when Ubuntu switched to GnuTLS+subversion) I can't even remember why the certificate authentication did not work for me a few years back but it's OK now (on Ubuntu and OSX) > bigger changes can be done > later (i.e. if we agree on what we want and someone finds time to implement > the changes). no, it's not nice to delay things because the direction is > unknown, or how many people would like some change, or maybe noone has time > for it. but reality is often like that :( -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
