On Thu, 22 May 2008, Martín Ferrari wrote:
> Upstream-Bug-Browser:
> http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
> Upstream-Bug-Submitter:
> http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
>
> Which were furiously rejected by many people, in the usual and
> friendly tone c
In March, I proposed adding some useful (to me) fields to the control
file, along this idea:
Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
Which were furiously rejected by many peopl
#include
* Martín Ferrari [Tue, Mar 18 2008, 11:51:45AM]:
> On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote:
>
> > > It would be good if this process could be automated, however I suspect
> > > this header is not the solution.
> >
> > Granted, but then you are speaking a
On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote:
> > It would be good if this process could be automated, however I suspect
> > this header is not the solution.
>
> Granted, but then you are speaking about giving better tool support for
> manually forwarding bugs, which
On Tue, Mar 18, 2008 at 4:53 AM, Andreas Tille <[EMAIL PROTECTED]> wrote:
> Sometimes innovation comes silent. I remember times when we
> have hidden Homepage information behind 'XCBS-URL'. So why
> not using
>
> XCBS-UpstreamBTS
>
> or something like that and experiment with this and se
On Tue, 18 Mar 2008, Raphael Hertzog wrote:
On Tue, 18 Mar 2008, Andreas Tille wrote:
XCBS-UpstreamBTS
I'm opposed to this as well. Homepage and Vcs-* were almost required and
provide the basic pointers about a package but the control file is not
a general-purpose information file.
Well,
On Tue, 18 Mar 2008, Andreas Tille wrote:
>XCBS-UpstreamBTS
>
> or something like that and experiment with this and see how it
> might evolve?
I'm opposed to this as well. Homepage and Vcs-* were almost required and
provide the basic pointers about a package but the control file is not
a gener
On Tue, Mar 18, 2008 at 04:29:41PM +1100, Brian May wrote:
> Ralf Treinen wrote:
>> I do not think that automatically forwarding bugs would be a good idea.
> Right now it is a pain to forward a bug, say to a sourceforge bug
> report, because it involves several steps:
[...]
> It would be good if
On Tue, 18 Mar 2008, Christian Perrier wrote:
without preventing innovative initiatives such as this one
Sometimes innovation comes silent. I remember times when we
have hidden Homepage information behind 'XCBS-URL'. So why
not using
XCBS-UpstreamBTS
or something like that and exper
Quoting Neil Williams ([EMAIL PROTECTED]):
> Please can this 'trend' be stopped here and now?
>
> The Packages.gz file is already enormous (especially for Emdebian
> purposes or other low resource units) and adding yet more fields to
Couldn't there be an opportunity somewhere to have some possib
Brian May <[EMAIL PROTECTED]> writes:
> 4. Send email to [EMAIL PROTECTED] marking the bug as forwarded.
> 5. Wait for response (seems to take ages), fix any errors that
> occurred, go back to step 4.
>
> Generally, I always seem to find new and exciting ways of stuffing up
> step 4 (e.g.
Ralf Treinen wrote:
I do not think that automatically forwarding bugs would be a good idea.
Right now it is a pain to forward a bug, say to a sourceforge bug
report, because it involves several steps:
1. Log into sourceforge
2. Create bug report, copy link to Debian bug report into it.
On Tue, 18 Mar 2008, gregor herrmann wrote:
> Maybe a better place for Tincho's idea would be an (optional)
> debian/bugtracker file (similar to debian/watch).
An important concern is that these sorts of files don't actually
change with the source package, they change whenever the upstream
changes
On Mon, 17 Mar 2008 20:01:30 +, Neil Williams wrote:
> > I appreciate the strive to make Debian work on small machines, but it
> > is reasonable to put their constraints on the whole project?
> IMHO the Packages.gz file is already too large for my standard Debian
> machines!
I see this point
On Mon, 2008-03-17 at 12:16 -0300, Martín Ferrari wrote:
> On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams <[EMAIL PROTECTED]> wrote:
>
> > Please can this 'trend' be stopped here and now?
> >
> > The Packages.gz file is already enormous (especially for Emdebian
> > purposes or other low resourc
"Martín Ferrari" <[EMAIL PROTECTED]> writes:
> On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams <[EMAIL PROTECTED]> wrote:
>
>> The Packages.gz file is already enormous (especially for Emdebian
>> purposes or other low resource units) and adding yet more fields to
>> debian/control is really not
On Mon, Mar 17, 2008 at 4:37 AM, Ben Finney
<[EMAIL PROTECTED]> wrote:
> Those pieces of data are called "fields". Just like in RFC2822
> messages or HTTP responses.
Thanks for the correction. I always think of headers, because one
usually refers to rfc2822 "fields" as "headers", I didn't know
(reply-to as requested)
On Mon, Mar 17, 2008 at 5:45 AM, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> > It could be used to automatically forward bugs,
>
> I don't think bugs should be forwarded automatically.
See my previous mail, I did choose the wrong word here.
> > track which bugs are open t
On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams <[EMAIL PROTECTED]> wrote:
> Please can this 'trend' be stopped here and now?
>
> The Packages.gz file is already enormous (especially for Emdebian
> purposes or other low resource units) and adding yet more fields to
> debian/control is really no
Trying to answer some of the problems pointed out to my proposal...
On Mon, Mar 17, 2008 at 2:49 AM, Russ Allbery <[EMAIL PROTECTED]> wrote:
> I think that if the goal is to support automated tools, pointing to
> straight web pages isn't particularly useful without some additional
> informatio
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote:
> Dear -devel:
>
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug t
On Mon, Mar 17, 2008 at 02:38:19AM -0300, Martín Ferrari wrote:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug trackers.
I
On Mon, Mar 17, 2008 at 02:38:19AM -0300, Martín Ferrari wrote:
> Dear -devel:
>
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstrea
"Martín Ferrari" <[EMAIL PROTECTED]> writes:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug trackers.
Those pieces of d
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote:
> Dear -devel:
>
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug t
On Mon, Mar 17, 2008 at 2:38 PM, Martín Ferrari
<[EMAIL PROTECTED]> wrote:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream
"Martín Ferrari" <[EMAIL PROTECTED]> writes:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to upstream
> bug trackers.
>
> It could be used
Dear -devel:
Following the trend to add metadata to the debian/control file that
allows for the creation of new and powerful tools, I thought about the
usefulness of a header that'd allow to automatically relate to
upstream bug trackers.
It could be used to automatically forward bugs, track which
28 matches
Mail list logo
