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'
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 situatio
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 divergence
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
algori
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
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 f
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 t
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
> impro
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 Armstr
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 di
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
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, 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 ab
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, wi
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, 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_
http://www.donarmstr
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 w
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.
> >
>
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
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 severi
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
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 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
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 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 i
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 usin
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 probabl
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 De
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 an
"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 su
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 Debia
out 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 are listed in the proposal as a "can", not a
> "should" -- i.e. somethi
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
'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 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.
> >
>
(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 t
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
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 perfec
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, 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 i
(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
> > > > develop
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 s
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 mainta
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
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
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 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, 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
> > (appl
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
> inte
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
* 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 upst
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 se
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 prop
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 cha
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
* 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 i
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 - mai
"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)
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
ight 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..
> >
> > After re-reading the whole thread, I still have several concerns
> > about the idea
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
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 over
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
* 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 look
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·
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, al
"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
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
* 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 y
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
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 ple
g 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
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 wor
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 n
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
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
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 p
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 debiani
"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
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 gon
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 set
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
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
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
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
mod
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
* 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 qu
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
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 forward
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
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
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
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 Deb
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 proposa
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 wh
ws 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 information
between
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
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
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 th
On Sunday 18 May 2008, Ben Finney wrote:
> Please follow 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, 20
1 - 100 of 160 matches
Mail list logo
