Re: divergence from upstream as a bug
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
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
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
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
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
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/)
track bugs in VCS, not the other way around (was: divergence from upstream as a bug)
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 [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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
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
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 -- Clint why the hell does kernel-source-2.6.3 depend on xfree86-common? infinity It... Doesn't? Clint 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 people.fccf.net/danchev/key pgp.mit.edu
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
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
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
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
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
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
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
George Danchev [EMAIL PROTECTED] writes: I strongly believe that [...] there is no any urgent need for more infrastrucre enhancements and yet another places to look at (like teaching BTS/PTS of doing additional DD-upstream communication processing which brings even more complexity to the scene). How is the Debian BTS another place to look at? It's already an essential place to look for information about what changes are made in a Debian package. In the world of diversion, there should be a single point of unification one can safely return to. 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. -- \ We tend to scoff at the beliefs of the ancients. But we can't | `\scoff at them personally, to their faces, and this is what | _o__) annoys me. -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tracking divergence from upstream as a bug
On Sat, 2008-05-17 at 23:01 -0400, Joey Hess wrote: Ben Finney wrote: Care to discuss what tags you plan to use, so an attempt at consensus can be made on naming the tags for this purpose? I'm using a divergence usertag, with users [EMAIL PROTECTED] and [EMAIL PROTECTED] (so it'll show up on my bugs page, and the package's bug page -- not ideal). I've done aalib so far. Doing this retrospectively does make things look more than a little odd in the BTS. Unarchiving, reopening, retitling, change severity and then tagging (#97695). I can see the reasoning (keeping the patch with any original bug report) but reopening a bug 7 years after it was closed just to indicate that upstream still hasn't included the fix is more than a little strange to behold. I wonder if such divergence issues should merely start with a new bug and *reference* the old, archived, bug report. I need to implement divergence tags for GPE and soci - I can't decide whether to start new bugs or reopen ones that have already been closed by an upload. Certainly in the future I plan to treat my own bugs more like NMUs and if the fix involves a patch that I have devised myself, send the patch to the BTS prior to the upload. However, from a bug submitter point of view, I don't think I want to see the bug report kept open (tagged divergence) after it has actually been closed by a Debian-specific patch. As upstream it might make a fair bit of sense but as a user / bug submitter, it will just look odd. Also, as upstream, I might not want to trawl through hundreds of comments (possibly including references to other packages due to bugs being reassigned) to get to a patch and possibly find that the patch in the BTS at comment 112 differs from the final patch actually applied before the bug was closed in comment 234. I'm wondering, therefore, if divergence bugs should be NEW bugs that include only the final patch and a summary along with a reference to the old discussion so that the old bug can stay archived and closed and the new bug is updated via bts-link. A user reporting a bug in foo should not still be wondering why the bug is open after the fix has been applied. To me, divergence tags are a maintainer issue, not a user issue and as such, could deserve being filed by the maintainer as a separate issue. To all intents and purposes, the bug actually reported by the submitter was fixed long, long ago - I can't see that it makes a whole lot of sense (to the bug submitter) to reopen it. If I got a message saying that a grave bug that I had reported before Etch was now suddenly reopened in the release phase for Lenny, as a bug submitter I might be a little concerned. -- 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
On Sat, 17 May 2008, Pierre Habouzit wrote: ... glibc without patches can't work. Isn't this the best support for Joey's proposal? A software which does not work without patches is IMHO buggy. Despite the technical fact in this specific case it also forces divergences between distributions - which is even worse. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
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] It would be nice if the changelog could indicate wether a bug is closed by divergence or by upstream. A new statements should be added for the changelog to make divergence easy to handle and document them machine readable in the source: * Adding Debian patch foo (Diverges: #1234) * Patch foo added upstream (Closes: #1234) Maybe divergence could mark a bug as fixed instead of closed. For people that want to use divergence like you propose a bug isn't closed untill it is accepted upstream. There would also be scope for other workflows, as well as automated tools. If a package has a debian/patches, some of which have been forwarded upstream and some not, then a tool could query the BTS (or headers in the patches, whatever) to figure out which have yet to be sent upstream, and send them. Tools could also do this for changes recorded in a VCS. This goes towards having a standard header in each debian/patches/*. The header could include the bug number for this patch or even foreign BTS urls. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sun, 18 May 2008, Josselin Mouette wrote: That would be very nice. I think you could easily make giant improvements by reworking the bug listing pages. They would be much more useful with a table listing all bugs with one bug per line, color indicators for the severity, and a column on the left with icons indicating the tags and the Debian versions the bug applies to. We are doing something like that in Debian Med [1] (to be adapted for other CDDs soon). I don't know whether David Paleino who write this stuff adopted it from seomewhere else, but I wanted to give a hint that this color scheme is useful and working. Kind regards Andreas. [1] http://debian-med.alioth.debian.org/bugs.php -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sunday 18 May 2008, Ben Finney wrote: George Danchev [EMAIL PROTECTED] writes: I strongly believe that [...] there is no any urgent need for more infrastrucre enhancements and yet another places to look at (like teaching BTS/PTS of doing additional DD-upstream communication processing which brings even more complexity to the scene). How is the Debian BTS another place to look at? It's already an essential place to look for information about what changes are made in a Debian package. In the world of diversion, there should be a single point of unification one can safely return to. 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. Eh ;-)... dumping out a phrase out of the context leads to undefined results. I that respect you failed to get my point or I failed to emphasize it as well. So, if your diff.gz brings multiple logical changes to the upstream source in a combined fashion, BTS won't help you make these look better from a reviewer point of view, no matter how cool BTS is tag-tracking changes being forwarded/rejected/whatever upstream. This is superfluous, but yet not useless, since if my system claims that I run upstream 'foo' version 'x.y' I know that all the patches before 'x.y' have been merged upstream and the additional material is place in debian/patches/ ... logically separated and documented in several diffs if any... you get the idea. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu 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
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. 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'. 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. It would be nice if the changelog could indicate wether a bug is closed by divergence or by upstream. A new statements should be added for the changelog to make divergence easy to handle and document them machine readable in the source: * Adding Debian patch foo (Diverges: #1234) * Patch foo added upstream (Closes: #1234) Assuming both refer to the same bug report, I personally prefer the Fixes: #1234 approach: foo (0.1.6-1) unstable; urgency=low * New upstream release * Remove patch 'patch-file-name' included upstream (Closes: #1234) -- Neil Williams [EMAIL PROTECTED] Fri, 16 May 2008 21:29:20 +0100 foo (0.1.5-2) unstable; urgency=low * Add 'patch-file-name' $reason (Fixes: #1234) Maybe divergence could mark a bug as fixed instead of closed. For people that want to use divergence like you propose a bug isn't closed untill it is accepted upstream. I like that idea - the bug submitter gets a notification that the upload has fixed the bug but we continue to track the issue until the patch disappears. As far as the bug submitter is concerned, Fixed == end of the problem. That may require a new column on the DDPO and a new row in the PTS so that bugs that are Fixed but not Closed are shown separately. -- 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
Joey Hess wrote: FWIW, I like the general idea of tracking upstream diverge with a bug. Mike Hommey wrote: The BTS would also need something to make it easier to spot patches in a bug. Patch tracking is one of the few things bugzilla is not bad at, for instance. I guess you're talking about a way for the BTS allow downloading of the last (or preferred) patch sent to a bug. And not just deciding when to set the patch tag. That would be useful for the QA tool that checks if divergence's patches match the debianised source. Dunno if it's mandatory, the tool could also use heuristics, or try every attachment that looks like a patch and see which, if any, match. BTS currently has two deficiencies compared to Bugzilla when it comes to handling patches: - No defined way to store patches (and fetching them automically) Some people add them as attachments, some people inline them in a mail, some send an archive etc. And some PHP people send full modified sources :-) - Bugzilla has the neat feature to mark a patch as obsoleting a previously posted bug, which is often very helpful in complicated bug with several rounds of review and fixups Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tracking divergence from upstream as a bug
Neil Williams [EMAIL PROTECTED] writes: However, from a bug submitter point of view, I don't think I want to see the bug report kept open (tagged divergence) after it has actually been closed by a Debian-specific patch. As upstream it might make a fair bit of sense but as a user / bug submitter, it will just look odd. Would your opinion be different if the bug was fixed but not closed nor archived, until the divergence tag is gone? A user reporting a bug in foo should not still be wondering why the bug is open after the fix has been applied. Isn't that a matter easily resolved by presenting the bug information appropriately in the interface? -- \“Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live.” —John | _o__) F. Woods | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sun, May 18, 2008 at 07:39:07AM +, Andreas Tille wrote: On Sat, 17 May 2008, Pierre Habouzit wrote: ... glibc without patches can't work. Isn't this the best support for Joey's proposal? A software which does not work without patches is IMHO buggy. Despite the technical fact in this specific case it also forces divergences between distributions - which is even worse. You are welcomed to explain that to our upstream. Lots have tried. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCM5L7yqV4d.pgp Description: PGP signature
Re: divergence from upstream as a bug
On Sun, May 18, 2008, Lucas Nussbaum wrote: (This discussion is similar to the one about DEPs vs BTS bugs -- a discussion on the BTS would always miss a summary.) I didn't follow this discussion, but it strikes me that many bug trackers have a summary for bugs. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tracking divergence from upstream as a bug
On Sun, 2008-05-18 at 18:43 +1000, Ben Finney wrote: Neil Williams [EMAIL PROTECTED] writes: However, from a bug submitter point of view, I don't think I want to see the bug report kept open (tagged divergence) after it has actually been closed by a Debian-specific patch. As upstream it might make a fair bit of sense but as a user / bug submitter, it will just look odd. Would your opinion be different if the bug was fixed but not closed nor archived, until the divergence tag is gone? I think that would be fine - as long as the bug is clearly Fixed and the relevant Debian www pages are updated. A user reporting a bug in foo should not still be wondering why the bug is open after the fix has been applied. Isn't that a matter easily resolved by presenting the bug information appropriately in the interface? 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. -- 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
On Sat, May 17, 2008, Joey Hess wrote: If I grab an upstream change from their VCS, I wont open a Debian bug about it; if I find a bug in the Debian version which also applies to upstream, I might skip to directly reporting it upstream, and only there. If you grab a patch from 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 if you're somehow wrong, knowing that QA tools will flag that.) Just as, if you see a bug filed in the upstream BTS, you don't need to file it in our BTS. In both cases, the package in Debian *has* a bug, even if it's counterproductive to file it in the BTS. So has the maintainer to decide whether to file a divergence bug? What about divergences which upstream doesn't like or which are only useful to Debian and would be hard or useless to render generic? A change is a change, not a bug; we don't need to map each change to a bug. We could get better at distinguishing between changes, and perhaps we can reach a point where we can extract a list of logical changes (or changesets) between Debian uploads, or between the Debian and upstream versions, but I don't think we want bugs for that. The point of having bug reports is not for change tracking, but for communication. We've long established that we want maintainers to tell upstream about what changes they make. Using the BTS just exposes this communication to the world and allows querying it and noticing when it's not being done, or when upstream is ignoring it. Concerning communication, I think we should make our patches easy to extract and browse. Another helpful solution is the PTS: I know some upstreams actively commenting on Debian uploads despite not using Debian (but I don't know many). I do see your point that the BTS can store emails, URLs, files etc., but I don't like diverting the use of this tool for this use case; I'd be more happy with a separate tool. Another route could be to ask maintainers to expose divergences at the source level; perhaps we can standardize a format to extract a stack of patches with descriptions (whatever format is used to store the Debian source), and a command (or debian/rules target) to trigger this output? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream communication
processing which brings even more complexity to the scene).
How is the Debian BTS another place to look at? It's already an
essential place to look for information about what changes are made in
a Debian package.
In the world of diversion, there should be a single point of
unification one can safely return to.
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.
If we want to work this idea, we have two ways: either starting a
centralized _common to everyone_ place where all downstreams share their
experience, patches, and so on, and everyone can track wrt _his own_
packaging versions that has or doesn't have the patch (upstream would
just be another layer of that sort FWIW), or we go the decentralized
way.
The former is what launchpad somehow trie{s,d} to do, without the
multiple versionning layers afaict (but I may be wrong, I never really
used it, and that's not the point). Given how mitigated the results of
it are, I'm unsure if it's the way to go (and I don't think the oh
launchpad is closed source, it's bad mojo argument is the real reason
why we don't see everyone using launchpad 3 or 4 years after it was
started).
The other way is to provide some glue between all the issue trackers
out there, so that every issue tracker is a source in a giant
bug/patch/content tracking middleware. There are people working on that
afaict (or at least trying to design such tools). This is way better,
and allow upstreams to keep their beloved tool, while we can see
everyone collaborate on bugs, and fetch patches, updates, whatever from
multiple sources (a bit like distributed VCSs work: you have multiple
bug sources you pull from, to create a comprehensive tool in the end).
But the BTS is nowhere near that.
FWIW I've been convinced from a long time that the latter is the way
to go. I've discussed with people trying to design such distributed
BTSes in the past a lot, and bts-link was at the beginning aimed as a
step in that direction too (even if it's not, as I wanted it to be an
_actual_ tool and not vapourware).
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgp3CRHGZqoKo.pgp
Description: PGP signature
Re: divergence from upstream as a bug
Please follow URL:http://www.debian.org/MailingLists#codeofconduct and avoid sending messages individually to someone when the message is also sent to the list, unless they ask for it. Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote: The 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. -- \Program testing can be a very effective way to show the | `\presence of bugs, but is hopelessly inadequate for showing | _o__) their absence. —Edsger W. Dijkstra | 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 [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
On Sunday 18 May 2008, Ben Finney wrote: Please follow URL:http://www.debian.org/MailingLists#codeofconduct and avoid sending messages individually to someone when the message is also sent to the list, unless they ask for it. Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, May 18, 2008 at 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 people.fccf.net/danchev/key pgp.mit.edu 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
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote: Please follow URL:http://www.debian.org/MailingLists#codeofconduct and avoid sending messages individually to someone when the message is also sent to the list, unless they ask for it. … Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, May 18, 2008 at 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. That's why the proposal is bad. It doesn't improve that, and it requires more work from the maintainer. Lose/lose situation. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmtA0sgq1wU.pgp Description: PGP signature
Re: divergence from upstream as a bug
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
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
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
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
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
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
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
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
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
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
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 people.fccf.net/danchev/key pgp.mit.edu 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
* 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 [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
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
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
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
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
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
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
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
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
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
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
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
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]) http://www.eyrie.org/~eagle/ -- 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 [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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
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
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]
Mailing lsit code of conduct, again (was: divergence from upstream as a bug)
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
* 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]
Re: divergence from upstream as a bug
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 [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
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
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
* 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
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
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
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
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 version tracking in patches.d.o but also add that and the BTS to the places upstream should look for patches? No need to duplicate version tracking. We can just export patches for the versions in stable/testing/unstable. Yes, I would add patches.debian.org to the places where upstream should look for patches. But that would be the only place where upstream should look for patches (unless upstream really wants to follow Debian closely, which is not the general case), and upstream would have the guarantee that all Debian modifications to his package are listed on patches.debian.org. Instead of that, you are saying to upstream: Well, our patches
Re: divergence from upstream as a bug
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
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 good at presenting modifications if you know how to use it.
Re: divergence from upstream as a bug
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 those who choose not to use (Fixes: #), it simply helps those of us who want to track
Re: divergence from upstream as a bug
* 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
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]
Which problem are we trying to solve? (Was: divergence from upstream as a bug)
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: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
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
Re: Mailing lsit code of conduct, again (was: divergence from upstream as a bug)
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: divergence from upstream as a bug
* 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: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
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 out, I need to build the
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
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]
