Re: divergence from upstream as a bug

[Don Armstrong]

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 need the Fixes: or Patches: complexity at all; it doesn't
solve any problems that need to be solved, and means that a few dozen
tools need to be changed to support it.

> I don't even think we need a new tag; a fix to a bug tagged
> "upstream" can be assumed to be a divergence until the bug is
> finally closed.

Bugs will be closed when they're fixed in Debian. We just won't
archive them until the tag is removed.


Don Armstrong

-- 
Nearly all men can stand adversity, but if you really want to test his
character, give him power.
 -- Abraham Lincoln

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Magnus Holmgren]

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.
>
> Why do we need to track which revisions have divergence?[1]
> Divergences aren't an issue for release managers, nor are they an
> issue for users.
>
> There are only two questions about divergences that the BTS needs to
> answer[2]:
>
>  * I'm upstream. Are there any divergences by Debian that I should
>cherry pick?
>
>  * I'm the maintainer. Are there any divergences which the upstream
>has merged which I can mark as undiverged?
>
> A simple, single tag handles both of these cases. The first is
> answered by selecting packages which have the tag which someone is the
> upstream for. The second by removing the tag when the divergence goes
> away by an upload to unstable (or a commit that will end up in
> unstable soon.)

Right. 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. I don't even think we need a new tag; a fix 
to a bug tagged "upstream" can be assumed to be a divergence until the bug is 
finally closed.

-- 
Magnus Holmgren[EMAIL PROTECTED]
Debian Developer 


signature.asc
Description: This is a digitally signed message part.

Re: divergence from upstream as a bug

[Don Armstrong]

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?[1]
Divergences aren't an issue for release managers, nor are they an
issue for users.

There are only two questions about divergences that the BTS needs to
answer[2]:

 * I'm upstream. Are there any divergences by Debian that I should
   cherry pick?

 * I'm the maintainer. Are there any divergences which the upstream
   has merged which I can mark as undiverged?

A simple, single tag handles both of these cases. The first is
answered by selecting packages which have the tag which someone is the
upstream for. The second by removing the tag when the divergence goes
away by an upload to unstable (or a commit that will end up in
unstable soon.)

If it's desired to know when the divergence has been cherry picked but
an upload has not yet been made, fixed-upstream already handles this.


Don Armstrong

1: In the cases where a divergence introduces a bug, that's a bug in
its own right that should be tracked as we track all bugs.

2: Well, at least two major ones that I can see. If there are more,
someone should raise them so I know to think about them going forward.
-- 
"There's no problem so large it can't be solved by killing the user
off, deleting their files, closing their account and reporting their
REAL earnings to the IRS."
 -- The B.O.F.H..

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Magnus Holmgren]

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 twice, once with the "patched-in" versions and once with 
the "fixed-in" versions as input (the current terminology of the BTS is 
is "Fixed in versions ...", so I'd prefer to call the new state "patched"). 
If a particular version is found to be both patched and fixed, then it is 
considered fixed. 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.

-- 
Magnus Holmgren[EMAIL PROTECTED]
Debian Developer 


signature.asc
Description: This is a digitally signed message part.

Re: divergence from upstream as a bug

[Russ Allbery]

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 that, in an ideal world, would
>> be improved.  Nothing more (or less) than that.

> Like making upstream software use something like sensible-browser?

If it were a configure option, we wouldn't need an upstream divergence and
could just add a configure option in debian/rules.

Any time we're actually patching upstream source, there's going to be some
way that we could avoid that by adding more configuration to upstream.
I'm not sure that's *always* a good idea, but in most cases it would be.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

track bugs in VCS, not the other way around (was: divergence from upstream as a bug)

[martin f krafft]

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 follows from that quite naturally..

I am not even going to try to read this thread, so please excuse if
I repeat what others have said. We should make it policy that the
original proponent of a discussion (Joey here) becomes the chair and
has to keep a summary of the discussion up to date on a wiki. I know
you'll hate me, Joey, but I think it would make sense.

Let me say up front, that I agree with the parallels between bugs
and divergence, since we want to minimise diffs and keep bug counts
low.

However, I think Joey's idea would be a step backwards. Let me
explain.

> The BTS could be enhanced to allow opening a bug and forwarding it
> upstream in a single message. (IIRC currently, it takes two). This would
> allow a very simple workflow where a DD makes a change to a package,
> generates a patch, and sends it upstream while also recording the
> divergence in the BTS.

I love debbugs, dearly! It fits nicely into my workflow, or maybe it
welded my workflow, I don't care -- I like it.

But it's awfully brittle and a giant pile of hack. If we didn't have
Don and the few others who aren't entirely confused by the code
base, we wouldn't have bugs.debian.org anymore.

I cringe every time we make an enhancement to debbugs, pictures of
band aids and superglue come into my mind, and I fear the day when
our (over-)reliance on debbugs is going to hurt us *bad*.

We have a lot of "integration" in place between debbugs and other
parts of the project, like the PTS, debian/changelog parsing, etc
etc etc. They work for the most part, but they're horribly brittle
I find. It seems to me that a lot of information is stored in more
than one place, creating redundancy which will cause problems, or if
not, then at least require massive amounts of extra work to keep it
in sync.

Atomicity does not exist.

What we're trying to do right now is more or less keep track of
patches in Debian packages. Joey proposes to use bug reports for
that. It *does* make some sense, but it's far-fetched. Very
far-fetched. Yes, we want to minimise bug count *and* diversion from
upstream, but does that mean we have to map one onto the other?

Let's assume for a minute that we accept that VCSs are the way
forward and start to consider how we could track bugs in the VCS,
alongside the code.

Start to think about it this way, and stuff suddenly neatly aligns,
at least in my world.

Suddenly you can commit a patch and mark the bug fixed atomically.

Suddenly, bug reports become commits in a branch, and keeping the
branch empty is your goal.

Divergence from upstream is represented in topic branches, and you
want to keep the number of those minimal to not go insane.

You also get all the benefits of a distributed system and if we find
ways to cooperate with other distros via one and the same repository
[0], bugs would be shared, but done right from the start [1].

0. http://vcs-pkg.org
1. http://madduck.net/blog/2008.05.06:how-launchpad-got-it-wrong

I have no details on this yet, but the general idea. Let's not
create more dependence on our aging BTS, please.

And yes, I will try to create a wiki page summarising this subthread
in the next few weeks, if the idea isn't completely unrealistic.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"and if the cloud bursts, thunder in your ear
 you shout and no one seems to hear
 and if the band you're in starts playing different tunes
 i'll see you on the dark side of the moon."
   -- pink floyd, 1972


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: divergence from upstream as a bug

[martin f krafft]

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 whole thing becomes useless because the
divergence isn't recorded in this instance. If a change is not in
0.2 but in 0.3, but 0.2-2 cherry-picked it, well, it's a divergence.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
never underestimate the power of human stupidity.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: divergence from upstream as a bug

[martin f krafft]

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.  Nothing more (or less) than that.

Like making upstream software use something like sensible-browser?

I do see parallels between upstream divergence and bugs and keeping
your bug record down means having to feed upstream, but some changes
are Debian-specific and make the source diverge from upstream, and
yet they are not at all bugs, not even wishlists.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"my father, a good man, told me:
'never lose your ignorance; you cannot replace it.'"
   -- erich maria remarque


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: divergence from upstream as a bug

[Don Armstrong]

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

-- 
Guns Don't Kill People.
*I* Kill People.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

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 just one or displays many is a trivial
> decision once debbugs tracks them all.

ACK. The only non trivial design issue is that it should be possible to
mark some of the patches as denoting the "current patch state", probably
the same you are going to do for the summary (i.e. marking one of the
message in the bug log as "current bug state"). Thanks for this
developments BTW.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Michael Banck]

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) debian/patches.
> 
> They will not except for trivial cases. And in trivial cases you can
> probably seperate patches from on big patch reasonably well too.

I'm not sure what you mean with "trivial cases".  Most patches I've seen
to upstream involve different source files, with the exception of
Makefile{,.in,.am}, maybe.  Even if a change involves several source
files and another the same, it's not a given that the changes necessary
overlap.

So I think it works except for complicated cases.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpjLqif6RjxR.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Don Armstrong]

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 more, I think
> > that having a single summary, with a set of patches and possibly
> > attachments located near the summary is the way to go. I haven't
> 
> 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 just one or displays many is a trivial
decision once debbugs tracks them all.
 
> > This is an unecessary restriction, as not all patches need
> > necessarily be diff files. Making it easy to extract extractable
> > patches should be good enough; those that can't will just have to
> > refer to a message.
> 
> What other kind of patches, beside diffs, are you referring to?
> Stuff like prose explanation on how to fix a problem, binary blobs,
> or what else?

Yes.

> Anyhow, even if you make the distinction between extractable and
> non-extractable patches, I think diff should be extractable, and
> allowing them to be inlined is a PITA. Maybe this can be overcomed
> at an API implementation level, with some logics to recognize
> inlined diffs in messages tagged +patch which are missing
> attachments? It starts looking complicate though ...

I don't want to add in a set of restriction mechanisms to when a tag
can and cannot be placed. Making the automatic extraction work with
extractable patches and attachments and documenting this fact should
be enough to encourage their use without unecessarily restricting
flexibility and making the tagging fragile because of it.


Don Armstrong

-- 
Democracy is more dangerous than fire. Fire can't vote itself immune
to water.
 -- Michael Z. Williamson

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

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 a set of patches and possibly
> attachments located near the summary is the way to go. I haven't

Fair enough, but why are you referring to a _set_ of patches? For the
sake of simplicity assuming that a bug has a single patch sounds like a
fair assumption to me. Of course the patch can patch multiple files and
of course and can be obtained only after a round of repeated
submissions, but in the end: one bug, one patch.  If you agree on this I
think the BTS interface should exploit the principle: at most one
"current" patch, as it will have at most one "current" summary.

> > But still this does not solve another problem we have with patch
> > management in the BTS: they are sometimes inlined, while sometimes
> > the are attached. Can't we fix attachment as the required format for
> This is an unecessary restriction, as not all patches need necessarily
> be diff files. Making it easy to extract extractable patches should be
> good enough; those that can't will just have to refer to a message.

What other kind of patches, beside diffs, are you referring to? Stuff
like prose explanation on how to fix a problem, binary blobs, or what
else?  I tend to believe that diffs are the only things we are usually
interested in pushing upstream, but not knowing the other kind of
patches you have in mind I can't be sure.

Anyhow, even if you make the distinction between extractable and
non-extractable patches, I think diff should be extractable, and
allowing them to be inlined is a PITA.  Maybe this can be overcomed at
an API implementation level, with some logics to recognize inlined diffs
in messages tagged +patch which are missing attachments? It starts
looking complicate though ...

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Don Armstrong]

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 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 a set of patches and possibly
attachments located near the summary is the way to go. I haven't
completely decided how this should be implemented, though.

> But still this does not solve another problem we have with patch
> management in the BTS: they are sometimes inlined, while sometimes
> the are attached. Can't we fix attachment as the required format for
> patches? (e.g. forcing an attachment if one wants to add +patch or
> something similar). This + the forthcoming ability above to identify
> *the* latest patch will give us the ability to automatically extract
> patches from bug reports.

This is an unecessary restriction, as not all patches need necessarily
be diff files. Making it easy to extract extractable patches should be
good enough; those that can't will just have to refer to a message.


Don Armstrong

-- 
 why the hell does kernel-source-2.6.3 depend on xfree86-common?
 It... Doesn't?
 good point

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Don Armstrong]

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.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

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 feature branches are
>> merged. The merging generally needs human interaction somewhere in the
>> history of the integration branch. Doesn't mean every merge needs it
>> though.
>> 
>> Unfortunately there seems to be no way to generate a patch series from
>> that other than one big patch for everything combined. The human
>> interaction stored in the integration branch can't be machine
>> transformed to make a patch series. It seems that that transformation
>> is just as difficult as the merge itself.
>
> The following might work:
>
> 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) debian/patches.

They will not except for trivial cases. And in trivial cases you can
probably seperate patches from on big patch reasonably well too.

Anyway, if you do have such a case you can just claim you have a
stacked branches setup. Such a setup would have some file giving the
order in which branches should be applied and any order would do.

> If they do not apply cleanly, store them individually at
> debian/patch-series or some other directory to be agreed upon, and make
> patches.debian.org be aware of this, i.e. expose them similar to the
> debian/patches patches, but mark them as overlapping/conflicting.

Which might be usefull for upstream but not for anyone working on the
package to fix a bug. As such I don't think that has anything to do in
the source package. For feature branches I would rather have
patches.debian.org fetch the diff from the RCS directly or just link
there.

> Another possibility would be to combine those feature branches which
> conflict which each other, but put the others in seperate patches, still
> using 3.0 (quilt); however, the combined patch of conflicting feature
> branches might be quite meaningless, so not sure about this.

I'm not sure if that is even worth it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 that once again, upstream that would benefit from our system
> > the most are those kind of upstreams, with very large sources, huge user
> > base, huge bugs lists, and massive amounts of patches floating around.
> 
> This does not imply that such upstreams (which I agree are those who
> would benefit most from the improvements being discussed) are using
> systems hard to communicate with.
> 
> I get your word that KDE and glibc are in such a category, but we need a
> bit of numbers before concluding that "large packages" implies "sucky
> BTSs". Do you perhaps have some kind of evidence of this from bts-link?
> (If this is so, it wasn't clear to me from the post I'm replying to.)

  It does not implies such a thing, it's not even a hard rule, though
it's common enough. KDE uses a huge BZ, Gnome does too, mozilla does
too, xorg does too, linux also has a BZ (even if I'm not sure it's the
preferred form of bug reporting, it's quite unclear depending on the
submodule), gcc, binutils and most of the toolchain packages have a BZ
(on sourceware.org), OOo has an issuezilla (which is a BZ in disguise), …

  Of course, vim uses a mailing list, TTBOMK emacs does too.

  You can have a look by yourself, the current list of BTSes bts-link
knows about is here:
http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=btslink.cfg;hb=HEAD
The sole decent BTS here is trac, that allow to report bugs in one form
only, no auth (except HTTP), no intermediate form, no nothing. I've had
to use every of the other ones (except mantis) and none are efficient
for reporting bugs massively like maintainers with thousands of bug
should do.

  Of course, bts-link don't know every BTS out there, bug it's fair to
assume I've been contacted by maintainers that find that dealing with
their upstream's BTS is a PITA (else they wouldn't have bothered sending
me a mail probably).

  Anyways, my point is that we should not really focus on how to "track"
patches, but how to ease reporting bugs/patches upstream, in a unified
_simple_ way. The current discussion is built on sand: Joey's proposal
stands on the assumption that maintainers do open bugs upstream for each
patch they have in their package. That isn't true, and for a good
reason: for many upstreams, this is way too long. Speaking from
experience, when I work on a Debian package, reason says that I should
only spend 30 minutes on it. 45 minutes later I'm still on it, and well,
when the patches I've written have to go to a BZ, I just don't forward
them because I'm already 15 minutes late, and that it's a one minute
story per patch. I just don't have that time for -15 minutes already.
When upstream uses a Mailing list, or anything where I can submit
patches sending a mail, it's merely a git-format-patch | mail, which is
3 seconds away, and I do it. And it's enough because my patches are
commented.

  Is it bad behavior ? Yes, it is. But that's the way it is, and I would
be more than surprised to be an isolate case. Just write a damn tool
that allow forwarding bugs with a unified _optimized_ (ergonomics-wise)
fashion, and tadaaa you'll see that many things will be way simpler, and
that we won't even need joey's proposal at all, or only for very seldom
cases.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpTzZDEf0WNz.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

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 having patch messages nominate
> themselves as the summary message.

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.

But still this does not solve another problem we have with patch
management in the BTS: they are sometimes inlined, while sometimes the
are attached. Can't we fix attachment as the required format for
patches? (e.g. forcing an attachment if one wants to add +patch or
something similar). This + the forthcoming ability above to identify
*the* latest patch will give us the ability to automatically extract
patches from bug reports.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

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, and a column on the left with icons
> indicating the tags and the Debian versions the bug applies to.

#434504 (though the bug subject is a bit misleading). At the end of the
report there are some CSS stylesheets which changes the output to a
trac-like bug listing. Help is needed to finish it up ...

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

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 are those kind of upstreams, with very large sources, huge user
> base, huge bugs lists, and massive amounts of patches floating around.

This does not imply that such upstreams (which I agree are those who
would benefit most from the improvements being discussed) are using
systems hard to communicate with.

I get your word that KDE and glibc are in such a category, but we need a
bit of numbers before concluding that "large packages" implies "sucky
BTSs". Do you perhaps have some kind of evidence of this from bts-link?
(If this is so, it wasn't clear to me from the post I'm replying to.)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Michael Banck]

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 generally needs human interaction somewhere in the
> history of the integration branch. Doesn't mean every merge needs it
> though.
> 
> Unfortunately there seems to be no way to generate a patch series from
> that other than one big patch for everything combined. The human
> interaction stored in the integration branch can't be machine
> transformed to make a patch series. It seems that that transformation
> is just as difficult as the merge itself.

The following might work:

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) debian/patches.

If they do not apply cleanly, store them individually at
debian/patch-series or some other directory to be agreed upon, and make
patches.debian.org be aware of this, i.e. expose them similar to the
debian/patches patches, but mark them as overlapping/conflicting.

Another possibility would be to combine those feature branches which
conflict which each other, but put the others in seperate patches, still
using 3.0 (quilt); however, the combined patch of conflicting feature
branches might be quite meaningless, so not sure about this.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[George Danchev]

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 them learned to search for +++ and ignore debian/.

Well we can still have debian/patches/$diff easily extracted and separated, 
even without orig.tar.gz, since these are purely new files to be created by 
patch: zcat *.diff.gz | patch -p1 (--force for hooligan diff.gz who touch 
outside debian/ when applied, no debian/patches/ obviously)

> However I do agree, extractin that to a web repository would be nice, to
> make it linkable.

Well I guess it is no too much hassle for p.d.o to inspect the diff.gz's and 
publish the results without even unpacking orig.tar.gz in the following way 
(or similar):

Checks:

1) get the debian/patches/ directory ( if any ): 
zcat $diff.gz | patch -p1 --force   
2) perl regex to see if upstream code is touched outside debian/patches/:
while ( <$diff_handler> ) { print $_ if ( /^---\s[^\/]+(?!\/debian)\// ); }
/* could be better ? */

Conclusions:

* run 1) and if debian/patches/ doesn't exists 
* and 2) returns no matches 
=> $SUMMARY - no patches applied by Debian, nothing to publish

* run 1) and if debian/patches/ exists
* run 2) returns no matches
=> $SUMMARY - patched by debian/patches
=> $PATCHES/ - publish them as well

* run 1) and if debian/patches/ doesn't exists
* run 2) returns matches
=> $SUMMARY - not very cool, patched in a combined fashion, good luck 
inspecting diff.gz youself
=> $PATCHES/ - no useful bits to reveal

* run 1) and if debian/patches/ exists 
* and 2) returns matches 
=> $SUMMARY - too bad, patches applied both ways (inside/outside 
combination) - by debian/patches and in a combine fashion, good luck 
inspecting diff.gz youself
=> $PATCHES/ - no useful bits to publish



I'm not certain about url's, but:

p.d.o/$debian_source_package_name/$SUMMARY
p.d.o/$debian_source_package_name/$PATCHES/

would suffice.


-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Raphael Hertzog]

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 Ubuntu's bug tracker, see a
> bug reported there, and fix it in the Debian package.

That's why I integrated the distribution name, so that we can also have
Fix-Ubuntu-Bug for example. And it imposes no structure on the content
for each specific distribution.

But both solution are acceptable provided that you accept multiple "Fixes"
field. But in your case, it's best to allow URL only (for uniformity).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

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 it in the Debian package.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

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 specific patch
> 
> (Fixes: #1234) in changelog.
> 
> > - fixed in upstream
> 
> (Closes: #1234) in changelog
> 
> Or equivalent mails to control. Fixes would do version tracking just
> like closes does.

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.

(Btw, when quoting, you should be careful not to cut atomic entities,
like paragraphs usually, into smaller parts. I usually try to write one
idea per paragraph especially for that.)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Don Armstrong]

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 be done by the addition of an extension
to debcommit (or similar) to automatically add divergence when a
change is made which impacts a bug which involves a change not
(ultimately) inside of debian/; ideally even sending the patch to the
bts and marking it as a summary.[1]

[Or maybe some other command which does the same with a interdiff or
similar.]

Doing differently will require a manual step to actually extract the
patch which is involved in the divergence, and also requires changes
to dak et al.


Don Armstrong

1: Possibly even replacing tagpending...
-- 
In all matters of government, the correct answer is usually: "Do
nothing"
 -- Robert Heinlein _Time Enough For Love_ p428

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

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
> > awaiting a new release upstream to be finally closed. 
> > nnn-fixed is ignored if the upstream tag is not already
> > set. Bugs can be fixed in the changelog of an upload using
> > (Fixes: #1234) in a similar manner to (Closes: #1234). The
> > principle usage of "fixed" is to denote points at which 
> > Debian diverges from upstream. Filenames of patch files must 
> > be clearly identified when using (Fixes: #1234) in the
> > changelog.
> 
> 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 close this bug report when
> upgrading the Debian package to an upstream source in which the patch
> has been merged or obsoleted".

Take a bug #111, severity:serious, affecting unstable,testing,stable.
The maintainer fixes the bug in unstable using a Debian patch. Following
your process, the bug is now downgraded to wishlist. Meaning that RC
#111 bug in stable suddenly became a wishlist bug. We don't want that!

Could someone summarize again the different features that we require for
the "BTS tracks patches sent upstream" thing? I can think of:
- the new features must not change the existing workflow, when not using
  the BTS to track upstream patches.
- the submitter should still know when the bug is fixed in Debian (=
  when he can upgrade the package and expect it to work as supposed)
- the maintainer and upstream need a way to list the patches that
  were submitted upstream but not integrated yet.
- the process must not break the tracking of bugs in other suites
Anything else?

The current solution proposed by Don is:
  add a divergence tags that can be used to mark bugs about patches sent
  upstream ; don't archive closed bugs tagged divergence.

This is good, because it avoids duplicating all the version-tracking for
a "fixed-with-a-patch" state that will only be useful for a few
packages. Those who don't need the feature won't see it.

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.
2) slightly change behaviour of Closes:. do as usual, and if the bug
   is tagged divergence, remove the tag.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Raphael Hertzog]

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 close this bug report when
> upgrading the Debian package to an upstream source in which the patch
> has been merged or obsoleted".

I don't really like the idea to have "Fixes:" and "Closes:" do different
things. It basically means the same thing and would lead to
very different results. That's not something that I'd like to implement in
dpkg-dev (with my dpkg maintainer hat).

I would suggest as alternative, that this information should be stored in
the fields preceding the patch. And dpkg-genchanges/dak shouldn't process
anything with respect to that.

However the tool that grabs the patch and publish it in patches.debian.org
should certainly tag the bug number with divergence. (And since that tool
could use real patches coming from 3.0 (quilt) packages or generated
patches coming from any other VCS-based source packages, everybody would
be happy)

Fix-Debian-Bug: 5
Forwarded-Upstream: http://bugzilla...
Author: Random Joe <[EMAIL PROTECTED]>
Comment: 
 The behaviour A was wrong when B. This patch makes sure to do C in that
 case as this is what the user expects.

[patch follows]

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

"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 patchset
> constructed from non-quilt based work models, especially with things
> centered on history. For example something to tag commits to git
> repository, so some package creating tool can put changes belonging
> together (like a modification and its updates for newer upstreams)
> into a single .diff of such a series. (be that meta-tags in the
> description, automatic utilisation of feature branches, extending the
> git format or whatever git experts can think of or consider worthwile)
> (or perhaps I'm just too stupid to find branch-hopping and manual
> merging manually convenient enough to actually do).

There are 2 distinctly different workflows:

1) stacked patches or branches

You base each patch or branch on the source with the previous patch
applied or branch merged in already. Then you have a nice linear
progression of changes that can be put into /debin/patches/.

If you want to use a RCS I suggest using stacked git or the mercurial
extension instead of actual branches.

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 generally needs human interaction somewhere in the
history of the integration branch. Doesn't mean every merge needs it
though.

Unfortunately there seems to be no way to generate a patch series from
that other than one big patch for everything combined. The human
interaction stored in the integration branch can't be machine
transformed to make a patch series. It seems that that transformation
is just as difficult as the merge itself.


I think the divergence bugs would be most usefull there. The diff.gz
would not contain usefull patches as all features are mangled into one
patch there. But it would be easy to generate a patch for each feature
branch and send it to the BTS.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

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
> it's 100% clear, why should I even create a bug on the BTS about it?
> There's no point in discussing something that doesn't need discussion.

Because it is a divergence. Documenting only divergences upstream will
accept would be short sighted.

>> I agree with you that the bug description should be a summary. The BTS
>> would be the history of the patch. The how and why it became. If that
>> info is in upstreams BTS then you would just link that.
>> 
>> > 2) It makes the BTS another place to look at for upstreams or other
>> > distros interested in our patches.
>> 
>> What other place is there currently besides extracting the source and
>> checking that?
>
> The source package's debian/patches dir, which will still be the
> canonical place to get the up-to-date patch?

That assumes everyone uses debian/patches. Would be nice but that is
not reality.

>> > 4) The bureaucracy/usefulness ratio looks very high to me. After all,
>> > we spent 15 years not doing that, and it seems to me that many patches
>> > are small and don't require any discussion, so the overhead would be
>> > huge. Maybe we could try a simpler solution first?
>> 
>> "bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
>> the BTS. Not mutch work.
>
> That's not enough. It doesn't extract the relevant patch automatically

That was said to be optional. Once you know that there is a patch you
can always download the source and get it or patches.d.o could have it.

> 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 specific patch

(Fixes: #1234) in changelog.

> - fixed in upstream

(Closes: #1234) in changelog

Or equivalent mails to control. Fixes would do version tracking just
like closes does.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

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" 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. something that would be a natural part of the
> workflow, but not a necessary part of the proposal.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[George Danchev]

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 1/[EMAIL PROTECTED] 2/dist-3.70.orig | diffstat
> |  0 files changed
>
> Your point being?

Ops, sorry for the false positive -- my memory served me bad, I should have 
checked that first.

Another reason I thought of for seeing such defferences might be a silent 
subsequent change of the tarball at the upstream site (md5,sha1 sums 
including).

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Charles Plessy]

'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 closed. 
>   nnn-fixed is ignored if the upstream tag is not already
>   set. Bugs can be fixed in the changelog of an upload using
>   (Fixes: #1234) in a similar manner to (Closes: #1234). The
>   principle usage of "fixed" is to denote points at which 
>   Debian diverges from upstream. Filenames of patch files must 
>   be clearly identified when using (Fixes: #1234) in the
>   changelog.

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 close this bug report when
upgrading the Debian package to an upstream source in which the patch
has been merged or obsoleted".

This does not offer all the functionalities one could dream of, but it
may be the easiest start, especially that it can be performed by hand.
(Which I am considering doing for the packages I maintain).

> With suitable changes in debchange, we could have:
> 
> $ dch -a --fixes 1234 "Add 090_missing_stdlib_h.patch"
> ... time passes, new upstream release made...
> $ dch -a --closes 1234
> 
> Simple.

I like it :)

Have nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

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 that sentiment by offering just to not archive bugs tagged
> > with 'divergence'. I would agree that the submitter doesn't really need
> > to know when Fixed: is replaced by Closes: - it is a maintainer issue
> > but one that does need to be publicly visible.
> 
> OK, but then you have to remove the divergence tag when the change is
> integrated upstream -- not just close the bug. This would be still be a
> manual process, right?

I suppose bts-link could be utilised - after all, the bug tagged
'divergence' should also be forwarded so it can be updated from there.
However, it might be just as well that it is manual. As I mentioned
before, removing a tag can be done by anyone so it's not a big issue.

> Users can choose whichever bug tracker they prefer, but DDs should
> always report patches that should be reported upstream to the upstream
> BTS. It would be nonsense if DDs started reporting patches for upstream
> only to the Debian BTS.

ok.

> OK, I think that we generally agree. Let's summarize again to make sure:
> 
> 1) Encourage maintainers to use patches in debian/patches. Define some
> useful pseudo-headers.

Definitely.

> 2) Build patches.debian.org, fully automated export of Debian patches.

Yes.

> 3) For patches that need to be sent upstream, a pseudo header in the
> patch indicates where the submission of the patch to upstream is
> discussed.
> -> If upstream has a BTS, the discussion happens on upstream's
>BTS, and the pseudo header in the patch points there.
> -> If upstream doesn't have a BTS, a bug is created/reused on the Debian
>BTS, and the discussion with upstream is Cced with this bug. The
>pseudo header in the patch points to that Debian BTS bug.
>Additionally, this bug is tagged +divergence to indicate what it's
>about.
>Also, bugs tagged divergence are not archived. So even after the bug
>has been closed in Debian, the bug can continue to be used to discuss
>the patch with upstream.
> 
> Sounds good?

Yes, it does.

It could also be possible to add some automation because as the
pseudo-header is in the patch, scripts could check that the list of
pseudo-headers with a bugs.d.o URL matches the list of diversion bugs
obtained via SOAP. Lintian doesn't currently do SOAP queries of the BTS
but a QA script should be relatively easy to create. Maybe bts-link
could be drafted in to provide some leverage over pseudo-headers mapping
to an upstream bug tracker.

Lintian could check that the pseudo-header exists.

-- 
Neil Williams <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

(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 bug has been fixed using a divergence
> > > whilst still waiting for upstream.
> > 
> > OK, but is that really a problem? Currently, the submitter will receive
> > the close message, can read the changelog, and see if his bug was closed
> > in a new upstream release, or by a Debian-specific change.
> 
> My point is that the bug submitter should get notification as soon as
> the package is fixed in Debian. It is the maintainer who needs to know
> about matters after that. It doesn't matter what the submitter receives
> as long as it is sent asap. Just using 'divergence' without closing the
> Debian side of the bug would leave the bug open but with different tags.
> 
> Don's idea of simply not archiving such bugs (and therefore using
> Closes: at the first opportunity) isn't quite what I was thinking but it
> would work. Just might not be as easy to scan for those bugs in the bts
> webpages.
> 
> >  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 that sentiment by offering just to not archive bugs tagged
> with 'divergence'. I would agree that the submitter doesn't really need
> to know when Fixed: is replaced by Closes: - it is a maintainer issue
> but one that does need to be publicly visible.

OK, but then you have to remove the divergence tag when the change is
integrated upstream -- not just close the bug. This would be still be a
manual process, right?

> > > OK, so problem 1:
> > > Q: How to improve Debian forwarding patches to upstream using upstream
> > > bug trackers?
> > > A: Leave the burden on the DD to handle multiple logins to multiple bug
> > > trackers but make life easier in the BTS so that everyone can read the
> > > patch without needing a login. This, IMHO, is met by the Fixed|Closed
> > > two stage closure idea.
> > 
> > Can you point to some upstream BTS that require you to login to read
> > patches? I was under the impression that most BTS give you read access
> > without login.
> 
> The DD doesn't just need to read patches, he needs to login and post new
> patches and new comments, but yes, I got that bit confused. What I meant
> was upstreams where the "bug tracker" is actually private email or
> similar. (Some do only offer the login window and tuck a little
> "anonymous" box in the top corner.)

When upstream has no good way to track patches, I'm perfectly fine with
the Debian maintainer choosing that the right way to track patches
submitted upstream is to open bugs in the Debian BTS for each of those
patches.  That's a sensible thing to do. What I strongly oppose is
asking all maintainers to do this, even when upstream has a good way to
track patches/bugs.

> I should have stuck with the original paragraph:
> 
> > I want Debian to go to upstream (as now) and let DD's suffer the hassle
> > of divergent upstream bug trackers so as to not force that workload on
> > our users or members of different upstream teams trying to work out why
> > their code is suffering from a buggy -dev package. If appropriate, feed
> > that info into the BTS.
> Message-Id: <[EMAIL PROTECTED]>
> 
> > I fear that this will turn into DDs thinking that it's enough to file a
> > bug in the BTS to consider a bug as "forwarded upstream".  While it's
> > obviously not the case.
> 
> I'm not sure how that follows but I don't want that either. (I suggested
> that Fixed would only work if Forwarded was set.)

If you enforce the "file a bug in the Debian BTS for each patch you want
to see integrated upstream", it might end up sounding like "filing bugs
in the Debian BTS is sufficient". A bit like the "if it's lintian-clean,
then it's clean" problem.

> > If my upstream BTS doesn't require login to read the bug, are there
> > other reasons (beside the "submitter want to be notified when the patch
> > is applied upstream" one -- see question above) for duplicating the bug
> > discussion into the BTS?
> 
> Similar reason to why you added that CC - because when dealing with a
> variety of inputs, it is helpful to get an overview of the changes
> across all packages. I'm not sure where you see duplication:
> 
> > Use tags in the BTS and custom webpages to let others know which bugs we
> > fixed with these patches. If the upstream tracker isn't public, file the
> > patches in the BTS too so that everyone can find it. 

If the discussion happens publicly both in upstream's BTS and in
Debian's BTS, then there's a clear duplication problem (dropped Ccs,
lost mails, etc). If the discussion happens via private emails with
upstream, Cced with the Debian BTS, then it's fine.

> and
> 
> > Users can choose wh

Re: Tracking divergence from upstream as a bug

[Neil Williams]

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 this by just not archiving bugs tagged
> divergence; when it's fixed upstream, you just untag it.
> 
> No need for complicated mucking about with the changelog parsers.

Hmmm, ok. Should be straightforward to create QA pages/scripts that can
check on bugs that might get missed.

Untagging is also something that can be done by anyone so it has the
advantage that more people can pick up such errors and fix them.

I've already started talking myself into circles (see my reply to Lucas)
so I think I'll quit while I'm ahead and go for that solution.
:-)


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

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 sometimes don't forward
> > >   simple patches
> > > - they want to know which patches are actually used (and widely tested),
> > >   because that make them better candidates for integration upstream
> > 
> > > But maybe I'm just misunderstanding upstreams' needs?
> > 
> > There's no accounting for the variety in upstream teams - I don't know
> > many that want the second option but I can see that some will probably
> > want it that way, if only because of an MIA DD.
> 
> Well, Vincent Untz (GNOME release manager) explicitely said that he
> needed that in [1] and [2]. But it's true that more input from other
> upstreams would be interesting.
> [1] http://lists.debian.org/debian-devel/2008/05/msg00496.html
> [2] http://lists.debian.org/debian-devel/2008/05/msg00509.html

I guess it's because that is an over-arching upstream and has to deal
with a variety of GNOME teams and Debian DD's. 

It's kind-of how I expect to use divergence for GPE packages and
possibly Emdebian (treating Debian as our upstream).

> But my main motivation for providing something like patches.d.o is that,
> after the openssl debacle, many people have the impression that we are
> patching a lot of useless stuff, and that we don't know what we are
> doing. A good answer to that would be to expose all our patches in
> something like patches.d.o. (sort of "we don't hide our problems"
> applied to packages)
> 
> Also, it's really cheap to do: it can be fully automated.

If you're sure that all that online disc space really is cheap, it's
fine by me. Maybe working with embedded devices has obscured the real
cost of online space but I can't help but complain about every extra Mb.
:-)
 
> > 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 bug has been fixed using a divergence
> > whilst still waiting for upstream.
> 
> OK, but is that really a problem? Currently, the submitter will receive
> the close message, can read the changelog, and see if his bug was closed
> in a new upstream release, or by a Debian-specific change.

My point is that the bug submitter should get notification as soon as
the package is fixed in Debian. It is the maintainer who needs to know
about matters after that. It doesn't matter what the submitter receives
as long as it is sent asap. Just using 'divergence' without closing the
Debian side of the bug would leave the bug open but with different tags.

Don's idea of simply not archiving such bugs (and therefore using
Closes: at the first opportunity) isn't quite what I was thinking but it
would work. Just might not be as easy to scan for those bugs in the bts
webpages.

>  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 that sentiment by offering just to not archive bugs tagged
with 'divergence'. I would agree that the submitter doesn't really need
to know when Fixed: is replaced by Closes: - it is a maintainer issue
but one that does need to be publicly visible.
 
> > OK, so problem 1:
> > Q: How to improve Debian forwarding patches to upstream using upstream
> > bug trackers?
> > A: Leave the burden on the DD to handle multiple logins to multiple bug
> > trackers but make life easier in the BTS so that everyone can read the
> > patch without needing a login. This, IMHO, is met by the Fixed|Closed
> > two stage closure idea.
> 
> Can you point to some upstream BTS that require you to login to read
> patches? I was under the impression that most BTS give you read access
> without login.

The DD doesn't just need to read patches, he needs to login and post new
patches and new comments, but yes, I got that bit confused. What I meant
was upstreams where the "bug tracker" is actually private email or
similar. (Some do only offer the login window and tuck a little
"anonymous" box in the top corner.)

I should have stuck with the original paragraph:

> I want Debian to go to upstream (as now) and let DD's suffer the hassle
> of divergent upstream bug trackers so as to not force that workload on
> our users or members of different upstream teams trying to work out why
> their code is suffering from a buggy -dev package. If appropriate, feed
> that info into the BTS.
Message-Id: <[EMAIL PROTECTED]>

> I fear that this will turn into DDs thinking that it's enough to file a
> bug in the BTS to consider a bug as "forwarded upstream".  While it's
> obviously not the case.

I'm not sure how that follows but I don't want that either. (I suggested
that Fixed would only work if Forwarded was set.

Re: Tracking divergence from upstream as a bug

[Don Armstrong]

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 fixed upstream, you just untag it.

No need for complicated mucking about with the changelog parsers.


Don Armstrong

-- 
There is no such thing as "social gambling." Either you are there to
cut the other bloke's heart out and eat it--or you're a sucker. If you
don't like this choice--don't gamble.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 it supported. RT isn't. Launchpad should be
> 
> Uh, rt.cpan.org seems to work fine with bts-link, and it's already in
> btslink.cfg :)
> 
>  
> http://git.debian.org/?p=bts-link/bts-link.git;a=blob_plain;f=btslink.cfg;hb=HEAD

  Yeah I didn't remember about it, and it's probably because it's code
that is 2 yo, and that I didn't write myself to begin with :)

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpC976niOmHq.pgp
Description: PGP signature

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

(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 (upstream, other distros, users) to know which patches we
> > > >   applied, the reason for the patch, and whether they should be
> > > >   interested in that patch or not.
> > > 
> > > In that case, the fault lies in Debian for not using Forwarded properly.
> > > IMHO we should be going out of our way to communicate with upstream
> > > using the systems preferred BY upstream, not trying to devise a new one.
> > > 
> > > I know it's a PITA using bugzilla and a gazillion different logins but
> > > that is part of the workload.
> > 
> > I think that upstreams would like two different things:
> > - that distros forward patches to their BTS
> > - that distros provide an automated, simple way to see what they patched
> 
> ok - so two problems, not one.

Yes.

> > That sounds logical to have both:
> > - they know that distro devs are not perfect and sometimes don't forward
> >   simple patches
> > - they want to know which patches are actually used (and widely tested),
> >   because that make them better candidates for integration upstream
> 
> > But maybe I'm just misunderstanding upstreams' needs?
> 
> There's no accounting for the variety in upstream teams - I don't know
> many that want the second option but I can see that some will probably
> want it that way, if only because of an MIA DD.

Well, Vincent Untz (GNOME release manager) explicitely said that he
needed that in [1] and [2]. But it's true that more input from other
upstreams would be interesting.
[1] http://lists.debian.org/debian-devel/2008/05/msg00496.html
[2] http://lists.debian.org/debian-devel/2008/05/msg00509.html

But my main motivation for providing something like patches.d.o is that,
after the openssl debacle, many people have the impression that we are
patching a lot of useless stuff, and that we don't know what we are
doing. A good answer to that would be to expose all our patches in
something like patches.d.o. (sort of "we don't hide our problems"
applied to packages)

Also, it's really cheap to do: it can be fully automated.

> > > > I thought that the problem of tracking changes for Debian developers was
> > > > already solved by using a VCS and advertising it thought Vcs-*?
> > > 
> > > No, it isn't because Debian developers still need to track where Debian
> > > patches have diverged from upstream due to delays in upstream
> > > development. Vcs does nothing for that, nothing whatsoever (and I
> > > consider it a nonsense to include the entire upstream codebase in our
> > > RCS).
> > 
> > If we have a Formarded-upstream: field in patches.d.o (pointing to the
> > upstream bug for a patch), it would be easy to modify bts-link and
> > automatically monitor those upstream bugs.
> 
> 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 bug has been fixed using a divergence
> whilst still waiting for upstream.

OK, but is that really a problem? Currently, the submitter will receive
the close message, can read the changelog, and see if his bug was closed
in a new upstream release, or by a Debian-specific change. 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.

Do we really want to "solve" that? Have submitters been asking for that?

> > Yes. One problem with this discussion is that we are discussing:
> >What can/can't we do by using, abusing and modifying our current
> >infrastructure (i.e the BTS)?
> > Instead of discussing:
> >What is the real problem that we are trying to solve? What needs
> >to be done to fix that problem? (what features/requirements are
> >needed in a candidate solution?)
> > The discussion is polluted by technical details about BTS things, and
> > this hides the real issues.
> 
> OK, so problem 1:
> Q: How to improve Debian forwarding patches to upstream using upstream
> bug trackers?
> A: Leave the burden on the DD to handle multiple logins to multiple bug
> trackers but make life easier in the BTS so that everyone can read the
> patch without needing a login. This, IMHO, is met by the Fixed|Closed
> two stage closure idea.

Can you point to some upstream BTS that require you to login to read
patches? I was under the impression that most BTS give you read access
without login.

I fear that this will turn into DDs thinking that it's enough to file a
bug in the BTS to consider a bug as "forwarded upstream".  While it's
obviously not the case.

If my upstream BTS doesn't require login to read the bug, are there
other reasons (beside the "submitter want to be notified when the patch
is

Re: divergence from upstream as a bug

[Niko Tyni]

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 seems to work fine with bts-link, and it's already in
btslink.cfg :)

 
http://git.debian.org/?p=bts-link/bts-link.git;a=blob_plain;f=btslink.cfg;hb=HEAD
-- 
Niko Tyni   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Michael Banck]

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 maintainers to easily look
at or (more importantly) for other distribution packagers to look at.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Bastian Blank]

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 now I saw that Don Armstrong also asked such a 
> question, but I forgot to reply to him while having a lunch yesterday. While 
> digging in debian source packages I have seen several such in the past, but I 
> only remember dist now -- compare:
> http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
> http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz

| $ wget http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
| [...]
| $ wget http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz
| [...]
| $ 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 1/[EMAIL PROTECTED] 2/dist-3.70.orig | diffstat
|  0 files changed

Your point being?

Bastian

-- 
What kind of love is that?  Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, "Metamorphosis",
   stardate 3219.8


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

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 they should be
> > >   interested in that patch or not.
> > 
> > In that case, the fault lies in Debian for not using Forwarded properly.
> > IMHO we should be going out of our way to communicate with upstream
> > using the systems preferred BY upstream, not trying to devise a new one.
> > 
> > I know it's a PITA using bugzilla and a gazillion different logins but
> > that is part of the workload.
> 
> I think that upstreams would like two different things:
> - that distros forward patches to their BTS
> - that distros provide an automated, simple way to see what they patched

ok - so two problems, not one.

> That sounds logical to have both:
> - they know that distro devs are not perfect and sometimes don't forward
>   simple patches
> - they want to know which patches are actually used (and widely tested),
>   because that make them better candidates for integration upstream

> But maybe I'm just misunderstanding upstreams' needs?

There's no accounting for the variety in upstream teams - I don't know
many that want the second option but I can see that some will probably
want it that way, if only because of an MIA DD.

> > > I thought that the problem of tracking changes for Debian developers was
> > > already solved by using a VCS and advertising it thought Vcs-*?
> > 
> > No, it isn't because Debian developers still need to track where Debian
> > patches have diverged from upstream due to delays in upstream
> > development. Vcs does nothing for that, nothing whatsoever (and I
> > consider it a nonsense to include the entire upstream codebase in our
> > RCS).
> 
> If we have a Formarded-upstream: field in patches.d.o (pointing to the
> upstream bug for a patch), it would be easy to modify bts-link and
> automatically monitor those upstream bugs.

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 bug has been fixed using a divergence
whilst still waiting for upstream.

> Yes. One problem with this discussion is that we are discussing:
>What can/can't we do by using, abusing and modifying our current
>infrastructure (i.e the BTS)?
> Instead of discussing:
>What is the real problem that we are trying to solve? What needs
>to be done to fix that problem? (what features/requirements are
>needed in a candidate solution?)
> The discussion is polluted by technical details about BTS things, and
> this hides the real issues.

OK, so problem 1:
Q: How to improve Debian forwarding patches to upstream using upstream
bug trackers?
A: Leave the burden on the DD to handle multiple logins to multiple bug
trackers but make life easier in the BTS so that everyone can read the
patch without needing a login. This, IMHO, is met by the Fixed|Closed
two stage closure idea.

Problem 2:
Q: How to help upstream find out from Debian which patches are actually
in use.
A: provide browsable patch files organised by source package (the
upstream source package name if it differs) - this sounds like the
patches.d.o idea.

I'll stick to Problem 1. :-)

I think you're right that there are two distinct problems - although I'm
still not convinced that Problem 2 is sufficiently common to require a
whole new bug/patch tracker.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: divergence from upstream as a bug

[George Danchev]

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, but I forgot to reply to him while having a lunch yesterday. While 
digging in debian source packages I have seen several such in the past, but I 
only remember dist now -- compare:
http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz

the rest might already been fixed now... And no, I didn't file a bugs against 
these, since I wanted to avoid an useless teaching of how to access the DD 
VCS, which I hate most.

> > And when extending the source packaging format, do not throw away the
> > good properties lightly. Git for example is no format to present
> > modifications. It is one to present history (which is almost but not
> > quite something completely different).

True.

> Git is quite good at presenting modifications if you know how to use it.

...and also true.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

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
> > > > upstreams.
> > > 
> > > Oh?  When I read the proposal, I understood that the problem we want to
> > > solve is about tracking changes we make to upstream.
> > 
> > Ah, interesting. We are not trying to solve the same problem, which
> > might explain why it's so hard to converge to a single solution.
> > 
> > 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 in that patch or not.
> 
> In that case, the fault lies in Debian for not using Forwarded properly.
> IMHO we should be going out of our way to communicate with upstream
> using the systems preferred BY upstream, not trying to devise a new one.
> 
> I know it's a PITA using bugzilla and a gazillion different logins but
> that is part of the workload.

I think that upstreams would like two different things:
- that distros forward patches to their BTS
- that distros provide an automated, simple way to see what they patched

That sounds logical to have both:
- they know that distro devs are not perfect and sometimes don't forward
  simple patches
- they want to know which patches are actually used (and widely tested),
  because that make them better candidates for integration upstream

But maybe I'm just misunderstanding upstreams' needs?

> > I thought that the problem of tracking changes for Debian developers was
> > already solved by using a VCS and advertising it thought Vcs-*?
> 
> No, it isn't because Debian developers still need to track where Debian
> patches have diverged from upstream due to delays in upstream
> development. Vcs does nothing for that, nothing whatsoever (and I
> consider it a nonsense to include the entire upstream codebase in our
> RCS).

If we have a Formarded-upstream: field in patches.d.o (pointing to the
upstream bug for a patch), it would be easy to modify bts-link and
automatically monitor those upstream bugs.

> Going back to the original message:
> http://lists.debian.org/debian-devel/2008/05/msg00536.html
> 
> "The BTS could be enhanced to allow opening a bug and forwarding it
> upstream in a single message. (IIRC currently, it takes two). This would
> allow a very simple workflow where a DD makes a change to a package,
> generates a patch, and sends it upstream while also recording the
> divergence in the BTS."

Yes. One problem with this discussion is that we are discussing:
   What can/can't we do by using, abusing and modifying our current
   infrastructure (i.e the BTS)?
Instead of discussing:
   What is the real problem that we are trying to solve? What needs
   to be done to fix that problem? (what features/requirements are
   needed in a candidate solution?)
The discussion is polluted by technical details about BTS things, and
this hides the real issues.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[George Danchev]

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
> > (applied/unapplied/blamed/whatever). Such a service to can only be a
> > companion one, but not a reliable source of what has actually
> > changed, so consider it 'yet another place to DIG at'.
>
> Whether the patch is in the bug report or not, I don't see how that
> affects the proposal.
>
> > 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 re-read the original proposal that starts this
> thread, and I can't see where everyone is reading "bureaucracy" and
> "extra workload" and "patches floating in the BTS" and "forcing
> upstream to read new BTS tags and features".

Although not mentioned in the first place these are all unavoidable 
consequences you will face at some point.

> The proposal, at its core, is merely about how to *classify*
> divergence from upstream source in a Debian package. There's nothing
> in the original message that requires patches to be duplicated, or
> upstream to get patches in a different way, or any of the other
> spectres people are raising here.
>
> It *suggests* that, with such a classification, certain workflows
> would be enabled naturally; but it doesn't *insist* on any of them.
>
> There's merely the proposal that we start *tracking* the divergence as
> a bug that needs resolution, like any other bug report in the BTS.

Such a classification may exists, but it is not a reliable source of code 
changes and their states which are actually deployed and are being in use.

> Am I wrong?

Well, not wrong, but you ask for too much load for almost no gain in solving 
the problem of exposure of debian changes for easy public peer review.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Miriam Ruiz]

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 in that patch or not.

I agree there too. That's the problem I'm interested in solving too,
and I think that the proposed solution of having some pseudoheaders
added to the patches and an automated system to fetch those patches
and publish them automatically would be the best solution. This would
allow an easy inspection, not only from upstream, but also from people
from other distros, third parties and Debian collaborators.

Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

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 that the problem we want to
> > solve is about tracking changes we make to upstream.
> 
> Ah, interesting. We are not trying to solve the same problem, which
> might explain why it's so hard to converge to a single solution.
> 
> 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 in that patch or not.

In that case, the fault lies in Debian for not using Forwarded properly.
IMHO we should be going out of our way to communicate with upstream
using the systems preferred BY upstream, not trying to devise a new one.

I know it's a PITA using bugzilla and a gazillion different logins but
that is part of the workload.

> I thought that the problem of tracking changes for Debian developers was
> already solved by using a VCS and advertising it thought Vcs-*?

No, it isn't because Debian developers still need to track where Debian
patches have diverged from upstream due to delays in upstream
development. Vcs does nothing for that, nothing whatsoever (and I
consider it a nonsense to include the entire upstream codebase in our
RCS).

Going back to the original message:
http://lists.debian.org/debian-devel/2008/05/msg00536.html

"The BTS could be enhanced to allow opening a bug and forwarding it
upstream in a single message. (IIRC currently, it takes two). This would
allow a very simple workflow where a DD makes a change to a package,
generates a patch, and sends it upstream while also recording the
divergence in the BTS."

To me, that reads as:
Use the upstream trackers to let upstream people know which patches we
applied and why. Use the BTS to track the Debian side of the divergence.

(Every divergence has two sides, otherwise there would be no difference
between Debian and upstream.)

I'd like to see that extended to include:
Use tags in the BTS and custom webpages to let others know which bugs we
fixed with these patches. If the upstream tracker isn't public, file the
patches in the BTS too so that everyone can find it. 

Then, when an upstream release finally includes the effect of the patch,
remove the patch from Debian and change Fixes: to Closes:.

What this proposal is about is identifying where Debian has diverged
from upstream so that it is easier for Debian to get back into sync with
upstream, not for upstream to get into sync with Debian. (Subtle
difference).

You appear to want upstream to come to us and for us to provide
one-tracker-to-rule-them-all to suit the needs of every upstream team
with a Debian package. That isn't going to happen.

I want Debian to go to upstream (as now) and let DD's suffer the hassle
of divergent upstream bug trackers so as to not force that workload on
our users or members of different upstream teams trying to work out why
their code is suffering from a buggy -dev package. If appropriate, feed
that info into the BTS.

Users can choose whichever bug tracker they prefer - the Debian BTS or
the upstream bug tracker for the project concerned. It is up to Debian
to ensure that proper use of Forwarded ensures that the same information
is available via (but not necessarily in) both. i.e. whichever entry
route is chosen, links are available to go to the relevant point where
the information is publicly available (without logins). Whether that
particular point is in the upstream bug tracker or the BTS is
inconsequential. The essential point is that it does exist and it is
linked from both entry points.

Upstream have chosen their bug tracker and whether we like it or not,
they are unlikely to migrate to one that Debian devises. That way lies
Launchpad. Yuck. As an upstream myself, I simply refuse to use that
horror. There again, I would also refuse to use the RH or Fedora bug
trackers or the OSX bug trackers or Fink or BSD or who knows what else.
As upstream, I've settled on the bug tracker I want to use upstream (and
in some cases it is the BTS) and I'm not going to go trawling round the
distros myself. I want the distros to come to me - as the BTS currently
does via Forwarded and the Fedora people do via their methods. I've
clearly documented the preferred bug tracker for each project on the
relevant website for that project.

The BTS cannot be all things to all people and I fail to see that Vcs
solves anything with regard to divergence (it only provides history, not
divergence).

With or without a README.source, Vcs does nothing to help me track which
patches that I have applied in Debian are actually diverging from
upstream and which have been applied. To find that o

Re: divergence from upstream as a bug

[Bernhard R. Link]

* 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 forgotten or
> > vanished and reappeared. Not just other upstreams of forks. But also our
> > users to see at once what is changed.
> 
> Yup, and that's exactly the point of the discussion.  Joey's proposal
> about using the BTS is one set of tools that would generate such a web
> site, using the web site generation and tracking logic already present in
> the BTS to keep it maintained.  There are other possible ways of
> implementing such a web site, of course.

My point was especially as having an interface to those files. Writing
automatic things to feed those in the BTS will surely be more work than
having a page just parsing those file directly.
Having the maintainer put things there means more work on the maintainer
to spread stuff to more places. This punishes maintainers doing a good
work (updating a description or refreshing a patch needs multiple
actions) and creates a danger of things getting out of sync.

> Well, yes, obviously.  But I almost never see this outside of discussions
> like this where it's used as an example of what not to do.  In practice,
> nearly all code is under-commented and these sorts of problems are rare.

Useable code is almot always under-commented. When you force or educate
people to write comments, you regulary get comments worse than no
comments. It's just efford wasted in the wrong direction.

> Most code that's lived in the wild for a while will develop workarounds
> and obscure fixes to problems that were not at all obvious when it was
> originally written.  The details of those workarounds and fixes *need* to
> be written down, and as much as we might wish otherwise, there is no
> programming language in existence that makes such problems so clear that
> it can usually replace comments.

As I said, comments are best when there are little. Not comments are
best when there are none.

> The general rule of thumb used in many parts of GCC is that if you had to
> fix a bug in a piece of code, you probably should at least consider adding
> a comment making it clear why the code needs to be written the new way,
> since it's apparently not as obvious as you think (or the previous coder
> wouldn't have gotten it wrong).  That's correct more often than not in my
> experience.

And I totaly agree. But it has nothing to with my point.

> What does this have to do with your point?  As you say, that's not a
> modified version.  I think it's messy too, but it's not like we're putting
> Debian-specific modifications into the upstream *.orig.tar.gz (which as
> far as I'm concerned would be a fairly serious bug).

Well, the only thing suggesting this that strictly is devref.

> > And packages having a .tar.gz containing the real tar files and
> > sometimes even patches may be seldom and declining but to be stumbled
> > over regulary.
>
> Oh, this is still quite common, but I don't think that's an example of
> your point.  I think it's an awkward way of laying out the package, but
> usually the people who do this are even *more* careful about using
> pristine upstream tarballs -- that's exactly why they use this layout,
> which can do things like handle multiple upstream tarballs.  The tradeoff
> is that you have to unpack the *.orig.tar.gz to get the upstream tarball,
> but it is there.

You have to download the tarball, then find out where the patches are,
and how they are stored in there, and then how they are applied.
It adds quite a bit of complexity to answering the question "what
exectly is modified here".

> This isn't what I'm talking about.  Git is quite good at presenting
> *modifications* if you know how to use it.  Diffing topic branches is as
> easy and as reliable as looking at patches in debian/patches, and provides
> better tools for manipulating the results.  gitk shows a much better
> picture of the relationship between branches than one can get from a quilt
> series file, once you know what you're looking at.
>
> The drawback is that you have to know how to use Git.  I agree that this
> is a drawback and that expecting all upstreams to know how to use Git
> isn't reasonable.

I think to actually get this to work, and to get it to work in
non-trivial examples, you need quite a deep understanding of git.
At least I don't think that things like making one feature branch
depending on another after those already exist for some time sounds
that easy...

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mailing lsit code of conduct, again (was: divergence from upstream as a bug)

[Vincent Bernat]

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 to the list.

Hi Ben!

Another solution  on your  side is to  use Mail-Followup-To.  With gnus,
this is  really easy: just  set message-subscribed-regexps to a  list of
regexps of the list you are subscribed to. For example:

(setq message-subscribed-regexps '("@lists.debian.org"
   "@lists.alioth.debian.org"
   ))

Most mailers comply with this header.
-- 
GRAMMAR IS NOT A TIME OF WASTE
GRAMMAR IS NOT A TIME OF WASTE
GRAMMAR IS NOT A TIME OF WASTE
-+- Bart Simpson on chalkboard in episode AABF10


pgpNfC594wBfW.pgp
Description: PGP signature

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Pierre Habouzit]

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 understood that the problem we want to
> > solve is about tracking changes we make to upstream.
> 
> Ah, interesting. We are not trying to solve the same problem, which
> might explain why it's so hard to converge to a single solution.
> 
> 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 in that patch or not.
> 
> I thought that the problem of tracking changes for Debian developers was
> already solved by using a VCS and advertising it thought Vcs-*?

  Seconded, on both account. And if the exact details of how the VCS
handles those changes so that an outsider from the maintenance team can
contribute aren't obvious, I read about a README.source proposal that
seems to fill the gap nicely enough.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpWVxWM5PKxQ.pgp
Description: PGP signature

Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

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 make to upstream.

Ah, interesting. We are not trying to solve the same problem, which
might explain why it's so hard to converge to a single solution.

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 in that patch or not.

I thought that the problem of tracking changes for Debian developers was
already solved by using a VCS and advertising it thought Vcs-*?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Bernd Eckenfels]

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/.

However I do agree, extractin that to a web repository would be nice, to
make it linkable.

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Bernhard R. Link]

* 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 usually tried to be
reasonably small.
Compared with some vcs information, where one has to first learn the
layout of that vcs, how branches are accessed via some webinterface
or (even harder) the actual tool. And so on...

> > Everything else is just overhead, as with comments in source
> > code: they are nice to have as long there little, but if there are too
> > many they are most of the time outdated, wrong or distracting.
>
> I find the why and how a patch came together important
> information. You compare this idea to comments in source code. I find
> those invaluable in understanding sources. So you actually made a
> point for the idea imho.

A comment in code that describes how something was implemented is not
really what you want. What you want is information about the current
code: How it works, what is important, what possible pitfalls there are.
Sometimes history can substitute for a bit of that information ("A
changed this in May 1998 to foo, B changed it back one week later because
that causes problems elsewhere" can subsitute for "note that this and
that other code needs this and that here").
Sometimes history is even part of this information (a la "This was once
so and so, be prepared that old data can have this").
History can be valuable information to track down when and how some problem
was introduced, but it is simply so much more information that one needs
an additional view for the important stuff.

> > Instead of adding new stuff, why not actually enforce and improve what
> > we have:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> Say goodby to all packages with +dfsg tarballs. This is just not practical.

Hey, I said "or pure subsets of those". For this the devref "suggests":
"should not contain any file that does not come from the upstream
author(s), or whose contents has been changed by you."

> 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 patchset
constructed from non-quilt based work models, especially with things
centered on history. For example something to tag commits to git
repository, so some package creating tool can put changes belonging
together (like a modification and its updates for newer upstreams)
into a single .diff of such a series. (be that meta-tags in the
description, automatic utilisation of feature branches, extending the
git format or whatever git experts can think of or consider worthwile)
(or perhaps I'm just too stupid to find branch-hopping and manual
merging manually convenient enough to actually do).

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Neil Williams]

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 uploads divergent code with Fixed: #1234
> > [fixed, divergence, forwarded]
> > 4 - bts-link tags the report as upstream work on the issue
> >   [fixed, divergence, forwarded, fixed-upstream],
> > [fixed, divergence, forwarded, pending] etc.
> > 5 - maintainer closes bug in the relevant upstream release
> > [closed]
> > ... time passes ...
> > [archived]
> >
> > 'Tags: + upstream' would mean that the issue is an upstream issue but
> > without a Debian-specific patch (or fix), yet.
> > 'Tags: + divergence' would mean that the upstream issue has been fixed
> > in Debian with a patch in advance of an upstream fix.
> 
> 'fixed + upstream' would mean divergence. No need for a new tag actually.

Hmm, that's interesting. Good idea.

This would mean a relatively simple change to implement the entire
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 closed. 
nnn-fixed is ignored if the upstream tag is not already
set. Bugs can be fixed in the changelog of an upload using
(Fixes: #1234) in a similar manner to (Closes: #1234). The
principle usage of "fixed" is to denote points at which 
Debian diverges from upstream. Filenames of patch files must 
be clearly identified when using (Fixes: #1234) in the
changelog.

Possibly add:
"Fixed bugs must also be tagged Forwarded as well as just
upstream."

or alternatively, 
"Forwarded is equivalent to upstream and one or both tags must
be used for Fixed to work."

Probably also add:
"Fixed bugs must be tagged "patch" for Fixed to work."

Also add: 
"The maintainer may choose not to post the patch to the BTS when
using Fixes: as long as the upstream bug tracker makes all
patches publicly visible without requiring passwords or
authentication."

Lintian could check that the specified patch actually exists and use
that to output a warning if the patch was removed (due to the changes
already being present in the upstream). The other checks implemented in
debchange and in bugs.debian.org.

The requirement for a filename in debian/patches is so that it is easier
to track the point at which Fixes: needs to become Closes:. I suppose it
might be possible to parse the output of lsdiff -z *.diff.gz | grep -v
debian to find the filename of the files being patched and put those in
the Fixes: changelog entry but I would prefer the use of debian/patches
as one source file may contain more than one issue to be Fixed - e.g. a
FTBFS bug in the #include lines and a seg fault in a function
declaration in src/foo.c. YMMV.

Is this acceptable as a possible policy proposal?

> > Uploading a divergent package with Fixed: would mean removing the patch
> > tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed
> > not set). As divergence implies upstream, replace 'upstream' with
> > 'divergence'.
> 
> Why remove the patch tag? Well, ok, maybe it is better so you can get
> a list of pending patches in your package without having already
> applied patches show up.

Well that was just the simplest way of doing things but if the PTS can
be adapted to *ignore* patches where the bug is "fixed" (or at least
split those numbers into a different section of the ToDo list in the
PTS) then that would solve the problem by allowing everyone to clearly
identify which BTS patches are in the package and which are not. Leaving
the patch tag in place could be useful, as long as the relevant web
pages and tools can discriminate between patches in open bugs and
patches in Fixed bugs.

> > In effect, divergence would be a sub-case of upstream as Fixed would be
> > a sub-case of Closed.
> >
> > (Native packages simply use Closed: directly, as now.)
> >
> > We could also specify that Fixed: cannot be used unless 'forwarded' is
> > already set - debchange could check for that.
> 
> So what you're saying is that we only need a minimal change:
> 
> - (Fixes: #1234) in changelog when adding a patch
> - The fixed state from NMU uploads is reused for divergent sources.
> [- debchange does some extra sanity checking]
> 
> And we use "fixed + upstream" as source being divergent.

Yes. A tweak or two in dpkg-dev as well so that Fixes: gets into
the .changes file alongside Closes: (after all, the same upload may
Close some bugs and Fix others), e.g. where the Closed issue is
critical / security-related and warranted an urgent upstream release but
the Fixed issue(s) were minor (or disruptive) and need to wait for a
later upstream release.

This is no more work for 

Re: divergence from upstream as a bug

[Russ Allbery]

"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 systems or
>> glibc systems and upstream would accept it if it were
>> better-implemented.

> This is an orthogonal issue. That explains why some patches are not yet
> incorporated upstream. It does not explain why the patch is necessary.

Er, yes.  However, what I was responding to was your feeling that these
aren't bugs in the Debian package.  I think often they are, in that the
Debian-specific change is less than ideal (per Policy 4.3) and needs
additional work.

> It may be a mess, but it is there. And it is always current.  Not having
> or knowing all things like diffstat and co make it hard to read, but it
> is a place and format everyone can find and everyone can look at.

Sure, I don't think anyone disagrees with that.

> 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 forgotten or
> vanished and reappeared. Not just other upstreams of forks. But also our
> users to see at once what is changed.

Yup, and that's exactly the point of the discussion.  Joey's proposal
about using the BTS is one set of tools that would generate such a web
site, using the web site generation and tracking logic already present in
the BTS to keep it maintained.  There are other possible ways of
implementing such a web site, of course.

>>> Everything else is just overhead, as with comments in source code:
>>> they are nice to have as long there little, but if there are too many
>>> they are most of the time outdated, wrong or distracting.

>> Hm, you and I may have very, *very* different ideas of what
>> well-maintained code looks like.  :)

> Things like
>
>  /* add 1 to where p points at */
>  *p++;
>
> are not helpful.

Well, yes, obviously.  But I almost never see this outside of discussions
like this where it's used as an example of what not to do.  In practice,
nearly all code is under-commented and these sorts of problems are rare.

> Good code with comments helping with the things not codified (which
> should be little, or the code cannot really be called good) is good. Bad
> code will hardly get better and not really much more maintainable with
> more comments.

This is kind of a digression, but.

Most code that's lived in the wild for a while will develop workarounds
and obscure fixes to problems that were not at all obvious when it was
originally written.  The details of those workarounds and fixes *need* to
be written down, and as much as we might wish otherwise, there is no
programming language in existence that makes such problems so clear that
it can usually replace comments.

The general rule of thumb used in many parts of GCC is that if you had to
fix a bug in a piece of code, you probably should at least consider adding
a comment making it clear why the code needs to be written the new way,
since it's apparently not as obvious as you think (or the previous coder
wouldn't have gotten it wrong).  That's correct more often than not in my
experience.

Yes, of course, you have to maintain the comments just like you have to
maintain all other documentation or they quickly become worse than
useless.

>> 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?

> They may not be so many, but there are. FTPmasters consider .orig.tar.gz
> repackaged (though without modification) so minor they just accept them.

What does this have to do with your point?  As you say, that's not a
modified version.  I think it's messy too, but it's not like we're putting
Debian-specific modifications into the upstream *.orig.tar.gz (which as
far as I'm concerned would be a fairly serious bug).

> Our secretary tells people devref is not even worth looking at because
> that says different things in that regard than he likes to do himself.

I'm a bit lost.  Is this referring to the debate over handling DFSG
modifications to upstream tarballs that we had back when the GR passed?

> And packages having a .tar.gz containing the real tar files and
> sometimes even patches may be seldom and declining but to be stumbled
> over regulary.

Oh, this is still quite common, but I don't think that's an example of
your point.  I think it's an awkward way of laying out the package, but
usually the people who do this are even *more* careful about using
pristine upstream tarballs -- that's exactly why they use this layout,
which can do things like handle multiple upstream tarballs.  The tradeoff
is that you have to unpack the *.orig.tar.gz to get the upstream tarball,
but it is there.

>> Git is quite

Re: divergence from upstream as a bug

[Daniel Burrows]

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 the patch is fixing (could be a Debian
> bug or an upstream bug, or even another distro's bug)
>   + URL of the discussion (patch, ML thread) happening upstream about
> this patch

  It seems to me that if you also add a pseudo-header for the bugs
that are relevant to a patch, the BTS could automatically incorporate
the patch into the bug log, and set any states that are deemed
appropriate.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

On 18/05/08 at 15:55 +0200, Goswin von Brederlow wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> 
> > 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 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 and the upstream bug tracker or mailing
> > list where the patch was forwarded (but the patch description should
> > only a summary of the discussion happening upstream). I don't see any
> > reason to additionally duplicate information into the BTS, especially
> > since the discussion of the patch would have to happen both on the
> > upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
> > possible!)
> 
> Who says upstream has a BTS or that the bug was discussed there?

See below ; I agree that filing a bug in the Debian BTS could be a
solution when there's no way to report the patch upstream.

> 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
it's 100% clear, why should I even create a bug on the BTS about it?
There's no point in discussing something that doesn't need discussion.

> I agree with you that the bug description should be a summary. The BTS
> would be the history of the patch. The how and why it became. If that
> info is in upstreams BTS then you would just link that.
> 
> > 2) It makes the BTS another place to look at for upstreams or other
> > distros interested in our patches.
> 
> What other place is there currently besides extracting the source and
> checking that?

The source package's debian/patches dir, which will still be the
canonical place to get the up-to-date patch?

> > 3) BTS bugs do a poor job at providing summaries, so nobody can have a
> > quick glance at a patch and determine its status. Sure, a design was
> > posted for a "summary" feature for the BTS (and I'd like that
> > feature). But there's no implementation yet.
> 
> Lets not improve things because we haven't improved things yet?
> This is a stupid argument.

My point is "let's not make this improvement depend on a whole tree of
improvements in other parts of Debian infrastructure, if possible".

> > 4) The bureaucracy/usefulness ratio looks very high to me. After all,
> > we spent 15 years not doing that, and it seems to me that many patches
> > are small and don't require any discussion, so the overhead would be
> > huge. Maybe we could try a simpler solution first?
> 
> "bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
> the BTS. Not mutch work.

That's not enough. It doesn't extract the relevant patch automatically
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 specific patch
- fixed in upstream

> > 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 the patch is fixing (could be a Debian
> > bug or an upstream bug, or even another distro's bug)
> >   + URL of the discussion (patch, ML thread) happening upstream about
> > this patch
> >
> > - encourage maintainers to use those pseudo-headers
> >
> > - publish patches on patches.debian.org so upstreams, other distros
> >   and users can have an easy look at them.
> >
> > - make patches.debian.org able to track upstream bugs and mark
> >   patches that were integrated upstream as such.
> >
> > - when there's really no place to submit patches upstream, encourage
> >   maintainers to file a bug in the Debian BTS about the patch, so
> >   the discussion about it can happen there. (with all the
> >   infrastructure you want in the BTS about it -- see the many mails in
> >   the thread about technical details).
> 
> So you not only duplicate vers

Re: divergence from upstream as a bug

[Bas Wijnen]

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, there is nothing to track.  So it's not about helping
upstream, it's about helping others who may be interested in our
changes.  Such people may be NMUers, or other distribution's packagers,
for example.

> > >   What Joey's proposal is:
> > >   * put more burden on the maintainers that already report patch
> > > upstream ;
> > 
> > Are these maintainers not recording the fact of a bug in the BTS?
> 
> When it's fixed in Debian ? What's the point ?

They have already reported the issue as a bug, if they did things right,
and they close that bug with their change.  In other words, they're
interacting with the BTS already anyway.

In fact, it could be a good idea to let this BTS interaction work
through debian/changelog as well, similar to closes: #123456.  (It
should of course be able to open bugs as well.)

The point is that this information is worth tracking, and the BTS is a
technical system which is very capable of doing so.  A bug in the BTS
doesn't mean that there is something that needs fixing.  Already it
doesn't, which is why we have the WONTFIX tag.  This just adds another
category of bugs which may or may not need fixing.

The benefit is not that the number of changes will be minimized due to
people trying to get the BTS empty[1].  The benefit is that things are
nicely documented and trackable.

Also, all the extra work you see is minimal IMO.  We're talking about
the situation where the maintainer will be writing code and testing the
changes.  This takes something like half an hour, minimum.  Then a good
maintainer will inform upstream about this, which takes about 5 minutes.
Most upstreams will be reached using e-mail (a mailinglist, usually).
In that case, adding the Cc: and pseudo-headers takes less than a
minute.  If they don't have e-mail, sending one to the BTS takes perhaps
two minutes.  This is really not significant compared to the task it is
added to.

I don't see your problem.

Thanks,
Bas

[1] Just to plug in one of my favorite subjects: IMO if the maintainer
disagrees with upstream about how to fix something, it is good that
the maintainer will make the changes (which are then not
incorporated upstream).  So in those cases, I would be against
"fixing" those bugs by dropping the patches.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Bas Wijnen]

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 overhead...

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Cyril Brulebois]

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 another century.

Oh boy, are you really “fighting” over wasting one half second to type
‘L’ instead of ‘r’ when you reply to a list? (In mutt, there’s a
list-reply function, why not use it in the first place? Most decent MUAs
have that feature as well.)

Mraw,
KiBi.


pgpPdSwa6xk0H.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Bernhard R. Link]

* 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 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 systems or glibc systems
> and upstream would accept it if it were better-implemented.

This is an orthogonal issue. That explains why some patches are not yet
incorporated upstream. It does not explain why the patch is necessary.

> Except from upstream's perspective, it's a mess, and not necessarily worth
> their time to bother to read.  All the debian directory stuff is mixed in
> with Autoconf noise, config.* updates, and actual changes they might care
> about.  Even if the patches are broken out into separate files in
> debian/patches, they now have to download the diff and apply it to
> something to get readable patches.  And after they go to all that work,
> they may discover there's no meaningful divergence at all; there's no
> warning in advance of whether that's the case.

It may be a mess, but it is there. And it is always current.
Not having or knowing all things like diffstat and co make it hard to
read, but it is a place and format everyone can find and everyone can
look at.
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 forgotten
or vanished and reappeared. Not just other upstreams of forks. But also
our users to see at once what is changed.
And with no additional impact for maintainers than to look at using
proper formats, adding description to the patches and stuff like that.

> > Everything else is just overhead, as with comments in source code: they
> > are nice to have as long there little, but if there are too many they
> > are most of the time outdated, wrong or distracting.
> 
> Hm, you and I may have very, *very* different ideas of what
> well-maintained code looks like.  :)

Things like

 /* add 1 to where p points at */
 *p++;

are not helpful. If types and variable do not speak or even only indenting
is incomprehensible, comments can not help. A comment stating what one
can see with one look at once glare do not help but are annoying once
no longer in sync. Prose being so long one cannot see the code and the
types of the local variables on the same screen is also most likely
causing more problems then helping. Good code with comments helping
with the things not codified (which should be little, or the
code cannot really be called good) is good. Bad code will hardly get
better and not really much more maintainable with more comments.

> > Instead of adding new stuff, why not actually enforce and improve what
> > we have:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> 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?

They may not be so many, but there are. FTPmasters consider .orig.tar.gz
repackaged (though without modification) so minor they just accept them.
Our secretary tells people devref is not even worth looking at because
that says different things in that regard than he likes to do himself.
And packages having a .tar.gz containing the real tar files and
sometimes even patches may be seldom and declining but to be stumbled
over regulary.

> Git is quite good at presenting modifications if you know how to use it.

Git is good at representing history. It might be nice for a maintainer
to see that line X was once changed and then changed again later, or
rather not really changed but only merged with the new upstream. And
then some years later the variable accessed here was renamed thus the
line had to be changed again.
I've from time to time tried to look at other people's modifications to
packages I maintain. And especially the BSDs tend to always have had all
stuff in VCSes. I'd rather have a large .diff.gz without any other
smaller files than to have to wade to history. (In the former it are at
least other changes, which sometimes might be related to what I look at,
the history is almost never intresting[1]).

Hochachtungsvoll,
Bernhard R. Link

[1] That does not claim that it is never or not very valuable then. But
for the common case it is so much littering, that if it somewhere, then
that should be somewhere else.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp2VXNRBPTaf.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Pierre Habouzit]

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, although I guess tf5 does use the Sourceforge tracker,
> kind of.

  There's two things to use bts-link:

  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
 supported since yesterday thanks to Jelmer Vernooij, sf.net is
 supported as well.

  2/ mark the bugs you know have a corresponding bug on the upstream bts
 as 'forwarded' with the proper URL.

  IOW basically, just do your usual workflow, bts-link adds 0 overhead
on your work, that's exactly why it's valuable. You can see a small doc
on http://bts-link.alioth.debian.org/ about what I just said.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpI97ycqOFb0.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Goswin von Brederlow]

"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 multiple
> patches, but for this adding additional patch files in there works
> smootly.

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.

> This is were people look at and what I from looking for changes of other
> distributions of packages I maintain often miss elsewhere: A complete,
> current list of what is actually changed.

Maybe the diff.gz could be parsed automatically for patches and linked
on packages[.qa].debian.org. At least the headers of each patch could
be directly accessible from the web just like the changelog. I think
that would be nice short of the BTS idea.

> Everything else is just overhead, as with comments in source
> code: they are nice to have as long there little, but if there are too
> many they are most of the time outdated, wrong or distracting.

I find the why and how a patch came together important
information. You compare this idea to comments in source code. I find
those invaluable in understanding sources. So you actually made a
point for the idea imho.

> Instead of adding new stuff, why not actually enforce and improve what
> we have:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.

Say goodby to all packages with +dfsg tarballs. This is just not practical.

> And when extending the source packaging format, do not throw away the good
> properties lightly. Git for example is no format to present
> modifications. It is one to present history (which is almost but not
> quite something completely different).

The quilt extension is certainly a big improvement and will hopefully
unify a lot of patch system using packages after lenny.

> Thanks in advance,
>   Bernhard R. Link

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Aurelien Jarno]

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 support for Joey's proposal?
> >> A software which does not work without patches is IMHO buggy.
> >
> > Do you have a proposal for a remplacement of the glibc then?
> 
> Why would you want to replace it? The proposal is about tracking the
> required patches in the BTS. Not about removing them.

Because it was suggested by Andreas the glibc is buggy.

> > 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
> > insults.
> 
> Wouldn't it be nice to have those attempts and insults archived for
> other people to see? That way when something like the OpenSSL
> catastrophe hits you you can point to the BTS and show what discussion
> went on with upstream.

That's already the case, those bugs are in upstream BTS. It's really
easy to point to them. Also if the patch comes from a bug in the Debian
BTS, we already use the forwarded tag to make the link between the
Debian and upstream BTS.

> > That's why I personally don't want another level of administrative task
> > like proposed by Joey Hess, which won't improve things in that case. We 
> > already have hundreds of bugs to fix in the Debian Glibc package, I 
> > don't want to waste my time.
> 
> I don't think tagging a bug is so much work. And for a team maintained

We are not speaking about tagging a bug, but opening a second bug in 
*our* BTS. I already find that I am spending too much time fighting with
bugzilla, I don't want to spend more time opening a second bug in our
BTS (and later having to close it). 

> package it would make things more transparent for everyone. You
> already need to coordinate sending patches upstream in some way. Why
> not use the BTS?

We already use the name of the patch (local-, submitted- and cvs-) to
know the status of a given patch. This is even more productive than
using the BTS for that, as you don't want to have to lookup the BTS each
time you are looking at a patch

Also there is no need to coordinate sending patch upstream. The one who
add a non Debian specific (not local-) patch to our SVN should send it
upstream. That's all.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Bernhard R. Link]

* 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 "no modifications"?

I think we already have a definition for that.

> Even a subset already implies modifications.

That's why I explicitly mentioned it. That is what repacking is supposed
to be limited to. (and doing this in itself is quite limited at least by
the text of the devref)

> But what about a snapshot from $VCS_OF_THE_DAY? The exists no pristine 
> tarball.

When no upstream exists then obviously putting the available stuff in
one (or using one of the available methods like make dist) is the obviously the
nearest approximation.

> And if someone really wants to do that he
> may pull the source unmodified from its own fork which is resynchronized
> for each version.

I'm not against forks. But who forks should also accept upstream
responsibilities.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Mailing lsit code of conduct, again (was: divergence from upstream as a bug)

[Ben Finney]

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 count as
> > an explicit request; in the absence of that, the code of conduct
> > should apply.
> 
> oh boy, are we really "fighting" over a dupe of a mail ?

Your mail message individually to me is not wanted, and I have a
reasonable expectation through the mailing list code of conduct *and*
through my explicit request that you not send it. Yet you continue to
do so, violating both.

> wasting 4k of data and two keystrokes ?

You make unfounded assumptions about how I receive and handle messages
in this forum.

> CoC is meant to reduce rudeness

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 to the list.

-- 
 \  "I bought some powdered water, but I don't know what to add."  |
  `\  -- Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Aurelien Jarno]

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 to do, especially when it concerns
> > "embedded crap" [1]: at best your patch is ignored, at worst you get
> > insults.
> 
> Has using eglibc.org as upstream been considered? Forking is a valid
> option when upstream is as hostile and unco-operative as glibc's is.

While I plainly support EGLIBC, it is mainly targeted to the embedded
world. I am not sure it is a good idea to switch a server/desktop
distribution to EGLIBC *yet*, also given that I find this project a big
young. Also it would cause divergence from other distributions, which 
seems to be the exact contrary to what seems to be discussed in this
thread.

That said, if the relation with upstream doesn't improve, and if in the
next years EGLIBC prove to be the way to go, we would consider switching
to it.


> > That's why I personally don't want another level of administrative task
> > like proposed by Joey Hess, which won't improve things in that case.
> 
> It seems very debian way - fix collaboration problems with policies
> and bureacracy..

Exactly. The problem is that most maintainers do not really feel it is
important to submit patch upstreams. Creating new tools won't help in
that case, while they will bother those already doing that.


> I would propose that maintainers can suggest alternative
> collobarion models with upstream as well. Such as maintaing the delta
> against upstream in VCS branch of upstream, maintaining a policy that

The problem is that you can't change upstream if it has proved to be
non-collaborative. OTOH I think we are currently managing the patches we
apply correctly, they are sorted by architecture, and by status (debian
specific, submitted and taken from cvs).


> packager will only include patches that are already in committed upstream
> VCS, or extreme cases declaring that the debian packaging is a fork of
> upstream.

For the glibc case, that would mean we should drop support for at least
half of the currently supported architecture.

Our current policy is to not commit a patch (except debian specific 
ones) in the SVN if it has not been submitted upstream.

IMHO, each package is specific, you can't have a global policy on the
way to forward patches upstream.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> 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 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 and the upstream bug tracker or mailing
> list where the patch was forwarded (but the patch description should
> only a summary of the discussion happening upstream). I don't see any
> reason to additionally duplicate information into the BTS, especially
> since the discussion of the patch would have to happen both on the
> upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
> possible!)

Who says upstream has a BTS or that the bug was discussed there?
Esspecially when you have debian specific patches where things are a
clear divergence there won't be an upstream record.

I agree with you that the bug description should be a summary. The BTS
would be the history of the patch. The how and why it became. If that
info is in upstreams BTS then you would just link that.

> 2) It makes the BTS another place to look at for upstreams or other
> distros interested in our patches.

What other place is there currently besides extracting the source and
checking that?

> 3) BTS bugs do a poor job at providing summaries, so nobody can have a
> quick glance at a patch and determine its status. Sure, a design was
> posted for a "summary" feature for the BTS (and I'd like that
> feature). But there's no implementation yet.

Lets not improve things because we haven't improved things yet?
This is a stupid argument.

> 4) The bureaucracy/usefulness ratio looks very high to me. After all,
> we spent 15 years not doing that, and it seems to me that many patches
> are small and don't require any discussion, so the overhead would be
> huge. Maybe we could try a simpler solution first?

"bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
the BTS. Not mutch work.

> 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 the patch is fixing (could be a Debian
> bug or an upstream bug, or even another distro's bug)
>   + URL of the discussion (patch, ML thread) happening upstream about
> this patch
>
> - encourage maintainers to use those pseudo-headers
>
> - publish patches on patches.debian.org so upstreams, other distros
>   and users can have an easy look at them.
>
> - make patches.debian.org able to track upstream bugs and mark
>   patches that were integrated upstream as such.
>
> - when there's really no place to submit patches upstream, encourage
>   maintainers to file a bug in the Debian BTS about the patch, so
>   the discussion about it can happen there. (with all the
>   infrastructure you want in the BTS about it -- see the many mails in
>   the thread about technical details).

So you not only duplicate version tracking in patches.d.o but also add
that and the BTS to the places upstream should look for patches?

That contradicts your 2) above.

> - Lucas

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Russ Allbery]

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
>> insults.

> Wouldn't it be nice to have those attempts and insults archived for
> other people to see? That way when something like the OpenSSL
> catastrophe hits you you can point to the BTS and show what discussion
> went on with upstream.

Finding the attempts of and resulting insults towards people trying to
work with glibc upstream isn't particularly hard.  I think the libc-alpha
mailing list is archived, for example.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Russ Allbery]

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 that you are interacting with upstream, unless upstream is
willing to do what we all do and send all the discussion to the bug
address.  And even that only gets the discussion, not any state changes.

(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, although I guess tf5 does use the Sourceforge tracker,
kind of.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Ben Finney]

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 that work ever. Yay.
> That's kind of what I call bureaucracy indeed.

This, at least, is addressing the point of the proposal. Thanks.

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.

-- 
 \ “Any intelligent fool can make things bigger and more |
  `\complex... It takes a touch of genius – and a lot of courage |
_o__) – to move in the opposite direction.” —Albert Einstein |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 in the absence of explicit
> requests. A Mail-Followup-To field setting may or may not count as an
> explicit request; in the absence of that, the code of conduct should
> apply.

  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 another century.

> > debian/patches is the proper place to put your changes.
> 
> Is it? Where is that stated to be required for all packages throughout
> Debian?

  For any reasonnably sized package, yes it should. Though it's not
required. The same way it's not required to use debhelper, even if
something like 90% of the archive do. Don't mix up things that are
mandatory, with best practices.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp3V3KEPEyz3.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Ben Finney]

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 are listed in the proposal as a "can", not a
"should" -- i.e. something that would be a natural part of the
workflow, but not a necessary part of the proposal.

-- 
 \"Don't worry about people stealing your ideas. If your ideas |
  `\are any good, you'll have to ram them down people's throats."  |
_o__)  -- Howard Aiken |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

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 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, 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.
>> 
>> I think a frequent workflow goes like this:
>> 
>> 1) user reports bug  [open]
>> 2) patch is added[open, Tags: patch]
>> 3) bug gets closed   [closed]
>> 
>> where 2 and 3 are often just a new version being uploaded. If I
>> understand you right you would add the following:
>> 
>> 2b) patch is send upstream [open, Tags: patch, send-upstream]
>> 3b) source diverges[closed, Tags: divergence, send-upstream]
>> 4) upstream accepts patch  [closed, Tags: divergence, fixed-upstream]
>> 5) new upstream release[closed]
>
> s/send-upstream/upstream/ - we already have a fixed-upstream.
>
> 1 - User reports bug with a patch against upstream code
>   [open, patch]
> 2 - maintainer forwards the patch upstream
>   [confirmed, patch, upstream, forwarded]
> 3 - maintainer uploads divergent code with Fixed: #1234
>   [fixed, divergence, forwarded]
> 4 - bts-link tags the report as upstream work on the issue
> [fixed, divergence, forwarded, fixed-upstream],
>   [fixed, divergence, forwarded, pending] etc.
> 5 - maintainer closes bug in the relevant upstream release
>   [closed]
> ... time passes ...
>   [archived]
>
> 'Tags: + upstream' would mean that the issue is an upstream issue but
> without a Debian-specific patch (or fix), yet.
> 'Tags: + divergence' would mean that the upstream issue has been fixed
> in Debian with a patch in advance of an upstream fix.

'fixed + upstream' would mean divergence. No need for a new tag actually.

> Uploading a divergent package with Fixed: would mean removing the patch
> tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed
> not set). As divergence implies upstream, replace 'upstream' with
> 'divergence'.

Why remove the patch tag? Well, ok, maybe it is better so you can get
a list of pending patches in your package without having already
applied patches show up.

> In effect, divergence would be a sub-case of upstream as Fixed would be
> a sub-case of Closed.
>
> (Native packages simply use Closed: directly, as now.)
>
> We could also specify that Fixed: cannot be used unless 'forwarded' is
> already set - debchange could check for that.

So what you're saying is that we only need a minimal change:

- (Fixes: #1234) in changelog when adding a patch
- The fixed state from NMU uploads is reused for divergent sources.
[- debchange does some extra sanity checking]

And we use "fixed + upstream" as source being divergent.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Russ Allbery]

"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 bug.
>> Everything else follows from that quite naturally..

> 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 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 systems or glibc systems
and upstream would accept it if it were better-implemented.  In that case,
it really is still an open bug against the Debian package (and Policy
concurs).

There are certainly patches in the category that you describe, however.
Many of them are even cherry-picked from upstream's VCS.

> 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 multiple patches, but for this
> adding additional patch files in there works smootly.
>
> This is were people look at and what I from looking for changes of other
> distributions of packages I maintain often miss elsewhere: A complete,
> current list of what is actually changed.

Except from upstream's perspective, it's a mess, and not necessarily worth
their time to bother to read.  All the debian directory stuff is mixed in
with Autoconf noise, config.* updates, and actual changes they might care
about.  Even if the patches are broken out into separate files in
debian/patches, they now have to download the diff and apply it to
something to get readable patches.  And after they go to all that work,
they may discover there's no meaningful divergence at all; there's no
warning in advance of whether that's the case.

> Everything else is just overhead, as with comments in source code: they
> are nice to have as long there little, but if there are too many they
> are most of the time outdated, wrong or distracting.

Hm, you and I may have very, *very* different ideas of what
well-maintained code looks like.  :)

> Instead of adding new stuff, why not actually enforce and improve what
> we have:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.

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?

> And when extending the source packaging format, do not throw away the
> good properties lightly. Git for example is no format to present
> modifications. It is one to present history (which is almost but not
> quite something completely different).

Git is quite good at presenting modifications if you know how to use it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 re-read the original proposal that starts this
> thread, and I can't see where everyone is reading "bureaucracy" and
> "extra workload" and "patches floating in the BTS" and "forcing
> upstream to read new BTS tags and features".
> 
> The proposal, at its core, is merely about how to *classify*
> divergence from upstream source in a Debian package. There's nothing
> in the original message that requires patches to be duplicated, or
> upstream to get patches in a different way, or any of the other
> spectres people are raising here.

  That's 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 that work ever. Yay.
That's kind of what I call bureaucracy indeed.

  What _would_ help is helping maintainers to report bugs upstream,
whatever the upstream way of tracking them works, with a unified
method/tool/whatever. _That_ would be more than useful. And it could
probably do what we're discussing as a side effect of reporting the bug
upstream. That would be in the end _LESS_ work for the maintainer, as it
eases the report to upstream, while having all the side effects you
want.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpe6aY6XTb2h.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Ben Finney]

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 setting may or may not count as an
explicit request; in the absence of that, the code of conduct should
apply.

> debian/patches is the proper place to put your changes.

Is it? Where is that stated to be required for all packages throughout
Debian?

-- 
 \  "Truth: Something somehow discreditable to someone."  -- Henry |
  `\L. Mencken |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Russ Allbery]

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 forward our patches. (Some
> corner-case have to be dealt for example when upstream is dead or has no
> appropriate infrastructure (no ML and no BTS)).

Yes, although one has to be a bit careful about this.  Some upstreams are
land mines and the forwarding of patches has to be done very carefully and
with specific types of justification.  Otherwise, all you get is a rant
about how Debian is breaking their software.  I wouldn't want to subject
someone new to Debian to that (or risk that someone new to that sort of
interaction might make matters worse).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Goswin von Brederlow]

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 buggy.
>
> Do you have a proposal for a remplacement of the glibc then?

Why would you want to replace it? The proposal is about tracking the
required patches in the BTS. Not about removing them.

> 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
> insults.

Wouldn't it be nice to have those attempts and insults archived for
other people to see? That way when something like the OpenSSL
catastrophe hits you you can point to the BTS and show what discussion
went on with upstream.

> That's why I personally don't want another level of administrative task
> like proposed by Joey Hess, which won't improve things in that case. We 
> already have hundreds of bugs to fix in the Debian Glibc package, I 
> don't want to waste my time.

I don't think tagging a bug is so much work. And for a team maintained
package it would make things more transparent for everyone. You
already need to coordinate sending patches upstream in some way. Why
not use the BTS?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 earlier.

  FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
honour that.

> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > On Sun, May 18, 2008 at 09:57:02AM +, Ben Finney wrote:
> > > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >   But it's NOT ABOUT Debian package maintainers.
> 
> You seem to contradict yourself; in the earlier message I quoted
> above, *you* raised the issue of "requires more work from the
> maintainer". I was responding directly to that point. If you don't
> think the effect on maintainers is relevant, I don't see why you
> raised it in the first place.

  huh you don't get it. It requires more work from the maintainer, _and_
gives nothing to upstream. But the problem we want to solve is making
things easier for upstreams. And it doesn't, at the cost of *OUR* time
that is already soo scarce.

> >   More administrivia is never an improvement. See (yeah I know it's
> > always about the glibc, but well … that's a very good example for the
> > discussion) in the glibc we have
> > debian/patches/$arch/$state-$subject.patches. For $state in
> > {submitted,local,cvs}. submitted means its sent upstream, local means
> > that it's not, cvs that it's a cherry-pick from upstream. Why on earth
> > would we need to write that in _yet another place_ ?
> 
> 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 similar purposes,
> instead of having that information scattered in many places.

  *g* you absolutely miss my point. Upstream *DON'T* go to our BTS
except in very rare case, because they don't really care about Debian
more than say fedora, gentoo, $distro.

> >   What Joey's proposal is:
> >   * put more burden on the maintainers that already report patch
> > upstream ;
> 
> Are these maintainers not recording the fact of a bug in the BTS?

  When it's fixed in Debian ? What's the point ?

> This assumes that 'debian/patches' is a known standard interface for
> all Debian packages, which I would think it clearly isn't in light of
> previous threads here. The Debian BTS, on the other hand, *is* a known
> standard interface for all Debian packages.

  debian/patches is the proper place to put your changes. the BTS is the
proper place to track _actual_ bugs in Debian. Not the one that are
fixed in Debian and not upstream's. upstream BTSes are made for that.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp9DTgwLhG34.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Bastian Blank]

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
modifications. But what about a snapshot from $VCS_OF_THE_DAY? The
exists no pristine tarball. And if someone really wants to do that he
may pull the source unmodified from its own fork which is resynchronized
for each version.

Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, "Errand of Mercy", stardate 3198.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Ben Finney]

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 only be a
> companion one, but not a reliable source of what has actually
> changed, so consider it 'yet another place to DIG at'.

Whether the patch is in the bug report or not, I don't see how that
affects the proposal.

> 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 re-read the original proposal that starts this
thread, and I can't see where everyone is reading "bureaucracy" and
"extra workload" and "patches floating in the BTS" and "forcing
upstream to read new BTS tags and features".

The proposal, at its core, is merely about how to *classify*
divergence from upstream source in a Debian package. There's nothing
in the original message that requires patches to be duplicated, or
upstream to get patches in a different way, or any of the other
spectres people are raising here.

It *suggests* that, with such a classification, certain workflows
would be enabled naturally; but it doesn't *insist* on any of them.

There's merely the proposal that we start *tracking* the divergence as
a bug that needs resolution, like any other bug report in the BTS.

Am I wrong?

-- 
 \"I hate it when my foot falls asleep during the day, because |
  `\ that means it's gonna be up all night."  -- Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Bernhard R. Link]

* 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 naturally..

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.

> For all the maintainers who already keep on top of forwarding their
> changes upstream, this won't be much of a burden; ideally you just CC
> the BTS and add some pseudoheaders.

Except that this hardly fits in reality. With active upstream you
usually have the discussion first, and decide to add the patch after
that and considering the impact on the code, the severity of the bug and
the perspective of upcoming upstream releases.

> For ones who can't, because they
> cannot communicate with upstream (for whatever reason), it gives them a
> way to communicate with other interested parties (users, other distros)
> and maybe resume communication with upstream in the future.

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 multiple
patches, but for this adding additional patch files in there works
smootly.

This is were people look at and what I from looking for changes of other
distributions of packages I maintain often miss elsewhere: A complete,
current list of what is actually changed.

Everything else is just overhead, as with comments in source
code: they are nice to have as long there little, but if there are too
many they are most of the time outdated, wrong or distracting.

Instead of adding new stuff, why not actually enforce and improve what
we have:
I'd suggest to start with making pristine upstream tarballs (or pure
subsets of those) obligatory. No modifications allowed in there and no
exceptions.
And when extending the source packaging format, do not throw away the good
properties lightly. Git for example is no format to present
modifications. It is one to present history (which is almost but not
quite something completely different).

Thanks in advance,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[George Danchev]

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 similar purposes,
> instead of having that information scattered in many places.

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 only be a companion one, but not a reliable source of 
what has actually changed, so consider it 'yet another place to DIG at'.

> >   What Joey's proposal is:
> >   * put more burden on the maintainers that already report patch
> > upstream ;
>
> Are these maintainers not recording the fact of a bug in the BTS?

Yes, that activity is not bullet proof.

> >   * has very few advantages for people that already did that work in
> > their source package in a decent enough way (like the glibc does):
> > the sole advantage I see is that it's predictable where to find the
> > information. But when you want to check a package you have to
> > `apt-get source` it anyways, and if debian/patches is sorted
> > properly, then you'll see that in an obvious way before even
> > launching your browser to look at the BTS.
>
> This assumes that 'debian/patches' is a known standard interface for
> all Debian packages, which I would think it clearly isn't in light of
> previous threads here. The Debian BTS, on the other hand, *is* a known
> standard interface for all Debian packages.

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.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Raphael Hertzog]

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 upstream, so the bug is tagged as a divergence,
> and then later upstream fixes it so the bug is closed.

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 forward our patches. (Some corner-case
have to be dealt for example when upstream is dead or has no
appropriate infrastructure (no ML and no BTS)).

This particular case (which I like) goes however in the opposite
direction of what I gathered... up to now it looked like that your idea
was better suited to be patches.debian.org based on debbugs but not
inside bugs.debian.org.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Riku Voipio]

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 patch is ignored, at worst you get
> insults.

Has using eglibc.org as upstream been considered? Forking is a valid
option when upstream is as hostile and unco-operative as glibc's is.

> That's why I personally don't want another level of administrative task
> like proposed by Joey Hess, which won't improve things in that case.

It seems very debian way - fix collaboration problems with policies
and bureacracy..

I would propose that maintainers can suggest alternative
collobarion models with upstream as well. Such as maintaing the delta
against upstream in VCS branch of upstream, maintaining a policy that
packager will only include patches that are already in committed upstream
VCS, or extreme cases declaring that the debian packaging is a fork of
upstream.

-- 
"rm -rf" only sounds scary if you don't have backups


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Ben Finney]

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
> > Debian BTS)
> 
> Huh? Upstreams knowing about the Debian BTS? Sure, in an ideal
> world, that's the case. But most upstreams don't follow the
> BTS/don't use it, simply because they don't have time to do that.

That's not what I said, though. I posited only that they know it
exists as a place to look for Debian-specific information, in the
context that it's not a *new* place for them to look for such
information.

Whether or not they actually look there isn't something we can have
much hope of enforcing, regardless of where it is.

-- 
 \   "Prediction is very difficult, especially of the future."  -- |
  `\Niels Bohr |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Ben Finney]

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 18, 2008 at 09:57:02AM +, Ben Finney wrote:
> > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > 
> > >   That's why the proposal is bad. It doesn't improve that, and
> > > it requires more work from the maintainer. Lose/lose situation.
> > 
> > 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) and that all Debian package maintainers are already
> > expected to know how to use.
> 
>   But it's NOT ABOUT Debian package maintainers.

You seem to contradict yourself; in the earlier message I quoted
above, *you* raised the issue of "requires more work from the
maintainer". I was responding directly to that point. If you don't
think the effect on maintainers is relevant, I don't see why you
raised it in the first place.

>   More administrivia is never an improvement. See (yeah I know it's
> always about the glibc, but well … that's a very good example for the
> discussion) in the glibc we have
> debian/patches/$arch/$state-$subject.patches. For $state in
> {submitted,local,cvs}. submitted means its sent upstream, local means
> that it's not, cvs that it's a cherry-pick from upstream. Why on earth
> would we need to write that in _yet another place_ ?

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 similar purposes,
instead of having that information scattered in many places.

>   What Joey's proposal is:
>   * put more burden on the maintainers that already report patch
> upstream ;

Are these maintainers not recording the fact of a bug in the BTS?

>   * has very few advantages for people that already did that work in
> their source package in a decent enough way (like the glibc does):
> the sole advantage I see is that it's predictable where to find the
> information. But when you want to check a package you have to
> `apt-get source` it anyways, and if debian/patches is sorted
> properly, then you'll see that in an obvious way before even
> launching your browser to look at the BTS.

This assumes that 'debian/patches' is a known standard interface for
all Debian packages, which I would think it clearly isn't in light of
previous threads here. The Debian BTS, on the other hand, *is* a known
standard interface for all Debian packages.

-- 
 \  "I busted a mirror and got seven years bad luck, but my lawyer |
  `\ thinks he can get me five."  -- Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

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 BTS? Sure, in an ideal world,
that's the case. But most upstreams don't follow the BTS/don't use it,
simply because they don't have time to do that.

So it's better to provide a new source of information (patches.d.o),
with only the most important information, without asking upstream to go
through all bugs in a package to find a few useful patches.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Aurelien Jarno]

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 which does not work without patches is IMHO buggy.
>> 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 patch is ignored, at worst you get
>> insults.
>>
>> That's why I personally don't want another level of administrative task
>> like proposed by Joey Hess, which won't improve things in that case. We 
>> already have hundreds of bugs to fix in the Debian Glibc package, I 
>> don't want to waste my time.
>>
>>
>>> Despite the technical fact in this specific case it also forces divergences
>>> between distributions - which is even worse.
>>>
>> Maybe it is worst, but it is actually a wish from upstream. Upstream
>> Glibc maintainers also manage the RedHat/Fedora branch in the same CVS,
>> and sometimes doesn't even bother to backport patches from this branch
>> to the trunk.
> 
> Isn't Ulrich Drepper RH/Fedora glibc maintainer ?

He is.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Mike Hommey]

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 work without patches is IMHO buggy.
> 
> 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 patch is ignored, at worst you get
> insults.
> 
> That's why I personally don't want another level of administrative task
> like proposed by Joey Hess, which won't improve things in that case. We 
> already have hundreds of bugs to fix in the Debian Glibc package, I 
> don't want to waste my time.
> 
> 
> > Despite the technical fact in this specific case it also forces divergences
> > between distributions - which is even worse.
> > 
> 
> Maybe it is worst, but it is actually a wish from upstream. Upstream
> Glibc maintainers also manage the RedHat/Fedora branch in the same CVS,
> and sometimes doesn't even bother to backport patches from this branch
> to the trunk.

Isn't Ulrich Drepper RH/Fedora glibc maintainer ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Lucas Nussbaum]

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 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 and the upstream bug tracker or mailing
list where the patch was forwarded (but the patch description should
only a summary of the discussion happening upstream). I don't see any
reason to additionally duplicate information into the BTS, especially
since the discussion of the patch would have to happen both on the
upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
possible!)

2) It makes the BTS another place to look at for upstreams or other
distros interested in our patches.

3) BTS bugs do a poor job at providing summaries, so nobody can have a
quick glance at a patch and determine its status. Sure, a design was
posted for a "summary" feature for the BTS (and I'd like that
feature). But there's no implementation yet.

4) The bureaucracy/usefulness ratio looks very high to me. After all,
we spent 15 years not doing that, and it seems to me that many patches
are small and don't require any discussion, so the overhead would be
huge. Maybe we could try a simpler solution first?

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 the patch is fixing (could be a Debian
bug or an upstream bug, or even another distro's bug)
  + URL of the discussion (patch, ML thread) happening upstream about
this patch

- encourage maintainers to use those pseudo-headers

- publish patches on patches.debian.org so upstreams, other distros
  and users can have an easy look at them.

- make patches.debian.org able to track upstream bugs and mark
  patches that were integrated upstream as such.

- when there's really no place to submit patches upstream, encourage
  maintainers to file a bug in the Debian BTS about the patch, so
  the discussion about it can happen there. (with all the
  infrastructure you want in the BTS about it -- see the many mails in
  the thread about technical details).

- Lucas


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Pierre Habouzit]

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 packaged for
> > > Debian. I don't see that this proposal changes that.
> > 
> >   That's why the proposal is bad. It doesn't improve that, and it
> > requires more work from the maintainer. Lose/lose situation.
> 
> 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) and that all Debian package maintainers are already expected to
> know how to use.

  But it's NOT ABOUT Debian package maintainers.

> That seems like an improvement on putting that information in a *new*
> place, that historically is not a place where all Debian package
> maintainers can be expected to use, and expecting that upstream will
> look there.

  More administrivia is never an improvement. See (yeah I know it's
always about the glibc, but well … that's a very good example for the
discussion) in the glibc we have
debian/patches/$arch/$state-$subject.patches. For $state in
{submitted,local,cvs}. submitted means its sent upstream, local means
that it's not, cvs that it's a cherry-pick from upstream. Why on earth
would we need to write that in _yet another place_ ?


  What Joey's proposal is:
  * put more burden on the maintainers that already report patch
upstream ;
  * doesn't change a thing for the one who don't ;
  * has very few advantages for people that already did that work in
their source package in a decent enough way (like the glibc does):
the sole advantage I see is that it's predictable where to find the
information. But when you want to check a package you have to
`apt-get source` it anyways, and if debian/patches is sorted
properly, then you'll see that in an obvious way before even
launching your browser to look at the BTS.

  As a summary, I see a big-lose/no-win-no-lose/ridiculous-win situation,
which sum up as quite-big-lose.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpmgCsNl00d2.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Aurelien Jarno]

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 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 patch is ignored, at worst you get
insults.

That's why I personally don't want another level of administrative task
like proposed by Joey Hess, which won't improve things in that case. We 
already have hundreds of bugs to fix in the Debian Glibc package, I 
don't want to waste my time.


> Despite the technical fact in this specific case it also forces divergences
> between distributions - which is even worse.
> 

Maybe it is worst, but it is actually a wish from upstream. Upstream
Glibc maintainers also manage the RedHat/Fedora branch in the same CVS,
and sometimes doesn't even bother to backport patches from this branch
to the trunk.


[1] This is how Ulrich Drepper names architectures he doesn't want to
support

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Ben Finney]

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.
> 
>   That's why the proposal is bad. It doesn't improve that, and it
> requires more work from the maintainer. Lose/lose situation.

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) and that all Debian package maintainers are already expected to
know how to use.

That seems like an improvement on putting that information in a *new*
place, that historically is not a place where all Debian package
maintainers can be expected to use, and expecting that upstream will
look there.

The former builds on the existing conventions (use of the Debian BTS
is mandatory for Debian package maintainers, upstreams already at
least know the BTS contains useful information), the latter attempts
to set up a separate system that hasn't historically been mandatory at
all.

-- 
 \"There was a point to this story, but it has temporarily |
  `\ escaped the chronicler's mind."  -- Douglas Adams |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[George Danchev]

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, 2008 at 06:01:19AM +, Ben Finney wrote:
> > > The Debian BTS is already on the list of places to go for
> > > information about Debian package changes. The proposal in this
> > > thread doesn't increase that.
> >
> >   For _debian_ packagers yes. But such a tool would be useful for
> > upstreams, and form them it *is* one another place to look at. And
> > most wont, because for large upstreams, there's this huge userbase
> > you see, and the huge number of downstreams, and huge number of
> > downstreams issue trackers. They can't look at them all.
>
> 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.

Please, also note that relation btw patches floating around in BTS and what 
has been actually applied to the debian source package in use may be 
extremely fragile -- mails got lost, tags being changed (by incident 
including), BTS server going down, you name it... OTOH interested parties can 
have diff.gz from more that 300 mirrors and its relation to what has been 
actually applied to the code is considerably much tighter and trustworty.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]