Fabien Ninoles <[EMAIL PROTECTED]> writes:
> Quick idea? Not really... but quick wording for a non-native english
> speaker, yes.
Sorry. I know that it's a longstanding discussion and I like to see a
end of it (by having a nice solution).
> At least, is really better than a RH-like-contrib dist
[EMAIL PROTECTED] wrote:
> However I have had a bug or three closed by someone else -- for the wrong
> package. Most recently was an anacron bug that was closed by the ytalk maint.
> It was an accident, he fixed it the moment I told him, but it should not be
> possible to do.
>
> Now, perhaps a p
>
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> [A big part snipped as I agree to it.]
>
> > 4. Noone but the maintainer of a package (or someone acting on their
> > request) should close its bug reports.
>
> I'm not sure if this acceptable anymore as we are starting to revive
> the qa-team. I
Christian Kurz wrote:
> I'm not sure if this acceptable anymore as we are starting to revive
> the qa-team. In some situationt they also need the right to close a bug
> report and so we need to make the above statement clearer than now.
The qa team is either working on a package owned by debian-qa
Manoj Srivastava wrote:
> One reason that I have encuntered in the past was the need to
> maintain a working, older version of X (say, R6) while toying with a
> newer release (say, R7). Having separate directories in /usr allowed
> my to have both versions installed on the machine (this
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
[A big part snipped as I agree to it.]
> 4. Noone but the maintainer of a package (or someone acting on their
> request) should close its bug reports.
I'm not sure if this acceptable anymore as we are starting to revive
the qa-team. In some situationt t
Santiago Vila wrote:
> Well, if we had some sort of policy (or even recommendation) to just avoid
> (or try to avoid) the extreme cases (without reaching to "oppression"),
> would things be worse than now?
A reccommendation would be fine. Perhaps it'd be more suited to go in the
developers referen
On Mon, May 31, 1999 at 01:56:07PM -0700, Joey Hess wrote:
> Santiago Vila wrote:
> > Well, what I would like to see is a general policy about bugs, covering
> > all aspects of bug reporting, forwarding, severitying and closing. Who is
> > allowed to do that, and when. For example, how many times a
On Tue, Jun 01, 1999 at 12:41:41PM -0500, Manoj Srivastava wrote:
> Hi,
>
> More than a year ago, Ian posted these rules governing
> disputes about bug reports. I found these acceptable, though I am
> somewhat leery of making thse _policy_. I would be happier if these
> were put togeth
> On Tue, 1 Jun 1999, Julian Gilbey wrote:
>
> > Santiago Vila wrote:
> > > Well, what I would like to see is a general policy about bugs, covering
> > > all aspects of bug reporting, forwarding, severitying and closing. Who is
> > > allowed to do that, and when. For example, how many times are a
Quoting Steve Greenland <[EMAIL PROTECTED]>:
> On 30-May-99, 07:37 (CDT), Peter Makholm <[EMAIL PROTECTED]> wrote:
> >
> > Somebody mentioned another upcomming and more complete proposal by
> > Wichert Akkerman in this area.
> >
> > I would like to see Wicherts proposal before rushing this prop
Hi,
More than a year ago, Ian posted these rules governing
disputes about bug reports. I found these acceptable, though I am
somewhat leery of making thse _policy_. I would be happier if these
were put together in a document which is, like the developers
reference, a document meant to
On Tue, Jun 01, 1999 at 12:15:22PM -0500, Manoj Srivastava wrote:
> >>"Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:
>
> Branden> I see so reason /usr/X11R6 has to continue to exist at all.
>
> One reason that I have encuntered in the past was the need to
> maintain a working
> The configure script must be a bash script, but not everything allowed
> in bash is allowed there.
Excuse my ignorance... Is this for postinst scripts or
/usr/sbin/*config scripts or both?
A lot of those are Perl scripts. I for one don't really want to
do complicated configuration in bash in
>>"Brock" == Brock Rozen <[EMAIL PROTECTED]> writes:
Brock> Well, I definitely think we should start with something
Brock> lightweight -- but the whole process of accepting
Brock> proposals/amendments should eventually become formalized, with
Brock> specific rules on how it's done -- IMHO.
>>"Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:
Branden> I see so reason /usr/X11R6 has to continue to exist at all.
One reason that I have encuntered in the past was the need to
maintain a working, older version of X (say, R6) while toying with a
newer release (say, R7). H
On Tue, Jun 01, 1999 at 05:34:48PM +0200, Santiago Vila wrote:
>
> I think this is better viewed in absolute terms.
>
> 38 reopening-reclosing flamewars in the BTS are too much.
> Very often is the *reopening* of a bug what makes the maintainer to be
> upset, not the fact that the submitter disag
> "Goswin" == Goswin Brederlow <[EMAIL PROTECTED]> writes:
Goswin> Package: debian-policy Version: 2.5.0.0 Severity: wishlist
Goswin> A better way to configure debian systems
Goswin> --
Goswin> 1. GOAL
On Tue, Jun 01, 1999 at 05:34:48PM +0200, Santiago Vila wrote:
>
> > Let's try to focus on the real problems. Social complications are seldom
> > solved by oppression.
>
> Well, if we had some sort of policy (or even recommendation) to just avoid
> (or try to avoid) the extreme cases (without rea
On Tue, 1 Jun 1999, Marcus Brinkmann wrote:
> On Tue, Jun 01, 1999 at 11:52:59AM +0200, Santiago Vila wrote:
> > >
> > > No, we just need some common sense, common courtesy (which none of us
> > > seem to be so good at ;), some good relaxation techniques and some
> > > good interpersonal skills.
On Tue, Jun 01, 1999 at 11:52:59AM +0200, Santiago Vila wrote:
> >
> > No, we just need some common sense, common courtesy (which none of us
> > seem to be so good at ;), some good relaxation techniques and some
> > good interpersonal skills.
>
> My experience says this is not enough.
Please don
On Mon, May 31, 1999 at 12:55:53PM -0700, Joey Hess wrote:
> Marcus Brinkmann wrote:
> > I already granted you this point. However, my /usr/X11R6 contains 45 MB of
> > data. What is the upper limit? Do people really live on such dangerous
> > edges that they can move 50 MB across partitions without
Package: debian-policy
Version: 2.5.0.0
Severity: wishlist
A better way to configure debian systems
--
1. GOALS
- Allow for automatic, non-interactive installation
- Variable amount of questions depending
On Tue, 1 Jun 1999, Julian Gilbey wrote:
> Santiago Vila wrote:
> > Well, what I would like to see is a general policy about bugs, covering
> > all aspects of bug reporting, forwarding, severitying and closing. Who is
> > allowed to do that, and when. For example, how many times are a submitter
>
On Mon, 31 May 1999, Edward Betts wrote:
> On policy, Santiago Vila <[EMAIL PROTECTED]> wrote:
> > Among other things: Old awk is not guaranteed to have user-defined
> > functions (if I'm not mistaken).
> >
> > However, I have yet to see an awk packaged for Debian
> > which is not a new awk.
>
>
On Sun, May 30, 1999 at 11:23:01PM +0200, Marco d'Itri wrote:
> >In other words, is it OK to announce the move to FHS on
> >-devel-announce so that developers can start making the necessary
> >changes to their packages?
> We should wait for FHS 2.1, some of the changes in 2.0 like /var/state
> w
> > Some time ago I discovered how bad dpkg handled hardlinks to conffiles in
> > one of the packages I maintain, smartlist.
> >
> > If you create a list "foo", it will have a file in /var/list/foo/rc.submit
> > which is just a hardlink to /var/list/.etc/rc.submit.
> >
> > However, if you change
On Mon, 31 May 1999 at 13:34, Joey Hess wrote about "Re: Bug#38612:...":
> Keep in mind what policy is for. Keep in mind the intended audience. It's
> not just the members of this list, and we shouldn't clutter policy up with a
> lot of baggage new maintainers need not read. A pointer is quite suf
>> >
>> > Does that make things clearer?
>>
>> I think that a smarter way of doing this would be better. A user should be
>> able to edit things in /etc and be reasonably sure that the changes will not
>> disappear.
>
> Absolutely: the changes will only disappear when the package is
> purged.
> On Mon, 31 May 1999, Julian Gilbey wrote:
>
> > Santiago Vila wrote:
> > > However, since every awk in the system is always a new awk and it is
> > > always available as awk, we could standarise the expectations and declare
> > > that every time a program in a Debian system needs any awk (either
> Julian Gilbey wrote:
> > Now that we have a "fixed" priority in the developers-reference (this
> > is not in policy itself), can this proposal be closed?
>
> Your quote is not sufficient for me to decide.
My quote was the entire bug report (except for signatures). Your
decision: it's your bug
> On Mon, 31 May 1999, Julian Gilbey wrote:
>
> > Now that we have a "fixed" priority in the developers-reference (this
> > is not in policy itself), can this proposal be closed?
>
> Well, what I would like to see is a general policy about bugs, covering
> all aspects of bug reporting, forwarding
> On Sun, 30 May 1999, Julian Gilbey wrote:
>
> > > Santiago Vila <[EMAIL PROTECTED]> wrote:
> > > > If not, should we clearly write in policy that hardlinks to conffiles
> > > > should be avoided wherever possible?
> >
> > Please could someone enlighten me about this proposal?
>
> Some time ago
> >>
> >> This would take away the admins ability to make modifications to the
> >> scripts.
> >> I would find this to be a bad thing.
> >
> > Maybe the wording's slightly wrong then. Maybe I should say
> > "locally-modified scripts" rather than "user-modified scripts"?
> >
> > I mean files su
> Brock Rozen wrote:
> > Does this mean that the "proposal-submitting guidelines" will not become
> > part of the policy itself? I think that should be done, as it makes them
> > official and allow for them to be changed officially as policy would
> > dictate (fine, it would dictate itself how it w
> On Mon, 31 May 1999 at 14:47, Santiago Vila wrote about "Bug#38612:...":
>
> > > Package: debian-policy
> > > Version: 2.5.0.0
> > > Severity: wishlist
> > >
> > > It would make a lot of sense if Manoj's proposal-submitting guidelines
> > > were to be placed in the debian-policy package and ref
36 matches
Mail list logo
