Re: Reworking on our organization - Look at the Ruby neighbours!
On Wed, 03 Jan 2007, Gunnar Wolf wrote:
> 2. ruby-pkg-tools includes a list of the group members [2],
> /usr/share/ruby-pkg-tools/pkg-ruby-extras.team - Why? Because,
> instead of having the mess we currently have, where each of us adds
> his email to the Uploaders: field of each package's debian/control,
> debian/control is built with the name of each of the maintainers.
No, no, no. Having people listed in the Uploaders that never even touched
the package is a no-no for me. I like the dynamic Uploaders field where
one add himself when working on the package.
Why would you want to list everybody on all packages ? The only reason I
can see is to have all the packages listed in your personal summary
(qa.debian.org/developer.php) but I see no point in that since there's
already the page of the group:
http://qa.debian.org/developer.php?login=pkg-perl-maintainers@lists.alioth.debian.org
On the contrary I want to keep my personal page limited to packages I
really maintain (even those within the team, like libdbd-pg-perl) and
when I have extra time that I choose to dedicate to the pkg-perl group
(which doesn't happen often :-() I can then go to the group page above.
> 3. CDBS classes [3]. I'm still uncertain about this one, but all in
> all, it makes sense. Most of our makefiles are just the same over
> and over. When we have done changes to our build process
> (i.e. replacing the -$(MAKE) distlean with the conditional
> variant), it has been quite an invasive and error-prone
> approach. Too many ways of doing very similar things (yes, like the
> Perl motto - but still, I don't see much benefit with the current
> situation). Of course, you are all familiar with my error-fixing
> extra commits (BTW, just not to break tradition, it took me _six_
> commits to get my name added to pkg-ruby-extras.team ;-) ). I do
> not like CDBS too much, but it is greatly because I have not used
> it much, and it's harder to debug something you are not familiar
> with. Probably we should build a couple of CDBS classes for all of
> our packages, and do away with our individual makefiles.
A CDBS class for perl modules already exist AFAIK. CDBS even make sense
in our case since most packages are very similar. But I'm not a big CDBS
fan in general.
> 4. A simple, automatic way to get the upstream sources [4]. You don't
> have to manually fiddle with creating build-area, putting and
> renaming the orig.tar.gz there. It's automatable. And, hey - If
> debian/watch has the information, if uscan can check if there are
> new versions, why must we do it manually? Well, there must be a
> reason not to rely on debian/watch for everything - They have a
> YAML file in their SVN describing where are the sources for each
> package.
What are those reasons ?
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: