Am Donnerstag, den 13.11.2008, 13:37 +0900 schrieb Charles Plessy:
> Hi all,
> 
> I added the following paragraph to our Policy.
> (I suppose it is consensual)

I'm not part of debian-med. However, I hope you don't mind this mail:

[..]
> +             <sect2>
> +                     <title><filename>debian/README.source</filename></title>
> +                     <para>This file is recommended by the Policy (<ulink 
> url="http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource";>ยง 
> 4.14</ulink>) from version 3.8.0 for documenting source package handling. You 
> can start from the following template, and add other necessary informations 
> about patch systems and sources in other format than gzipped tar achive:
> +                             <literallayout>
> +This package is maintained by the Debian Med packaging team. Please refer to
> +our group policy if you would like to commit to our Subversion repository. 
> All
> +Debian developpers have write acces to it.
> +                             </literallayout>
> +                     </para>
> +             </sect2>

IMHO this is a misuse of this file. The contents of README.source should
point to unusual/uncommon source handling, including source parts, which
have been removed, repackaged or put together, patch management systems
and maybe information related to multiple/special builds. But your
template does not fit any of these categories. Instead it doubles the
information from the already existing Vcs* control fields and
debian/copyright. So I think, that the last paragraph of section 4.14 of
the policy doesn't apply here (IMHO *buildpackage tools are not the
target of this sentence, as they are not necessary to modify the
source). As long as this package is maintained by a group of people,
they can agree to some policy internally. But such a group policy nor
the VCS usage do not apply to NMUs nor new maintainers (if this package
gets orphaned). So I think, putting this information into README.source
is wrong.

However, this is my very personal opinion.

Regards, Daniel


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to