On Tue, Nov 28, 2000 at 12:42:24PM -0800, Chris Waters wrote:
> Note that *nothing* we do provides any control over manually submitted
> bugs -- those go whereever the user decides to send them.
We can, however, make recommendations.
Thanks,
--
Raul
On Tue, Nov 28, 2000 at 03:48:46PM -0900, Britton wrote:
> > In other words, we have no way to control what "baddies" do with
> > Debian. The best we can do is make it easy and convenient for
> > "goodies" to do the right thing (whatever that may be). The entire
> > discussion about trying to pr
> In other words, we have no way to control what "baddies" do with
> Debian. The best we can do is make it easy and convenient for
> "goodies" to do the right thing (whatever that may be). The entire
> discussion about trying to prevent "bug report hoarding" is futile and
> moot -- we have no co
On Mon, Nov 27, 2000 at 10:35:58PM -0800, [EMAIL PROTECTED] wrote:
> Would it be technically feasable for a VAD (value-added distributor) to
> be able to tee a bug report, that is have it go to them, AND go to Debian
> with a flag stating that the VAD also has the bug?
It is technically feasible
On Sun, Nov 26, 2000 at 08:17:01PM -0500, Ben Collins wrote:
> Heh, without saying too much, commercial entities working with GPL
> software does not mean that they will turn in bug reports and fixes
> upstream, nor does it mean they mind working with custom patches. This is
A lot of what you're
On Mon, 27 Nov 2000, Britton wrote:
>
> > > > Origin: Debian
> > > > Bugs-To: mailto:[EMAIL PROTECTED]
> > > >
> > > > Which is clearly entirely reasonable and legitimate.
> > >
> > > No, it's not. If you want to make a package special instead of making it
> > > an integral part of Debian cha
On Sun, 26 Nov 2000, Chris Waters wrote:
> On Sun, Nov 26, 2000 at 07:39:13PM -0500, Eric Gillespie, Jr. wrote:
>
> > If Debian decides that bug reports should go to Debian unless
> > we've modified the package, that's what we'll do.
>
> We have no control over it. If evil-third-party Debian r
> > > Origin: Debian
> > > Bugs-To: mailto:[EMAIL PROTECTED]
> > >
> > > Which is clearly entirely reasonable and legitimate.
> >
> > No, it's not. If you want to make a package special instead of making it
> > an integral part of Debian change the Origin tag.
>
> What? It comes from Debian and
On Mon, Nov 27, 2000 at 12:55:18AM -0500, Branden Robinson wrote:
> On Mon, Nov 27, 2000 at 02:22:49PM +1000, Anthony Towns wrote:
> > On Sun, Nov 26, 2000 at 07:51:32PM -0500, Eric Gillespie, Jr. wrote:
> > > [...] though Anthony Towns indicated [...]
> > I'm fairly sure I did no such thing.
> I t
On Mon, 27 Nov 2000 05:55:31 + (UTC),
[EMAIL PROTECTED] (Branden Robinson) said:
> (FWIW, I disagree with Eric that environment variables
> should override command-line options. The real mistake was
That was a mistake on my part. It wasn't difficult to convince me
that i was wrong. My
On Mon, 27 Nov 2000 04:23:09 + (UTC),
aj@azure.humbug.org.au (Anthony Towns) said:
> On Sun, Nov 26, 2000 at 07:51:32PM -0500, Eric Gillespie,
> Jr. wrote:
>> I agree with this, and this is what prompted my original
>> followup. This seems like a win for both sides, though
On Mon, Nov 27, 2000 at 12:55:18AM -0500, Branden Robinson wrote:
> On Mon, Nov 27, 2000 at 02:22:49PM +1000, Anthony Towns wrote:
> > On Sun, Nov 26, 2000 at 07:51:32PM -0500, Eric Gillespie, Jr. wrote:
> > > I agree with this, and this is what prompted my original
> > > followup. This seems like
On Mon, Nov 27, 2000 at 02:22:49PM +1000, Anthony Towns wrote:
> On Sun, Nov 26, 2000 at 07:51:32PM -0500, Eric Gillespie, Jr. wrote:
> > I agree with this, and this is what prompted my original
> > followup. This seems like a win for both sides, though Anthony
> > Towns indicated that he doesn't l
On Sun, Nov 26, 2000 at 08:53:52PM -0800, Chris Waters wrote:
> On Sun, Nov 26, 2000 at 11:08:06PM -0500, Ben Collins wrote:
>
> > Fuck what? If it's none of our business, then why are we worrying about it
> > in the first place?
>
> I have no bloody idea. I have some guesses, but they're not ve
On Sun, Nov 26, 2000 at 11:08:06PM -0500, Ben Collins wrote:
> Fuck what? If it's none of our business, then why are we worrying about it
> in the first place?
I have no bloody idea. I have some guesses, but they're not very
flattering to the people who are doing all this worrying.
> It is our
On Sun, Nov 26, 2000 at 07:51:32PM -0500, Eric Gillespie, Jr. wrote:
> I agree with this, and this is what prompted my original
> followup. This seems like a win for both sides, though Anthony
> Towns indicated that he doesn't like the potential for "hording"
> that this creates.
I'm fairly sure I
> > we don't want to start a precedent where an offshoot distribution
> > can horde fixes and bug reports that Debian should know about.
>
> To put it impolitely, fuck that noise. It's none of our fucking
> business what people do with Debian as long as they obey the licenses
> and provide proper
On Sun, Nov 26, 2000 at 07:39:13PM -0500, Eric Gillespie, Jr. wrote:
> If Debian decides that bug reports should go to Debian unless
> we've modified the package, that's what we'll do.
We have no control over it. If evil-third-party Debian reseller
decides they want the bug reports, they hack th
On Sun, 26 Nov 2000 18:43:54 -0600, Chris Lawrence <[EMAIL PROTECTED]> wrote:
> Anyway, here's how reportbug treats things as of 1.5; YMMV:
>
> - If we find an Origin that we recognize (i.e. in lowercase, it's a
> valid argument to the -B option), we use internal defaults for that
> origin in hand
> > But what if we are interested in it? What if the Debian package
> > maintainers is already working on such a feature?
>
> Heh this is already happening II'm sure.
Then why contribute to it?
> > Uh, integration bugs could be a Debian problem. It could be that a new
> > Debian library upload m
On Sun, 26 Nov 2000, Ben Collins wrote:
> > Many Progeny users files a bug on APT asking that it support clusters
> > better. I having no interest in that stuff so I drop it on a shelf for all
> > eternity.
>
> But that's very argumentative, and asks that the bug tools know the
> interests of e
On Sun, Nov 26, 2000 at 05:45:10PM -0700, Jason Gunthorpe wrote:
>
> On Sun, 26 Nov 2000, Ben Collins wrote:
>
> > Then what if someone installs a Debian package on your distribution? How
> > does that get handled? What if someone wants to integrate a set of
> > packages from another source (not
On Mon, 27 Nov 2000 00:20:51 + (UTC),
[EMAIL PROTECTED] (Jason Gunthorpe) said:
> There are two classes of packages:
> #1 Debian Shared (between our derived dists)
> #2 Vendor Add Ons
> Derived dists want all bugs for group 1 to go to them
> before they go to us so that
On Sun, 26 Nov 2000, Ben Collins wrote:
> Then what if someone installs a Debian package on your distribution? How
> does that get handled? What if someone wants to integrate a set of
> packages from another source (not a distribution) with Debian or Progeny
> (can we say helix)?
Well clearly He
On Nov 26, Jason Gunthorpe wrote:
> > Debian has its own BTS. WTF would you want a Debian package use an
> > alternative BTS? It is either a real part of the distribution and should
> > be treated as such, or not.
>
> The Origin tag should declare what vendor the package came from - in this
> case
On Mon, 27 Nov 2000 00:07:18 + (UTC),
[EMAIL PROTECTED] (Ben Collins) said:
> IMO, Progeny should only get bug reports for packages that
> they intentionally changed. Further more, I don't think
> distributions should take over Debian's job. Progeny and
> other offshoots exist
On Sun, Nov 26, 2000 at 06:58:57PM -0500, Ben Collins wrote:
> IMO, Progeny should only get bug reports for packages that they
> intentionally changed.
The only way to ensure that is the ensure that they don't modify the
bug reporting tools, which is obviously an exercise in futility
(unless we w
On Sun, 26 Nov 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Yes, because you ingored the discussion on -policy and implemented
> > whatever you wanted and then expected it to just become accepted.
>
> Because in my opinion that discussion didn't produce any good
> altern
On Sun, Nov 26, 2000 at 06:54:41PM -0500, Eric Gillespie, Jr. wrote:
> On Sun, 26 Nov 2000 22:59:40 + (UTC),
> [EMAIL PROTECTED] (Wichert Akkerman) said:
>
> > packages? If a derived distro wants to get bugreports for a
> > modified package they have to change it anyway and don't
>
On Sun, 26 Nov 2000 22:59:40 + (UTC),
[EMAIL PROTECTED] (Wichert Akkerman) said:
> packages? If a derived distro wants to get bugreports for a
> modified package they have to change it anyway and don't
> need to modify /etc/dpkg/origins/debian. If they don't then
> the default
Previously Jason Gunthorpe wrote:
> Yes, because you ingored the discussion on -policy and implemented
> whatever you wanted and then expected it to just become accepted.
Because in my opinion that discussion didn't produce any good
alternative.
> What? It comes from Debian and has an alternate b
Previously Raul Miller wrote:
> I presume that packages without a Bugs field will be treated as if
> they have a default value (presumably debbugs), and that packages
> without an Origin field will be treated as if they have a default value
> (perhaps Debian)?
I'm tempted to suggest that the defau
On Sun, 26 Nov 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Yeah this isn't such a good idea. For instance I would tag some of my APT
> > builds to be
>
> Sigh. Here we go again.
Yes, because you ingored the discussion on -policy and implemented
whatever you wanted and
> So what if a friend gives me a floppy with a package and I have no
> idea where it comes from and only email net access?
Then you could E-mail your friend or the maintainer, and ask them to
E-mail you back the tiny origin file or the tiny package containing
it. I don't see why this is any diffe
I presume that packages without a Bugs field will be treated as if
they have a default value (presumably debbugs), and that packages
without an Origin field will be treated as if they have a default value
(perhaps Debian)?
Also:
On Sun, Nov 26, 2000 at 04:28:44AM +0100, Wichert Akkerman wrote:
> O
Previously Itai Zukerman wrote:
> Your assertion is, I think, something along the lines of, "What if I
> don't have access to the Foo origin data?" My response to that is,
> "Well, where did you get the package with origin Foo? You should be
> able to get the Foo origin file from the same place."
> > I think the package should be able to override any default origin
> > data, not the other way around.
>
> No, a package needs to have its own info since the origin file might
> not exist.
I don't follow the reasoning behind that, so maybe a specific example
will clear things up. Here's how I
Previously Jason Gunthorpe wrote:
> Yeah this isn't such a good idea. For instance I would tag some of my APT
> builds to be
Sigh. Here we go again.
> Origin: Debian
> Bugs-To: mailto:[EMAIL PROTECTED]
>
> Which is clearly entirely reasonable and legitimate.
No, it's not. If you want to make a
Previously Itai Zukerman wrote:
> I think the package should be able to override any default origin
> data, not the other way around.
No, a package needs to have its own info since the origin file might
not exist.
> Also, I think Origin: Debian packages should not specify a Bugs field,
> since bu
On 25 Nov 2000, Itai Zukerman wrote:
> I think the package should be able to override any default origin
> data, not the other way around.
Yeah this isn't such a good idea. For instance I would tag some of my APT
builds to be
Origin: Debian
Bugs-To: mailto:[EMAIL PROTECTED]
Which is clearly en
On Nov 25, Itai Zukerman wrote:
> On Sun, 26 Nov 2000 04:28:44 +0100, Wichert Akkerman <[EMAIL PROTECTED]>
> wrote:
> > Origin gives a package a way to indicate where it is coming from.
> > This can be used to find information about its origin in
> > /etc/dpkg/origins/. The origin information file
On Sun, 26 Nov 2000 04:28:44 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Origin gives a package a way to indicate where it is coming from.
> This can be used to find information about its origin in
> /etc/dpkg/origins/. The origin information file there
> can list an Bugs field that overri
Package: debian-policy
Severity: normal
Now that dpkg 1.7 has hit unstable and the first bugreporting tool
(reportbug) supports it I figured it was time to get this into
policy.
The basic idea of this is to have a way for packages to state
where they are coming from, and where bugreports for them
43 matches
Mail list logo
