Hi, (a bit late, but...)
On Sat, Jul 07, 2012 at 01:49:10PM -0600, Gaudenz Steinlin wrote: > > [git conversion things] I have talked to Moray about this, and we both basically agree (but the words here are mine)... but it seems the main advantage to git is that it is cool, not that it's better for this case. First and foremost is the institutional memory. If you want to work on DebConf N, you're going to want to know about DebConf N-1 and N-2 and N-3 and so on. As a specific example, I imagine DC13 people are going to be interested in getting sponsors now. The DC12 and DC11 and so on repos will be good for that - depending on how hard you scrape, you may want all of them. So... that means continuing to give people access to old repos, nullifying the "security" here? Or go and copy over previous years to the current repo each time? git is good for code. It has tons of nice features like branching and local copies. But I have always thought that subversion is fairly ideal for our use case. One of the complains is size of the repos. Imagine what it's like when you need full history of all changes of all of our binary files, instead of just the current version. Subversion handles this nicely. Also, with subversion you can do partial checkouts. It is one of the first things I figured out when I had to use subversion for debconf-data: $ svn co --depth=immediates svn+ssh://svn.debian.org/svn/debconf-data/ $ cd debconf-data $ cd dc12 $ svn co --depth=full dc12 $ # Hm, I want to check one file in dc11? $ cd ../dc11 $ svn co --depth=immediates Really, exactly how I hope DebConf repos would behave. git does nice branching and local copies... but most of our data is designed to reflect "the real world case" where there is only one version of facts, and everyone should have that as much as possible. I agree and empathize with the fact it is hard to get people access. I would suggest cc'ing debconf-team on requests to add people as commiters. It is also one of the reasons I try so hard to minimize the amount of private date put into debconf-team, and maximize the public part in debconf-data. (If you'd like to find new people for the admin team, I think it would be very well appreciated!) There are with respect to private data being in the repositories. While I've said this in IRC, private data should only be put in if the need for sharing makes long-term storage worth it. This is the case for most things historically put into it. Perhaps, if people wanted a split, a more logical one would be a repository for just the registration team/travel sponsorship, since they are the ones with all of the attendee information. Note that none of this applies to code, such as pentabarf, etc. I realize that I am doing a lot of talking here, and not much doing. I feel pretty dirty telling others that their work isn't appreciated. However, nonetheless, every year I see tons of people come into DebConf with great idealism about technology, who eventually seeing that putting on a DebConf is about managing complexity and finding a nice balance. I wish that I could do more, but I am currently trying to finish my degree so I have very limited time. In 2-3 months, I will have much more time and can take a more active role in things, perhaps by writing up various best practices (make a list for me!). I'm sure there has been much discussion at debconf itself, and if you all would like to go ahead, I'll wish you the best of luck and do what I can with the new system. - Richard -- | Richard Darst - rkd@ - boltzmann: up 1097 days, 19:18 | http://rkd.zgib.net - pgp 0xBD356740 | "Ye shall know the truth and -- the truth shall make you free" _______________________________________________ Debconf-team mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-team
