Le lundi 19 décembre 2005 à 09:44 +0100, Lucas Nussbaum a écrit : > First, technical issues: > > * Chances are very low that you will get Ubuntu people to use svn > instead of bzr. bzr is the "official" VCS in Ubuntu, it is written in > Python, the "official" language in Ubuntu. Making Ubuntu people use svn > is like asking a vi user to switch to emacs.
Again, in order to kill the discussion before it starts, I want to make things clear : I don't want to change how Ubuntu works. I just want to find a decent way for Debian to let external contributors integrate their work within Debian and in particular for Ubuntu developers. Because it's in the interest of Ubuntu developers to merge their work within Debian. I expect anyone familiar with VCS to be able to work with svn if needed. Much like I'm able to learn bzr. Actually, the Ubuntu people doing REVU didn't event think of using a VCS because they are handling uploads of source packages in their system. Adding a VCS layer has some advantages however : traceability of contributions from an applicant is one for example. > * Generating a dynamic web page means using a non-distributed > architecture. I started working on similar stuff, but with the > assumption that maintainers will run the scripts themselves (or with > cron). An output for ruby-related packages is available on > http://ox.blop.info/bazaar/rubyversionslist.html . The webpage about the > tools is https://wiki.ubuntu.com/MOTUTools . An easier approach could be > to provide the information in an easy way on all websites so some > scripts could fetch the pages, parse them, and generate the useful > reports. Yeah, this makes sense too. I'd like to have wrappers for doing things locally : - download source package from the good repository (without having to type a huge URL) - run most checks on it (pbuilder, piuparts, lintian, ...) - display analysis - etc. It's a good idea to have those tools widely available and to simply use them on a specific server to make the data available on web pages too. > Human issues: > * The main problem is how to define trust relationships between DDs, > MOTUs, would-be DD and MOTU-Hopefuls : > * Do we want to define them globally, or on a per-team basis ? > * What should they be ? Does Debian want to trust MOTU-hopefuls ? Does > Ubuntu want to trust would-be DDs ? Human issues are a non-issue. We can't define who trust who. Each person decides who they want to trust. I expect Debian developers to not trust anyone they don't know at all, however trust can be created when review after review they see that the person is doing a good job, etc. On the Debian side, we still have people or teams behind each package so they will set the rules of which contribution they can accept. But I'm confident that with the right tools, we can enhance our collaboration. > I think that we shouldn't try to reach a too wide scope here. Chances > are high it will be too complex and will just fail. Why not start by > developping tools to help Debian & Ubuntu collaborate by exchanging > patches, bug reports and source packages, and wait for collaborative > maintenance ? Sure ! It's time to go in more details... my proposal only defines the big lines. There's still much to be defined and I'll gladly accept concrete proposals. I'll try to draft some myself when I have some time. > Of course, the problem space of REVU and {mentors,sponsors}.d.n is > similar, and common tools could be developed too instead of reinventing > the wheel. Exactly ! But applicants should directly learn how to work in teams since that what they will have to do later anyway ... so the use of a VCS in the process is a good thing (in the Debian point of view at least). However that use could be hidden behind the scenes for those who prefer to not use such a system. I'm thinking here of REVU which handles upload of source package directly. A script could be written to integrate the source in the repository... => that's the kind of discussion that I expect: finding a way to make everyone happy with one common system (even if that system seems a bit overkill for one side or the other, we need to get a bit of momentum behind it to make it maintainable in the long run). Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
