On Fri, Apr 28, 2000 at 03:52:48PM +0200, Josip Rodin wrote:
> > - must not be so buggy that we refuse to support them,
> > + should not be so buggy that we refuse to support them,
> > - must meet all policy requirements presented in this
> > + should meet all policy requirements presented in this
> > manual.
> If you change the former line, that would mean that we may (hypothetically,
> of course) refuse to support foo which is in main, but it would still be
> suitable for release, i.e. it would be a normal bug? I don't quite like it.
If they're that buggy, they've already got RC bugs against them by
definition, no? But perhaps this does make more sense as a "must". I'm
easy.
> You could change the latter line to match current status, but that simply...
> doesn't look good :) We should have full policy compliance as one of the
> goals, important ones... but it's not doable right now.
I'd rather see that requirement just removed, and left for the scope. Can
you imagine "my package isn't policy compliant, so it doesn't have to be
policy compliant to go into main" ? :)
> > - Each package is given a certain <em>priority</em> value,
> > + Each package <em>must</em> have a <em>priority</em> value,
> So, we would need to go over each of these 804 packages (as reported by
> Lintian) that don't have it?
Ugh, pain, change to "should".
> > - Packages may not depend on packages with lower priority
> > + Packages <em>must not</em> depend on packages with lower priority
> Richard said that this isn't RC.
(I expect and hope this'll change for woody, but...) Change this to "should"
too. Existing practice, etc.
> > If changes to the source code are made that are generally
> > + applicable they should be sent to the upstream authors in
> > + whatever form they prefer so as to be included in the
> > + upstream version of the package.</p>
> Great to see that this would become a reason for filing a normal bug.
Isn't it now? It'd be weird to file a bug about, maybe, but it didn't
seem unreasonable to me.
> > + You should make sure that the <prgn>configure</prgn>
> > + utility detects the correct architecture specification
> > + string (refer to <ref id="arch-spec"> for details).</p>
> IIRC several porters have been filing these as RC bugs so far, if it made
> the package unbuildable... since the fix isn't complcated, maybe this should
> be a `must' case.
Packages have to be auto-buildable anyway. This is kind-of covered in
the build-depends section. (If the program checks to see if its manpage
is about and refuses to start otherwise, that makes a "missing manpage"
bug grave; similar upgrading applies here, imo) Unless this *always*
makes a package unbuildable?
> > - Document your changes and updates to the source package
> > - properly in the <tt>debian/changelog</tt> file.</p>
> > + You should document your changes and updates to the source
> > + package properly in the <tt>debian/changelog</tt>
> > + file.</p>
> However this would indicate that filing normal bugs on faulty changelog
> entries is preferred.
(Note that mistakes in changelogs are usually
best rectified by making a new changelog entry rather than
"revising history" by editing old changelog entries)
then, maybe.
> > + configuration, the program should to be changed to fall back
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > + to a reasonable default configuration if these environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > + variables are not present. If this cannot be done (e.g., if
> > + the source code of a non-free program is not available), the
> > + program <em>must</em> be replaced by a small `wrapper' shell script
> > + which sets the environment variables if they are not already
> > + defined, and calls the original program.</p>
> ...or the code should be added to the program itself to do it.
> > - files must go in the run-time library package. This is a
> > good idea in general, and especially for static linking
> > + issues. (Huh?)
> :)
No, really, what does this mean? What does "this" refer to here? Should
".la" files generally go in the lib or in the lib-dev? I have vague
memories so putting them in the lib makes the libs conflict, although
perhaps that's not such a bad thing for libtool libs. So I'm not clear
what's required and what's recommended here. That's probably really bad.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp8dWJey9R9Q.pgp
Description: PGP signature