On fredagen den 13 juni 2008, Don Armstrong wrote:
On Fri, 13 Jun 2008, Magnus Holmgren wrote:
The downside is that a bug can't simply be downgraded from fixed to
patched; it would have to be marked found and patched in the same
version, but that's hopefully a relatively rare situation.
On Sat, 21 Jun 2008, Magnus Holmgren wrote:
For some reason I forgot that a bug isn't automatically closed when
it's marked fixed in all existing branches. As long as the new
changelog/changes command (Fixes:/Patches:) causes the bug to be
marked fixed but not closed, we're fine.
We don't
On måndagen den 19 maj 2008, Lucas Nussbaum wrote:
My point is: We don't want to change version-tracking to track this
Fixes notion in addition to the Closes notion. Version-tracking is
complex enough already.
It shouldn't have to become more complex. We could simply run the same
algorithm
On Fri, 13 Jun 2008, Magnus Holmgren wrote:
The downside is that a bug can't simply be downgraded from fixed to
patched; it would have to be marked found and patched in the same
version, but that's hopefully a relatively rare situation.
Why do we need to track which revisions have
also sprach Russ Allbery [EMAIL PROTECTED] [2008.05.18.0401 +0100]:
I won't speak for Joey, but I consider a divergence a bug in the sense
that I'd use with a general bug-tracking system: it's something about the
package and/or the packaged software that, in an ideal world, would be
improved.
also sprach Joey Hess [EMAIL PROTECTED] [2008.05.17.2238 +0100]:
If you grab a patch from upstream that you know will be in a future
upstream release, the divergence is temporary. You can choose not to
file a bug report in our BTS about it, knowing that it will clear up.
... and suddenly the
also sprach Joey Hess [EMAIL PROTECTED] [2008.05.17.2201 +0100]:
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
martin f krafft [EMAIL PROTECTED] writes:
also sprach Russ Allbery [EMAIL PROTECTED] [2008.05.18.0401 +0100]:
I won't speak for Joey, but I consider a divergence a bug in the sense
that I'd use with a general bug-tracking system: it's something about
the package and/or the packaged software
On Tue, 20 May 2008, Pierre Habouzit wrote:
TTBOMK emacs does too.
Emacs is currently evaluating debbugs.
Don Armstrong
--
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
-- Douglas Adams _The Long Dark Tea-Time of the Soul_
On Mon, 19 May 2008, Stefano Zacchiroli wrote:
How I'm reading the latter paragraph is that patch messages are
*alternative* as some non-patch summary message, am I wrong? I think
the two should be orthogonal: you can have or not a summary message,
you can have or not a patch.
The idea was
On Tue, May 20, 2008 at 09:02:21AM +0100, Don Armstrong wrote:
The idea was that a patch, since it would actually contain the
resolution of the original problem, would be the correct place to
summarize the problem. However, on thinking about it more, I think
that having a single summary, with
On Tue, 20 May 2008, Stefano Zacchiroli wrote:
On Tue, May 20, 2008 at 09:02:21AM +0100, Don Armstrong wrote:
The idea was that a patch, since it would actually contain the
resolution of the original problem, would be the correct place to
summarize the problem. However, on thinking about it
On Tue, May 20, 2008 at 07:50:10AM +, Don Armstrong wrote:
On Tue, 20 May 2008, Pierre Habouzit wrote:
TTBOMK emacs does too.
Emacs is currently evaluating debbugs.
Well, then my point stands, debbugs _is_ also a sane BTS for reporting
bugs :)
--
·O· Pierre Habouzit
··O
On Tue, May 20, 2008 at 07:48:55AM +0200, Goswin von Brederlow wrote:
Michael Banck [EMAIL PROTECTED] writes:
Try to git-format-patch (or whatever tool applies for the particular
DVCS) each feature branch, see whether they apply cleanly by
luck/accident. If so, store them as a 3.0 (quilt)
On Tue, May 20, 2008 at 10:28:45AM +0100, Don Armstrong wrote:
Fair enough, but why are you referring to a _set_ of patches?
There may just be one current patch, but having access to the previous
patches and/or attachments which describe the problem easily is
useful. Whether debbugs display
On Tue, 20 May 2008, Stefano Zacchiroli wrote:
The only non trivial design issue is that it should be possible to
mark some of the patches as denoting the current patch state
Presumably the most recent patch is the current one; that's what I'm
actually going to do for summaries.
Don Armstrong
Ben Finney [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
The proposal is about tracking the required patches in the BTS.
Should have said tracking the state of patches. Didn't mean the
patches verbatim.
No, the bug is about classifying divergence from upstream
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 18/05/08 at 15:55 +0200, Goswin von Brederlow wrote:
Esspecially when you have debian specific patches where things are a
clear divergence there won't be an upstream record.
If there's a patch that is not going to be useful outside of Debian, and
Bernhard R. Link [EMAIL PROTECTED] writes:
* Goswin von Brederlow [EMAIL PROTECTED] [080518 16:09]:
The quilt extension is certainly a big improvement and will hopefully
unify a lot of patch system using packages after lenny.
Though I guess there still needs to be a way to get such a
On Mon, 19 May 2008, Charles Plessy wrote:
Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds To
be merged upstream: to the subject, and sends a message saying This
bug has been fixed by patching the original sources; we will forward
this patch to the upstream authors and
On 19/05/08 at 09:14 +0900, Charles Plessy wrote:
'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
On Mon, 19 May 2008, Lucas Nussbaum wrote:
Two additional changes could be made as well, to help with the process:
1) add parsing for Closes-with-patch: in changelog. This closes the
bug normally, and also tags the bug + divergence. sounds
non-disruptive.
This should actually probably
On 19/05/08 at 08:48 +0200, Goswin von Brederlow wrote:
Lucas Nussbaum [EMAIL PROTECTED] writes:
and update the corresponding bug report, and it doesn't work with
version-tracking, which would need to be updated have 3 notions:
- notfound (already exist)
???
- fixed using a Debian
On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
Fix-Debian-Bug: 5
I think that:
Fixes: http://bugs.debian.org/5
is better. The patch might fix a problem not reported in Debian. For
example, the Debian maintainer might monitor Ubuntu's bug tracker, see a
bug reported there, and fix
On Mon, 19 May 2008, Lucas Nussbaum wrote:
On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
Fix-Debian-Bug: 5
I think that:
Fixes: http://bugs.debian.org/5
is better. The patch might fix a problem not reported in Debian. For
example, the Debian maintainer might monitor
On Sunday 18 May 2008, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
The diff.gz contains all the changes including the debian dir. It is
by no means obvious if there are patches in there or not.
I think reading a debian diff is the every day job of DD and DAs. And all
of
On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
2) feature branches
Each feature branche is based on upstream (with few exceptions) and
contains all changes for one feature.
Then you have an integration branche where all feature branches are
merged. The merging
On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
You're describing a situation where upstream is difficult or impossible
to communicate with. I can't solve that, nor can anyone except upstream.
Except that once again, upstream that would benefit from our system
the most
On Sun, May 18, 2008 at 01:17:09AM +0200, Josselin Mouette wrote:
That would be very nice. I think you could easily make giant
improvements by reworking the bug listing pages. They would be much more
useful with a table listing all bugs with one bug per line, color
indicators for the severity,
On Sat, May 17, 2008 at 03:55:12PM -0700, 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.
This could be easily extended to
On Mon, May 19, 2008 at 09:40:09PM +, Stefano Zacchiroli wrote:
On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
You're describing a situation where upstream is difficult or impossible
to communicate with. I can't solve that, nor can anyone except upstream.
Except
Michael Banck [EMAIL PROTECTED] writes:
On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
2) feature branches
Each feature branche is based on upstream (with few exceptions) and
contains all changes for one feature.
Then you have an integration branche where all
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream communication
processing which brings even more complexity to the
On Sat, 2008-05-17 at 23:01 -0400, Joey Hess wrote:
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 Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software which does not work without patches is IMHO buggy.
Despite the technical fact in this specific case it also forces divergences
between distributions -
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 Sun, 18 May 2008, Josselin Mouette wrote:
That would be very nice. I think you could easily make giant
improvements by reworking the bug listing pages. They would be much more
useful with a table listing all bugs with one bug per line, color
indicators for the severity, and a column on the
On Sunday 18 May 2008, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream communication
processing
On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote:
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
Joey Hess wrote:
FWIW, I like the general idea of tracking upstream diverge with a bug.
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
Neil Williams [EMAIL PROTECTED] writes:
However, from a bug submitter point of view, I don't think I want to
see the bug report kept open (tagged divergence) after it has
actually been closed by a Debian-specific patch. As upstream it
might make a fair bit of sense but as a user / bug
On Sun, May 18, 2008 at 07:39:07AM +, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software which does not work without patches is IMHO buggy.
Despite the technical fact in
On Sun, May 18, 2008, 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.)
I didn't follow this discussion, but it strikes me that many bug
trackers have a summary for bugs.
--
Loïc Minier
--
To
On Sun, 2008-05-18 at 18:43 +1000, Ben Finney wrote:
Neil Williams [EMAIL PROTECTED] writes:
However, from a bug submitter point of view, I don't think I want to
see the bug report kept open (tagged divergence) after it has
actually been closed by a Debian-specific patch. As upstream it
On Sat, May 17, 2008, Joey Hess wrote:
If I grab an upstream change from their VCS, I wont open a
Debian bug about it; if I find a bug in the Debian version which also
applies to upstream, I might skip to directly reporting it upstream,
and only there.
If you grab a patch from
On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote:
The
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
So it's already the case that they have a certain number of places
to look, *including* the Debian BTS if the work is packaged for
Debian. I don't see that this proposal changes that.
On Sunday 18 May 2008, Ben Finney wrote:
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
…
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software which does not work without patches is IMHO buggy.
Do you have a proposal for a
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software which does not
On Sun, May 18, 2008 at 09:57:02AM +, Ben Finney wrote:
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
So it's already the case that they have a certain number of places
to look, *including* the Debian BTS if the work is
On 18/05/08 at 19:57 +1000, Ben Finney wrote:
As I understand it, the proposal is to put *new* information (that
Debian source diverges, and exactly why) into an existing location
that is already a place we expect upstream to know about (the Debian
BTS)
Huh? Upstreams knowing about the Debian
Pierre, please fix your MUA to honour the request I made earlier: stop
sending individual copies of messages that you also send to the Debian
lists. It's a request in the mailing list guidelines, and I've
explicitly pointed it out earlier.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May
Mike Hommey a écrit :
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 18/05/08 at 19:57 +1000, Ben Finney wrote:
As I understand it, the proposal is to put *new* information (that
Debian source diverges, and exactly why) into an existing location
that is already a place we expect upstream to know about (the
naturally..
After re-reading the whole thread, I still have several concerns
about the idea of tracking each divergence from upstream as a bug in
the BTS, and I still don't think it's a good idea.
1) It duplicates information. We will already duplicate information
between the patch description
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
Do you have a proposal for a remplacement of the glibc then?
And note we *do* forward patches we apply to the Debian Glibc, which is
not always something pleasant to do, especially when it concerns
embedded crap [1]: at best your
Hi,
On Sat, 17 May 2008, Joey Hess wrote:
The state of a bug being a divergence can just be one step in the
life-cycle of a bug.
Consider a new bug filed one a package, which turns out to be an
upstream bug, is forwarded upstream, gets patched in Debian, and then
has the patch forwarded
On Sunday 18 May 2008, Ben Finney wrote:
Again, the BTS is not yet another place; it's already a place where
Debian-specific information needs to be about other changes to the
package. It's a proposal to *consolidate* information into a place
that already has much similar information for
* Joey Hess [EMAIL PROTECTED] [080517 23:01]:
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
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
(applied/unapplied/blamed/whatever). Such a service to can
On Sun, May 18, 2008 at 02:44:49PM +0200, Bernhard R. Link wrote:
I'd suggest to start with making pristine upstream tarballs (or pure
subsets of those) obligatory. No modifications allowed in there and no
exceptions.
How would you define no modifications? Even a subset already implies
On Sun, May 18, 2008 at 10:24:10AM +, Ben Finney wrote:
Pierre, please fix your MUA to honour the request I made earlier: stop
sending individual copies of messages that you also send to the Debian
lists. It's a request in the mailing list guidelines, and I've
explicitly pointed it out
Aurelien Jarno [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best support for Joey's proposal?
A software which does not work without patches is IMHO
Raphael Hertzog [EMAIL PROTECTED] writes:
BTW, as a side thought, we could have tools that give list of bugs
tagged divergence which are not forwarded and as the task of forwarding
those is not really difficult when the patch is well commented, we could
have many contributors helping us to
Pierre Habouzit [EMAIL PROTECTED] writes:
FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
honour that.
What I've requested is laid out in the Debian mailing list code of
conduct as behaviour to be expected in the absence of explicit
requests. A Mail-Followup-To field
On Sun, May 18, 2008 at 01:14:09PM +, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
You wil have hard time teaching every upstream in Debian BTS (new)
tags and features, but they all already know how to deal well
prepared diffs from debian ftp mirrors.
I've gone back to
Bernhard R. Link [EMAIL PROTECTED] writes:
* Joey Hess [EMAIL PROTECTED] [080517 23:01]:
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
Neil Williams [EMAIL PROTECTED] writes:
On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote:
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
Goswin von Brederlow [EMAIL PROTECTED] writes:
The proposal is about tracking the required patches in the BTS.
No, the bug is about classifying divergence from upstream as a bug
to be tracked in the Debian BTS. The location of patches isn't a
necessary part of the proposal.
Patches in the BTS
On Sun, May 18, 2008 at 01:26:20PM +, Ben Finney wrote:
Pierre Habouzit [EMAIL PROTECTED] writes:
FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
honour that.
What I've requested is laid out in the Debian mailing list code of
conduct as behaviour to be expected
Pierre Habouzit [EMAIL PROTECTED] writes:
[tracking divergence from upstream as a bug in the Debian BTS is]
additional work. That's creepy and uninteresting work to begin with,
its useless with proper upstreams, and is needed only for bad
upstreams, that won't eve take a glance at all
Ben Finney [EMAIL PROTECTED] writes:
I don't have enough experience using the BTS to interact with upstream
to comment on this, but I'll watch the responses of others (who do have
such experience) with interest.
You basically can't, currently, use the BTS to interact with upstream,
only note
Goswin von Brederlow [EMAIL PROTECTED] writes:
Aurelien Jarno [EMAIL PROTECTED] writes:
And note we *do* forward patches we apply to the Debian Glibc, which is
not always something pleasant to do, especially when it concerns
embedded crap [1]: at best your patch is ignored, at worst you get
.
Everything else follows from that quite naturally..
After re-reading the whole thread, I still have several concerns
about the idea of tracking each divergence from upstream as a bug in
the BTS, and I still don't think it's a good idea.
1) It duplicates information. We will already duplicate
On Sun, May 18, 2008 at 01:37:53PM +0300, Riku Voipio wrote:
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
Do you have a proposal for a remplacement of the glibc then?
And note we *do* forward patches we apply to the Debian Glibc, which is
not always something pleasant
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 01:26:20PM +, Ben Finney wrote:
What I've requested is laid out in the Debian mailing list code of
conduct as behaviour to be expected in the absence of explicit
requests. A Mail-Followup-To field setting may or may not
* Bastian Blank [EMAIL PROTECTED] [080518 15:17]:
On Sun, May 18, 2008 at 02:44:49PM +0200, Bernhard R. Link wrote:
I'd suggest to start with making pristine upstream tarballs (or pure
subsets of those) obligatory. No modifications allowed in there and no
exceptions.
How would you define
On Sun, May 18, 2008 at 03:19:28PM +0200, Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
On Sat, 17 May 2008, Pierre Habouzit wrote:
... glibc without patches can't work.
Isn't this the best
Bernhard R. Link [EMAIL PROTECTED] writes:
We have already such a place. It's called the .diff.gz. It's linked
everywhere, on every mirror in the same directory as the software.
This file is there to contain and show what is changed.
Admitted, the original one file diff is not perfect for
On Sun, May 18, 2008 at 01:49:36PM +, Russ Allbery wrote:
Yes, there is bts-link -- I don't know how well it works having never
been lucky enough to have an upstream with a tracker that it support, so
far as I can tell. Or maybe I just don't know how to use it? My
upstreams use RT,
On Sun, May 18, 2008 at 02:11:09PM +, Pierre Habouzit wrote:
of BTS it uses it supported. RT isn't. Launchpad should be
supported since yesterday thanks to Jelmer Vernooij, sf.net is
Okay #417692 shows that it's a bit flaky atm, but it should be fixed
quite soon :)
--
·O·
* Russ Allbery [EMAIL PROTECTED] [080518 15:28]:
Except that it has an important scope problem. Divergences with the
Debian package are not open bugs in Debian, they are open bugs in
upstream that are localy fixed within Debian.
I don't think this is as universally true as it looks on
On 18/05/2008, Pierre Habouzit wrote:
oh boy, are we really fighting over a dupe of a mail ? wasting 4k of
data and two keystrokes ? (in mutt, D~=\n will remove dupes, kmail has
the same functionnality, and most decent MUA do to). CoC is meant to
reduce rudeness, not technical issues from
On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:
IOW basically, just do your usual workflow, bts-link adds 0 overhead
on your work, that's exactly why it's valuable.
Huh? This is just as true for the proposal we're discussing here, which
you seem to claim gives too much
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
upstreams.
Oh? When I read the proposal, I understood that the problem we want to
solve is about tracking changes we make to upstream. If upstream wants
those changes,
,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite naturally..
After re-reading the whole thread, I still have several concerns
about the idea of tracking each divergence from upstream as a bug in
the BTS, and I still don't think it's
On Sun, May 18, 2008 at 12:07:04PM +0200, Lucas Nussbaum [EMAIL PROTECTED]
was heard to say:
A saner solution would be to only use the BTS when it's not possible
to discuss the patch with upstream. We could do the following:
- add pseudo-headers in the patches for:
+ URL of the bug that
Bernhard R. Link [EMAIL PROTECTED] writes:
* Russ Allbery [EMAIL PROTECTED] [080518 15:28]:
I don't think this is as universally true as it looks on first glance.
Often the reason why the divergence remains a divergence is because
it's a quick hack that only works on (for example) Linux
On Sun, 2008-05-18 at 15:30 +0200, Goswin von Brederlow wrote:
Neil Williams [EMAIL PROTECTED] writes:
1 - User reports bug with a patch against upstream code
[open, patch]
2 - maintainer forwards the patch upstream
[confirmed, patch, upstream, forwarded]
3 - maintainer
* Goswin von Brederlow [EMAIL PROTECTED] [080518 16:09]:
The diff.gz contains all the changes including the debian dir. It is
by no means obvious if there are patches in there or not.
The limit to a single file is a real problem. But at least the
information has to be in there, and a .diff is
In article [EMAIL PROTECTED] you wrote:
The diff.gz contains all the changes including the debian dir. It is
by no means obvious if there are patches in there or not.
I think reading a debian diff is the every day job of DD and DAs. And all of
them learned to search for +++ and ignore debian/.
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
upstreams.
Oh? When I read the proposal, I understood that the problem we want to
solve is about tracking changes we
On Sun, May 18, 2008 at 03:05:41PM +, 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
upstreams.
Oh? When I read the proposal, I
OoO En ce début d'après-midi ensoleillé du dimanche 18 mai 2008, vers
15:56, Ben Finney [EMAIL PROTECTED] disait:
Then please have it reduce your rudeness, and comply with explicit
requests both from me and the ML CoC: stop sending unwanted mail
messages when the messages are already sent
* Russ Allbery [EMAIL PROTECTED] [080518 16:50]:
Bernhard R. Link [EMAIL PROTECTED] writes:
I think adding a website which nicely formats those files (with
diffstats, and properly showing included patch files) would be a thing
that really helps all involved people. Not only upstreams
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
upstreams.
Oh? When I read the proposal, I understood
2008/5/18 Lucas Nussbaum [EMAIL PROTECTED]:
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 they should be
interested
1 - 100 of 160 matches
Mail list logo
