[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ripit (updated package)



On Tue, 28 Apr 2009 03:07:04 +0300
Marius Vollmer <marius.vollmer@gmail.com> wrote:

> I understand that you want people to come to you with a very good
> package already, and that you don't want to waste time on a hopeless
> case.  Some prepared documents and checklists are certainly useful for
> potential sponsorees, but there is more than one way to convey the
> message, of course.

There are other guidelines too, written from different perspectives.
Pick one or combine some into a set of your own that you'll use once
you are a DD as well.

This is the problem with seeing the page as universal - it is most
definitely NOT universal, it is personal. (Hinted at by the
people.debian.org/~codehelp/ URL.)
 
> I think your list of requirements is great, technically, and they
> would be much better if you would teach more than you scold, and
> emphasize success over failure.

OK, I can probably expand certain bits but I have no intention of
making the page into a complete reference or anything of that size.

It's my sponsoring guidelines page, it is not a general-purpose
packaging guide.

> E.g., you say "Do not resort to cp or mv hacks. Use the tools and use
> them properly".  How should this be understood by a fledgling who has
> made hist first barely working debian/rules files that has a "cp" in
> it? That the mere act of using "cp" makes him not worthy of ever
> being shown how to do it right?

There are plenty of examples in existing packages - I do require the
maintainer to do the work, I'm not about spoon-feeding people. I expect
maintainers to be able to look at other packages for examples of what
Debian expects. There is no need to make the page so expansive that it
adds to the erroneous perceptions, already outlined in this thread, that
the page could ever be a general-purpose document and which I'll address
in the next update of the page. The page is about hints, not a tutorial.

Please also note that my page is explicit about expecting maintainers
to be expecting to join Debian and that has some influence on how the
points are written - I think it would be even more patronising to
spell out how to use install instead of cp. That point is a reminder of
something that I expect the maintainer to already understand. If not,
I expect the maintainer to be able to use standard methods (like
Google) to find out for themselves.

> Isn't it nicer to read something like this following?
> 
>     Here are some rules that I follow in my own packages, and you
> should follow them, too.  I have found that they make package
> maintaince easier in the long run, and lead to high quality packages.
> 
>     If you have questions about how to follow some of these rules,
>     please ask on <debian-mentors@lists.debian.org> instead of asking
> me personally.  You will reach more people that are able to answer
> your questions that way.
> 
>     [...]
> 
>     - Use CDBS or debhelper in debian/rules.  Try to avoid the
> explicit use of "cp", "mv", "chmod", etc.  CDBS and debhelper are
> quite flexible and can do a lot of things that make explicit file
>       manipulations unnecessary.  Invest the time to learn them well.
>       If really needed, prefer patching the upstream Makefile to do
> the right thing to using "cp" etc in debian/rules.  (See the section
>       on how to maintain patches below.)

That's probably short enough to add, but there won't be a section on
"how to maintain patches" - the page isn't a HowTo and I've no interest
in writing one.

I'm adding this section to the page:

###############
How general are these guidelines?

    These are my own requirements and have no bearing on the
requirements of other sponsors. This page is not authoritative in any
way (except for my own sponsoring), it is not a HowTo or a tutorial and
is offered on the simple basis that it might be useful to other
maintainers and for other packages. Certain points are clearly personal
to me and my own sponsoring only. I do try to implement the general
points in my own packaging (which is only fair) but if anything in my
packaging or my sponsoring is at odds with this document, the document
will be updated. If any elements are unclear, ask on the
debian-mentors@lists.debian.org mailing list and look at examples from
other packages already in Debian (i.e. I expect the maintainer to do
the work).

    By all means use the page for your own work, but please don't make
it into something it is not or recommend it for purposes that are
beyond the scope of the actual document. Some elements are already
lintian tests, some extend lintian tests and some are entirely my own
preference. Use your own judgement when using this page with packages
that I am not actually sponsoring.
###########

I hope that text is sufficiently clear.

If it helps some people, I'm happy. If it doesn't help me, I'll update
it. If it puts some people off, so be it. It's not up to me to create a
single document that is all things to all maintainers/sponsors (even if
such a document was even conceivable).

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgp1fw6TiKaUH.pgp
Description: PGP signature


Reply to: