On Sunday 18 May 2008, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
You seem to forgot that people will actually work with the source
code and actual patches applied to it, not with a bunch of patches
floating in Debian BTS with not so clear/predictable state
On 18/05/08 at 16:44 +0100, Neil Williams wrote:
On Sun, 2008-05-18 at 17:05 +0200, Lucas Nussbaum wrote:
On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
But the problem we want to solve is making things easier for
On Sunday 18 May 2008, Russ Allbery wrote:
--cut--
Isn't this already the case in practice? Do you really see many Debian
packages that have modified *.orig.tar.gz tarballs? And if so, have you
filed bugs?
Sorry for the delay, but now I saw that Don Armstrong also asked such a
question,
On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote:
The problem I am interested in solving is:
It is currently difficult for people not involved in Debian
development (upstream, other distros, users) to know which patches we
applied, the reason for the patch, and whether
On Sun, May 18, 2008 at 07:53:39PM +0300, George Danchev wrote:
On Sunday 18 May 2008, Russ Allbery wrote:
Isn't this already the case in practice? Do you really see many Debian
packages that have modified *.orig.tar.gz tarballs? And if so, have you
filed bugs?
Sorry for the delay, but
On Sat, May 17, 2008 at 06:57:54PM -0400, Joey Hess wrote:
In that case, it really doesn't matter whether the list of Debian
patches is on patches.debian.org, or on a page in the BTS. If upstream
wants to, they can look at them either way.
Sure it matters, for example for other Debian
On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:
1/ check bts-link is aware of your upstream BTS (means that there is a
small configuration step to do once and for all) and that the kind
of BTS it uses it supported. RT isn't. Launchpad should be
Uh, rt.cpan.org
(please don't remove Ccs. I added one for a reason)
On 18/05/08 at 18:02 +0100, Neil Williams wrote:
On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote:
The problem I am interested in solving is:
It is currently difficult for people not involved in Debian
development
On Sun, May 18, 2008 at 05:19:28PM +, Niko Tyni wrote:
On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:
1/ check bts-link is aware of your upstream BTS (means that there is a
small configuration step to do once and for all) and that the kind
of BTS it uses
On Sun, 18 May 2008, Neil Williams wrote:
Yes - supported by the use of (Fixed: #1234) in
debian/changelog, .changes etc. and a revised interface for PTS and DDPO
to discriminate between Fixed and Closed bugs.
I could easily handle this by just not archiving bugs tagged
divergence; when it's
On Sun, 2008-05-18 at 19:39 +0200, Lucas Nussbaum wrote:
(please don't remove Ccs. I added one for a reason)
(Not sure you want d-devel and direct since I know you are subscribed,
so removed that one. :-))
That sounds logical to have both:
- they know that distro devs are not perfect and
On Sun, 2008-05-18 at 18:51 +0100, Don Armstrong wrote:
On Sun, 18 May 2008, Neil Williams wrote:
Yes - supported by the use of (Fixed: #1234) in
debian/changelog, .changes etc. and a revised interface for PTS and DDPO
to discriminate between Fixed and Closed bugs.
I could easily handle
(you can skip to the end for a summary of what I think we agree on)
On 18/05/08 at 19:49 +0100, Neil Williams wrote:
I still like the two-stage closure option because sometimes we just need
to upload a fix before an upstream release can be made and the bug
submitter should know that the
On Sun, 2008-05-18 at 21:40 +0200, Lucas Nussbaum wrote:
(you can skip to the end for a summary of what I think we agree on)
The only
thing that he would additionaly get is a notification when the change is
applied upstream and fixed in Debian by a new upstream version.
Don echoed
'morning Neil and everybody. So many mails to read for breakfast!
Le Sun, May 18, 2008 at 03:51:18PM +0100, Neil Williams a écrit :
proposal:
[EMAIL PROTECTED] | (Fixes: #nnn)
marks the bug as fixed by a patch added by Debian and
awaiting a new release upstream to be finally
On Sunday 18 May 2008, Bastian Blank wrote:
--cut--
| $ md5sum dist*
| 7417436d2d0cbe9322d7503041c2e2df [EMAIL PROTECTED]
| b959d34e40b01303e98a6b85255dd92d dist_3.70.orig.tar.gz
| $ mkdir 1 2
| $ tar -C 1 -xzf [EMAIL PROTECTED]
| $ tar -C 2 -xzf dist_3.70.orig.tar.gz
| $ diff -urN
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite naturally..
The bug can be tracked, with a patch,
On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug?
WTF ? What's the point of free software if we invent rules for not
modifying them ? And well, we're in a bad posture then, because glibc
without patches
On Sat, May 17, 2008 at 05:01:08PM -0400, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from
On Sat, May 17, 2008, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
The bug tracker is a tool for me; not
On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug?
WTF ? What's the point of free software if we invent rules for not
modifying them
Mike Hommey wrote:
The BTS would also need something to make it easier to spot patches in a
bug. Patch tracking is one of the few things bugzilla is not bad at, for
instance.
I guess you're talking about a way for the BTS allow downloading of the last
(or preferred) patch sent to a bug. And
On Sat, May 17, 2008 at 09:13:03PM +, Mike Hommey wrote:
On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug?
WTF ? What's
On Sat, 2008-05-17 at 23:08 +0200, Pierre Habouzit wrote:
On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug?
WTF ? What's the point of free software if we invent rules for not
modifying them ?
?
On Sat, May 17, 2008 at 09:22:53PM +, Neil Williams wrote:
email from incoming that a new version needs to be prepared for Emdebian
because it nearly always fails first time, despite working last time.
welcome to our (mostly Aurélien's) world, because if you see the
revisions, you'll know
On Sat, May 17, 2008 at 05:21:52PM -0400, Joey Hess wrote:
Mike Hommey wrote:
The BTS would also need something to make it easier to spot patches in a
bug. Patch tracking is one of the few things bugzilla is not bad at, for
instance.
I guess you're talking about a way for the BTS allow
Loïc Minier wrote:
The bug tracker is a tool for me; not everything needs to go via bug
tracking.
I'm not thinking about using the BTS for this just because it happens to
be the hammer at hand, but instead because it looks to be a tool that
allows solving a large percentage of the
Pierre Habouzit wrote:
Okay, still I dislike the idea a lot.
You actually only read the first sentence at first?
the BTS is unusable past 100 bugs.
Every package accumulates 100 closed bugs after some period of time,
and this does not make the BTS unusable for that package, because the
On Sat, 2008-05-17 at 23:22 +0200, Pierre Habouzit wrote:
Okay, still I dislike the idea a lot. the BTS is unusable past 100
bugs.
? there are ways of managing lots and lots of bugs via custom scripts
and the SOAP interface or usertags or the filters at the end of each bug
index page.
For
Joey Hess [EMAIL PROTECTED] writes:
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite
On Sat, May 17, 2008 at 09:42:47PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Okay, still I dislike the idea a lot.
You actually only read the first sentence at first?
The 3 first. I assumed that everyone knows it's best to present a
summary of your idea in the first paragraph.
On Sat, May 17, 2008 at 09:38:06PM +, Joey Hess wrote:
Loïc Minier wrote:
allows solving a large percentage of the requirements, and already
interoperates with other tools (including upstream BTSes and mailing lists).
If by interoperates with upstream BTSes you mean bts-link, then
it's
On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:
Also, these aren't bugs in the Debian package, but rather bugs in upstream
(at least arguably), which put them into a different brainspace than
Debian bugs at least for me, and I'd find it awkward and confusing to have
them mixed in
On Sat, May 17, 2008 at 09:54:54PM +, Pierre Habouzit wrote:
and tracking actual content (like patches, modifications of them, and if
they got merged fully, partially, modified, rejected …) both ways.
And to be frank, when rereading that sentence, I know a project that
does that, and it's
Pierre Habouzit wrote:
The 3 first. I assumed that everyone knows it's best to present a
summary of your idea in the first paragraph.
You seem to have actually missed the second sentence, A change might be
a bug in upstream, or in the debianisation, or in Debian for requiring
the change..
Mike Hommey [EMAIL PROTECTED] writes:
On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:
Also, these aren't bugs in the Debian package, but rather bugs in
upstream (at least arguably), which put them into a different
brainspace than Debian bugs at least for me, and I'd find it
On 17/05/08 at 17:01 -0400, Joey Hess wrote:
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite
On Sat, May 17, 2008 at 10:07:33PM +, Joey Hess wrote:
In my original mail, I said that bugs tagged as divergences could
likewise be sorted out of the way.
I'm not convinced
You're not convinced that divergences could be sorted out of the way in
the bug display? Is there
On Sat, 17 May 2008, Joey Hess wrote:
The bug can be tracked, with a patch, in our BTS. The bug can be
forwarded upstream as the patch is sent upstream. A tag divergence
can be used to query for all such bugs, or to sort such bugs out of
the way.
It actually might even be useful to expose the
On Sat, 17 May 2008, Pierre Habouzit wrote:
The BTS is not well suited for that, so we're back to discussing about
which tool is best for doing that, as discussing how to do that in the
source package failed, we go to the BTS.
If people actually decide to do this, it's not that huge of a
.
The biggest reason for using the BTS is not technical. It's that, if we
decide that the project will treat divergence from upstream as a bug,
then we've effectively decided that maintainers will be responsible for
both minimising unncessary divergence, communicating about it to
upstream, and for keeping
On Sat, 17 May 2008, Joey Hess wrote:
Mike Hommey wrote:
The BTS would also need something to make it easier to spot patches in a
bug. Patch tracking is one of the few things bugzilla is not bad at, for
instance.
I guess you're talking about a way for the BTS allow downloading of the
Pierre Habouzit wrote:
No I read them, and I'm interested in how you intend to do so
_automatically_. Because if it isn't automatic, then we're back to the
current situation _plus_ filing bug in our own BTS. I fail to see where
the revolution is.
And I believe the automation of sending
Lucas Nussbaum wrote:
(This discussion is similar to the one about DEPs vs BTS bugs -- a
discussion on the BTS would always miss a summary.)
IIRC someone (possibly me or maybe it was aj) posted a design to solve
the lack of a bug summary in the DEP thread.
--
see shy jo
signature.asc
Don Armstrong wrote:
One of the wishlist features for the BTS that I've been contemplating
setting up is a summary feature, whre the current summary of a bug
is shown at the top, with the history continuing below.
Ah, I think that's the thing I was remembering from the DEP thread.
A mail to
Le dimanche 18 mai 2008 à 00:29 +0200, Pierre Habouzit a écrit :
And I believe the automation of sending bugs upstream unsolvable,
because I tried to solve it, and failed. Of course, when upstream is
Mailing-list driven this is easy. But when your upstream is KDE (or
glibc, or ..) that uses
Don Armstrong wrote:
Other tags and BTS data can be used if desired. For example,
divergence fixed-upstream, divergence wontfix, divergence
help. Versioning information can be used to track when an upstream
version resolves the divergence. Discussion and updated patches can
be CCed to
Joey Hess [EMAIL PROTECTED] writes:
The biggest reason for using the BTS is not technical. It's that, if we
decide that the project will treat divergence from upstream as a bug,
then we've effectively decided that maintainers will be responsible for
both minimising unncessary divergence
Le samedi 17 mai 2008 à 15:53 -0700, Don Armstrong a écrit :
If people actually decide to do this, it's not that huge of a deal to
make whatever changes are necessary to the BTS to make packages with
large numbers of such bugs easily manageable.
[In fact, making the handling of packages with
On Sat, 17 May 2008, Joey Hess wrote:
A mail to the bug is marked as a summary by a special pseudo-header
or such, right?
Right. There will also be a control command so you can indicate a
message is the summary post-facto (or remove a summary.
Don Armstrong
--
Clint why the hell does
On Sat, May 17, 2008 at 10:57:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
No I read them, and I'm interested in how you intend to do so
_automatically_. Because if it isn't automatic, then we're back to the
current situation _plus_ filing bug in our own BTS. I fail to see where
Russ Allbery wrote:
Some of that divergence is, realistically, bugs that won't be fixed. For
example, I patch the Shibboleth SP Makefile because I remove one XML
schema which is under a non-free license (no modification allowed).
Realistically, that upstream difference isn't ever going to go
this idea as
Tracking divergence from upstream as a bug in the Subject field.
--
\When you go in for a job interview, I think a good thing to |
`\ ask is if they ever press charges. -- Jack Handey |
_o__) |
Ben
Joey Hess [EMAIL PROTECTED] writes:
Hmm, another thought is, I sometimes have a changelog like this:
* New upstream release.
- Including my fix for foo.
- And a better approach than my old hack to fix bar.
It would be nice to be able to add bug numbers to close the
divergences when
Joey Hess [EMAIL PROTECTED] writes:
I think that going back and collecting all the patches I've sent to
upstreams over the years, and any I've dropped on the floor, and
keeping it up-to-date going forward will help me maintain my
packages better anyway, so I plan to do that this week. Though
Ben Finney [EMAIL PROTECTED] writes:
Joey Hess [EMAIL PROTECTED] writes:
(And then an automatic system closing any I forget to mention would be
nice.)
What information would trigger such automation, in the absence of you
noting it as such in the changelog entry?
For a patch that we know
I'm not sure whether you mean bug in the strict sense or in the BTS's
sense. Do you think a divergence is a minor bug or a wishlist bug? I
disagree that any divergence is a bug, but there may be a request to get
rid of a divergence.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Ben Finney wrote:
Care to discuss what tags you plan to use, so an attempt at consensus
can be made on naming the tags for this purpose?
I'm using a divergence usertag, with users [EMAIL PROTECTED] and
[EMAIL PROTECTED] (so it'll show up on my bugs page, and the
package's bug page -- not
Filipus Klutiero [EMAIL PROTECTED] writes:
I'm not sure whether you mean bug in the strict sense or in the BTS's
sense. Do you think a divergence is a minor bug or a wishlist bug? I
disagree that any divergence is a bug, but there may be a request to get
rid of a divergence.
I won't speak
naturally..
I have read that mail several times and I believe that divergence from
upstream as a bug is not the precise enough, it should be put instead hard
to get for peer reviewers divergences from upstream is a bug.
I'll give you an example with aalib (one of your packages where you
101 - 160 of 160 matches
Mail list logo
