On Tue, Apr 17, 2001 at 06:37:03PM +0300, Richard Braakman wrote:
On Wed, Apr 18, 2001 at 12:35:46AM +1000, Anthony Towns wrote:
aj, who'd rather relying on things that are objectively verifiable, rather
than oracles like the policy editor or the release manager
You can expect people to
On Fri, Apr 20, 2001 at 04:56:48PM +1000, Anthony Towns wrote:
That's reasonable. I don't agree, but enough other people seem to that
it'll probably happen anyway. And I don't think it'll be harmful.
It's only justification for not using must and should to indicate
RCness, though; [...]
In
On 20010416T104914+0100, Julian Gilbey wrote:
Did the ftpadmins ever consider the possibility of running lintian on
packages before allowing them into unstable?
I believe that all of us ftpmasters run lintian on new packages as part
of our set of new package checks. The results are then
On Tue, Apr 17, 2001 at 06:03:49PM -0500, Manoj Srivastava wrote:
Julian - there's no longer a suggestion of using policy as anything other
Julian than a set of guidelines
Is that really the case? I certainly do not find that I treat
Policy as a guideline, to be followed or
On Tue, Apr 17, 2001 at 06:03:49PM -0500, Manoj Srivastava wrote:
Julian == Julian Gilbey [EMAIL PROTECTED] writes:
Julian - there's no longer a suggestion of using policy as anything other
Julian than a set of guidelines
Is that really the case? I certainly do not find that I treat
On Tue, Apr 17, 2001 at 12:34:49PM +1000, Anthony Towns wrote:
It's only people on -policy that have to realise that MUSTs and SHOULDs
don't have the rfc meaning, though, afaics. Violating a MUST in an RFC
No, it's the readers/users of Policy. And they are the ones who have
been getting
On Tue, Apr 17, 2001 at 10:08:24AM +0100, Julian Gilbey wrote:
On Tue, Apr 17, 2001 at 12:34:49PM +1000, Anthony Towns wrote:
It's only people on -policy that have to realise that MUSTs and SHOULDs
don't have the rfc meaning, though, afaics. Violating a MUST in an RFC
No, it's the
On Wed, Apr 18, 2001 at 12:35:46AM +1000, Anthony Towns wrote:
aj, who'd rather relying on things that are objectively verifiable, rather
than oracles like the policy editor or the release manager
The RFC usages of SHOULD and MUST have spread far beyond the RFCs,
they are popular among
Julian == Julian Gilbey [EMAIL PROTECTED] writes:
Julian - MUST and SHOULD change to the universally-recognised IETF meanings
Julian - the distinction between RC and non-RC bugs is retained clearly
Julian - it's clear what one ought to do to create a good Debian package
Julian - there's
On Mon, Apr 16, 2001 at 02:16:24AM +0100, Julian Gilbey wrote:
I guess there are two conflicting desires here:
(1) The Acting Release Manager's desire to have it clear what
constitutes an RC bug.
(2) Developers' desires to know what must be done in all cases and
what ought to be
On Mon, Apr 16, 2001 at 10:49:14AM +0100, Julian Gilbey wrote:
Did the ftpadmins ever consider the possibility of running lintian on
packages before allowing them into unstable? I vaguely remember that
being discussed in the past.
(speaking from my experience as ftpadmin in the past)
They
On Mon, Apr 16, 2001 at 10:49:14AM +0100, Julian Gilbey wrote:
On Mon, Apr 16, 2001 at 02:16:24AM +0100, Julian Gilbey wrote:
I guess there are two conflicting desires here:
(1) The Acting Release Manager's desire to have it clear what
constitutes an RC bug.
(2) Developers' desires to
On Mon, Apr 16, 2001 at 10:38:39PM +1000, Anthony Towns wrote:
On Mon, Apr 16, 2001 at 10:49:14AM +0100, Julian Gilbey wrote:
On Mon, Apr 16, 2001 at 02:16:24AM +0100, Julian Gilbey wrote:
I guess there are two conflicting desires here:
(1) The Acting Release Manager's desire to have it
* Anthony Towns aj@azure.humbug.org.au [010416 05:54]:
Does that possibility satisfy everyone:
- MUST and SHOULD change to the universally-recognised IETF meanings
It's still not clear why this would be a Good Thing.
The only real reason I've seen is that it's confusing people (and then,
added an * to a word, instead.
It'd probably be fine for a month or two, but so was MUST/SHOULD...
Again, I'm still not seeing a real justification for bothering with the
IETF meanings.
There's a valid cause for confusion here: the difference between MUST
and SHOULD from a when should we use one
On Sat, Apr 14, 2001 at 12:22:03PM -0400, Sam Hartman wrote:
Anthony == Anthony Towns aj@azure.humbug.org.au writes:
Anthony Sure. *Everything* in policy is just a guideline, and
Anthony there can always be special cases. That's why we have
Anthony maintainers with good judgement.
On Mon, Apr 16, 2001 at 12:43:00AM +1000, Anthony Towns wrote:
In rare cases, specifically when a package has never been available when
with files in /usr/doc, it's quite reasonable to include the symlink in the
package itself. It's generally not worth the hassle, since most people will
use
I guess there are two conflicting desires here:
(1) The Acting Release Manager's desire to have it clear what
constitutes an RC bug.
(2) Developers' desires to know what must be done in all cases and
what ought to be done (but there may be exceptions), and what is
currently a
On 15-Apr-01, 20:16 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote:
I guess there are two conflicting desires here:
(1) The Acting Release Manager's desire to have it clear what
constitutes an RC bug.
(2) Developers' desires to know what must be done in all cases and
what ought to
Julian == Julian Gilbey [EMAIL PROTECTED] writes:
Julian On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
So we no longer accept uploads of packages that don't have manpages for
all their binaries?
Julian OK, let's take this example then. At the moment it's only a should.
Seth == Seth Arnold [EMAIL PROTECTED] writes:
Seth I've wondered about this several times in the past. Would it be
Seth possible/feasible/desirable to have an amendment to policy that
Seth specifies a schedule for its own replacement?
Generally, we have tended to refrain from putting
Anthony == Anthony Towns aj@azure.humbug.org.au writes:
Anthony --VbJkn9YxBvnuCH5J Content-Type: text/plain;
Anthony charset=us-ascii Content-Disposition: inline
Anthony Content-Transfer-Encoding: quoted-printable
Anthony On Fri, Apr 13, 2001 at 01:11:31PM -0400, Sam Hartman
On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote:
On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
So we no longer accept uploads of packages that don't have manpages for
all their binaries?
OK, let's take this example then. At the moment it's only a should.
Why
On Fri, Apr 13, 2001 at 03:20:50PM +1000, Anthony Towns wrote:
So we no longer accept uploads of packages that don't have manpages for
all their binaries?
OK, let's take this example then. At the moment it's only a should.
Why can't we say that, from now on, we will not accept uploads
On Fri, Apr 13, 2001 at 11:29:54AM +0100, Julian Gilbey wrote:
On Fri, Apr 13, 2001 at 03:20:50PM +1000, Anthony Towns wrote:
Suppose we do. First, what benefit does this provide to the user who
gets a copy of the new woody release in, say, six months on CD. Can they
rely on every binary
Anthony == Anthony Towns aj@azure.humbug.org.au writes:
Anthony Every package must comply with the MUST directives of the
Anthony current policy, or it doesn't get released. Packages that
Anthony don't comply with the current policy's SHOULD directives
Anthony are buggy.
First I
On Fri, Apr 13, 2001 at 01:11:31PM -0400, Sam Hartman wrote:
I believe it is consistent with that text for me as a maintainer to
close a normal bug opened against my package because I violate a
should guideline explaining why I had a good reason for doing what I did.
While generally a
Julian == Julian Gilbey [EMAIL PROTECTED] writes:
Julian Must == have to do this, RC bug if don't
Julian Should == we recommend you do this, normal bug if don't
May == recommended.
Julian I would much prefer to move to the RFC version with some sort of flag:
Julian Must ==
I've had a thought about my ideas. I suggest that we all try doing a
'PMI' on them (I will not have a chance now until early next week,
though). It's a three minute task, and you should be strict about
timing, and works like this:
For one minute, come up with as many Positive thoughts and ideas
On Fri, Apr 13, 2001 at 06:41:55PM +0100, Julian Gilbey wrote:
I've had a thought about my ideas. I suggest that we all try doing a
'PMI' on them (I will not have a chance now until early next week,
though). It's a three minute task, and you should be strict about
timing, and works like
On Wed, Apr 11, 2001 at 02:44:26PM -0700, Sean 'Shaleh' Perry wrote:
I thought we were using RFC definitions of must and should, and thus 'may'
follows.
You're not the only one who thought that, but we're not :)
Paragraph 1.1 describes them.
must = have to do this, release critical bug if not
On Thu, 12 Apr 2001, Richard Braakman wrote:
Must == have to do this
Should == we recommend you do this
May == we think it is a good idea, but is not always possible/sane/etc
These aren't the RFC definitions though. MAY simply means it's
optional, it doesn't have to be a good idea.
On Wed, Apr 11, 2001 at 02:44:26PM -0700, Sean 'Shaleh' Perry wrote:
On 11-Apr-2001 Julian Gilbey wrote:
We don't really have any standard way of saying you really should do
this as it's a really good thing to do, but there's no requirement to
do so (and hence not a reason to file bug
On 11-Apr-01, 18:05 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote:
[redef of MUST/SHOULD/MAY to RFC definitions; make def of RC bugs
orthogonal]
Does any of this sound reasonable? Anthony, what do you think of it?
I know you've always gone by the must = RC route, but there are lots
of people
On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
So we no longer accept uploads of packages that don't have manpages for
all their binaries?
OK, let's take this example then. At the moment it's only a should.
Why can't we say that, from now on, we will not accept uploads which
* Julian Gilbey [EMAIL PROTECTED] [010412 17:03]:
My suggestion is: change should to must in policy, and give
packages some time to migrate (eg., one year) before starting to do
NMUs. Then any packages uploaded within the coming year will have to
satisfy this requirement (or have a lintian
We don't really have any standard way of saying you really should do
this as it's a really good thing to do, but there's no requirement to
do so (and hence not a reason to file bug reports).
Any thoughts?
(The case I was thinking of was the build-arch/build-indep stuff.)
Julian
--
On 11-Apr-2001 Julian Gilbey wrote:
We don't really have any standard way of saying you really should do
this as it's a really good thing to do, but there's no requirement to
do so (and hence not a reason to file bug reports).
I thought we were using RFC definitions of must and should, and
On Wed, Apr 11, 2001 at 02:44:26PM -0700, Sean 'Shaleh' Perry wrote:
On 11-Apr-2001 Julian Gilbey wrote:
We don't really have any standard way of saying you really should do
this as it's a really good thing to do, but there's no requirement to
do so (and hence not a reason to file bug
39 matches
Mail list logo
