Re: Working on debian developer's reference and "best packaging practices"
[Please continue to CC me on any replies.]
Raphael Hertzog <hertzog@debian.org> writes:
> Le Tue, Apr 30, 2002 at 02:24:14PM +0900, Junichi Uekawa écrivait:
> > I was hoping to get libpkg-guide (library packaging guide) into
> > Developers Reference, although the terms and language is quite
> > different.
>
> Agreed ... it fits well within "Debian Best Packaging Practices".
Ok, I'll take a look. Sounds fine to me.
Do we want to adapt it to fit into the terminology of the DDR or just
cram it into a chapter?
Junichi, are you able to work on integrating it or should I seek
another party for that?
On to the content additions...
I'm going to cover the little points there with speculation on the
priority.
- Debian Best Packaging Practices
This item is vague. I assume we're talking about tips and developer
materials not contained in policy?
Anyhow, I have to wonder what exact bits have been identified which
should be added, and also, whether anyone volunteers... Some ideas:
Charles Briscoe-Smith used to have some maintainer script boilerplates
which were very useful.
I think this is more of an ongoing issue rather than a milestone we
can hit.
- Collaborative Maintenance of Packages [1]
This is a high priority item, represents not too much text, and
should be pretty easy to fit in.
- Going further than simple maintainer [1]
I would just call this "Other Tasks You Can Do". Assume this is a
pretty small chapter. Is this high priority?
- the content mentionned in the bug reports
Yes, the various and sundry. Some easy and some hard.
I'd like to add a chapter:
- working with the upstream maintainers
I think there's a whole best practices of working with the upstream
maintainer that needs to be written. Talking about when to fork and
when not to fork -- when to patch a bug in your package, and when to
wait for the new upstream version. Also included in this would be a
document that upstream maintainers can read so they know what their
reasonable expectations should be, and where to go for help if the
debian package maintainer for their software is misbehaving.
I think this document would help Debian's reputation among free
software developers -- which sometimes is not great for our flagrant
forking and such.
I wish I could work on only this until I was done, leaving the other
bits to other co-maintainers.
Unfortunately I do not yet have any other co-maintainers --
volunteers, anyone?
Again,
[1] == <URL:http://lists.debian.org/debian-qa/2002/debian-qa-200201/msg00062.html>
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: