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

Re: scope creep in DDP Policy



Javier Fernández-Sanguino Peña <jfs@computer.org> writes:

> 	Just a few comments, I'm way overloaded for the time being and
> cannot commit to do major editing.

That's ok.  No one's asking you to.  I'm trying to achieve consensus
on the DDP scope.  That's the main thing. There's still a lot of
distance between you and me on this issue.

> On Tue, Jan 28, 2003 at 12:29:58PM -0600, Adam DiCarlo wrote:
> > Personally I think in view of our revised ideas about our scope, the
> > idea of /usr/share/doc/Debian becomes a little dubious.  Not all
> > Debian documents are covered by the DDP policy.
> 
> 	No. That's the maint point. If it's a Debian document why on earth
> is it not under the DDP CVS.

But turn this around -- why on earth is it required that it is in DDP
CVS?

> I'm sure I'm stepping on many people shoes,
> many have been handling their documents in other (different) ways, such as
> the Installation manual, the Developers Reference...

Um, install manual is in DDP for sarge.  Developer's reference has
been in the DDP for a long, long time.

A better example of a document not in the DDP is debian-policy.  It
has it's own CVSROOT, it's own maintence procedures and list.  Is it
required that debian-policy move as a module under the DDP?  How does
Manoj feel about this?  What are the benefits of making this change?

Or an even better example: debconf-doc.  Should this really be
maintained by the DDP?  Doesn't it make more sense to allow Joey Hess,
the maintainer of this document, to decide whether he wants it in DDP
or not?

> 	Take a look at Bug #64278 

I would agree doc-debian and translations thereof should probably be
in DDP.  It's a pure documentation package not tied to package
maintenance.  You're right that DDP centralization helps here with
providing on ftp.debian.org

> or Bug #118592

Java-doc not in DDP is your complaint here.  My stance here is that
there are possible benefits to making this conform to DDP levels.  I
think it's our job to approach maintainers, letting them know the
benefits, offering our infrastructure and translation teams.

I think we're going to alienate maintainers by taking the line, "You
have to move this into DDP", or even, "it's a bug that this is not in
DDP".  Rather than pretending we have the authority to *require* such
documents be in the DDP CVS tree, we should take the approach of
persuation.

Maybe we're not so far apart after all...

>, or Bug #172482

This is something where we need to talk with ftpmaster and work out a
system of publishing out of DDP CVS to the ftp /debian/doc area.  This
is a different level of issues: internal to us, the DDP.  Once we get
this in place, we'll have a much strong argument for people to use DDP
CVS.

> or Bug #106492.... 

You want doc-debian in DDP.  You're approach, again, is to declare the
offenders buggy.  I think taht will alienate people and instead we
should use persuation, rather than trying to set a policy that it's a
problem if the packages don't use DDP CVS.

I'm glad you got down to cases.  It seems to show that we both have
the same goal at heart, just different ways to go about it.

> 	This separation into multiple "islands" each handled by their own
> DD makes it difficult to have a way to:
> 
> - make translations and keep them up-to-date
> - publish documentation on the ftp/web site (both original and
> translations)
> - provide packages for offline reading (for both too)
> 
> 	And that situation takes us to the point in which translators can't
> do their work properly, packages with documents get out of date, the
> website/ftpsite is missing content, and basicly users are not provided with
> all the information translators/documentation managers have struggled to
> make for them.

All these problems existing *within* DDP as well as *without* it.

> 	We _need_ a common infraestructure, I can't stress that enough. And
> we need DDs to accept and use that infraestructure, not provide whatever
> they feel is best when it usually is not.

I would agree the use of the common infrastructure is desirable.  I do
not agree we have the authority to require this.  We lack the
authority literally, meaning we don't have any means of enforcing
this.  We also lack the authority morally, because the DDP
infrastructure itself is rather lacking and not quite there yet. 

> 	Doc-base is not good enough. Excuse me for saying this, but
> document registration, if not integrated with GNOME/KDE help system as
> a subsytem is not enough. Please look around in /usr/share/doc to find
> stuff. Literally.

This should be solved by two things: (1) allowing doc-base to have
hooks so that other documentation systems can hook themselves in to
document registration, and (2) systems such as GNOME/KDE make use of
those hooks.

I propose to keep this stuff out of the DDP policy.

> >   developers-reference-en
> >   developers-reference-fr
> 
> 	This one is preferred. Some DDP documents might be available only
> on a given language and that might just not be english (see the fr/ section
> under manuals.sgml). The broader Debian gets the more documents that will
> be written by non-native english speakers (I believe one such proposal for
> a spanish document was made a while back).

Hmm, ok, that's somewhat reasonable.
developers-reference/developers-reference-fr is rather english centric
too, which is not desirable.

> > If you don't mind some radical surgery, I might be able to go through
> > the document, trimming the scope, and marking sections which should be
> > destined for policy or best practices as appropriate.
> > 
> 	"Put down your visors... lasers coming up"
> 	(i.e. go ahead, but don't forget to take content to Developers
> reference when appropiate)

Lets get consensus first.  I want to see your reactions to this email.

You proposed that I work on a branch, right? Otherwise, I can work
'uncommitted', sending patches to the list for approval.

-- 
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>



Reply to: