Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
Hi Don, On Mon, 14 Jul 2008 22:11:23 -0700, Don Armstrong wrote: It's your decision, but are you sure that you want to take on the repsonsibility of maintaining a development release of lynx throughout a stable release cycle instead of the stable release of lynx? Yes, it is not something like -snapshot but, at least recently, it is what you guessed as alternative possibiliry; An alternative possibility exists that the -cur release is actually the version that upstream plans on having long-term support for, and the lynx version is just for legacy users, but the bug thread (which I read) doesn't make this point clear. So, from the same reason, I can't speak for the security team, but I'd be rather suprised if they'd be willing to support a development version in favor of a stable version of lynx. it will be easier for our security team to support lynx-cur than a stable lynx. Regards,2008-7-15(Tue) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
On Tue, 15 Jul 2008, Atsuhito Kohda wrote: On Mon, 14 Jul 2008 22:11:23 -0700, Don Armstrong wrote: It's your decision, but are you sure that you want to take on the repsonsibility of maintaining a development release of lynx throughout a stable release cycle instead of the stable release of lynx? Yes, it is not something like -snapshot but, at least recently, it is what you guessed as alternative possibiliry; An alternative possibility exists that the -cur release is actually the version that upstream plans on having long-term support for, and the lynx version is just for legacy users, but the bug thread (which I read) doesn't make this point clear. This certainly doesn't match up with the information that's available on their website, especially considering that 2.8.6 is their release version, they're iterating new development releases every 3-6 months which will eventually be released at 2.9 or 2.8.7. So, from the same reason, I can't speak for the security team, but I'd be rather suprised if they'd be willing to support a development version in favor of a stable version of lynx. it will be easier for our security team to support lynx-cur than a stable lynx. So whatever development version we release with you'll be putting in the effort to backport patches to it, even if we're the only distribution who happens to be distributing that release, and you're willing to track it for a full release cycle? (Three years?) Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
On Tue, 15 Jul 2008 00:01:17 -0700, Don Armstrong wrote: This certainly doesn't match up with the information that's available on their website, especially considering that 2.8.6 is their release version, they're iterating new development releases every 3-6 months which will eventually be released at 2.9 or 2.8.7. Hmm, not a weekly-release. So whatever development version we release with you'll be putting in the effort to backport patches to it, even if we're the only distribution who happens to be distributing that release, and you're willing to track it for a full release cycle? (Three years?) In the first place, as a volunteer, there is no warranty. I'm not sure what you mean but it seems lynx in Debian/etch is of 2.8.5 but it is of 2.8.6 in Gentoo, OpenSuse as I checked on my VirtualBox. It is not so much sense to argue possibility but I'm afraid Debian's release period is generally so long that the possibility you mentioned could happen more likely with a stable version. Regards,2008-7-15(Tue) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
On Tue, 15 Jul 2008, Atsuhito Kohda wrote: On Tue, 15 Jul 2008 00:01:17 -0700, Don Armstrong wrote: This certainly doesn't match up with the information that's available on their website, especially considering that 2.8.6 is their release version, they're iterating new development releases every 3-6 months which will eventually be released at 2.9 or 2.8.7. Hmm, not a weekly-release. Right. So whatever development version we release with you'll be putting in the effort to backport patches to it, even if we're the only distribution who happens to be distributing that release, and you're willing to track it for a full release cycle? (Three years?) In the first place, as a volunteer, there is no warranty. Right. I'm not sure what you mean but it seems lynx in Debian/etch is of 2.8.5 but it is of 2.8.6 in Gentoo, OpenSuse as I checked on my VirtualBox. Yeah, I definetly agree that we should be releasing 2.8.6, not the old version of lynx that we were. It is not so much sense to argue possibility but I'm afraid Debian's release period is generally so long that the possibility you mentioned could happen more likely with a stable version. That's your call to make, possibly with the consultation of the stable security team. If it were me, I'd personally be very nervous about having to support a development version that no other distribution would be using, and that upstream never actually released as a stable release. I'd have to carefully weigh the frequency of security vulnerabilities with the time necessary to backport the security fix from the upstream development code against my time availability in the future. I cloned and reopened this bug primarily because it wasn't obvious that the above had been done, and the log didn't spell this out; the few things in the log also didn't mesh with the information that was in the upstream web pages. [Though I didn't check with upstream themselves, so.] Anyway, feel free to close this bug report if you feel that the above has been weighed, and that you've contemplated the concerns that I have. Don Armstrong -- Dropping non-free would set us back at least, what, 300 packages? It'd take MONTHS to make up the difference, and meanwhile Debian users will be fleeing to SLACKWARE. And what about SHAREHOLDER VALUE? -- Matt Zimmerman in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
submitter 490265 ! reopen 490265 found 490265 2.8.7dev9-1.1 thanks On Fri, 11 Jul 2008, Andreas Metzler wrote: On 2008-07-11 Don Armstrong [EMAIL PROTECTED] wrote: clone 369386 -1 retitle -1 lynx-cur should be called lynx; ditch lynx transition package severity -1 important thanks Why is this important? It looks like a purely cosmetical question. (minor or wishlist.) Because it's something that should be resolved prior to release, and probably should even be RC. It certainly isn't the kind of breakage that should be introduced in an NMU. On Sat, 28 Jun 2008, Andreas Metzler wrote: We end up with a dummy package lynx that depends on lynx-cur. (I think we should keep it permanently.) It should work correctly, lynx configuration files are handled as good as possible on upgrades: - if they are not modified locally thy are simply removed. - Otherwise they are moved to /etc/lynx-cur/ *unless* the config files in _that_ directory already exist. Why do we need a lynx transition package which depends on a lynx-cur package instead of just having a single lynx package? We can either have a lynx package and a lynx-cur transition package or the other way round if we want to provide upgrade path for users of both packages. We definetly don't need to release with the lynx-cur transition package, since we've never released with it.[1] Furthermore, by switching to lynx-cur, you instantly break local configurations in /etc/lynx for no real gain. I chose the latter in the NMU since there did not seem to be a strong preference for either by the lynx or the lynx-cur maintainer. Upgrading the lynx package to use 2.8.7dev9 sources would have been a lot more disruptive, requiring bigger changes than providing a lynx transtion package. (Mainly due to the existence of lynx-cur-wrapper.) Not a thing to be done in a NMU imho. And I do not want to adopt/hijack/maintain it. By uploading a lynx binary package which was a transition, you *did* effectively hijack the lynx package, whether you meant to or not. It's certainly not Kohda's responsibility to deal with any of the breakage resulting. This is the sort of change that should not be made in an NMU without the explicit blessing of the maintainer of both packages concerned unless you plan on hijacking, adopting, or being seriously involved in the maintenance of both. At the same time that such an upload is made, a request for removal of the lynx-cur or lynx package should also have been made, coupled with the triaging and possible reassignment of lynx-cur or lynx bugs to the new set of binary packages. Don Armstrong 1: Transitioning in unstable would be nice, but it's certainly not required, and could easily be handled by a tiny source stub package which did not transition. -- J.W. Grant: Bastard! Rico: Yes, Sir. In my case, an accident of birth. But you, Sir, you're a self-made man. -- Henry Rico Fardan in The Professionals http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
Hi Don and Andreas, On Mon, 14 Jul 2008 17:55:42 -0700, Don Armstrong wrote: Why is this important? It looks like a purely cosmetical question. (minor or wishlist.) Because it's something that should be resolved prior to release, and probably should even be RC. It certainly isn't the kind of breakage that should be introduced in an NMU. I don't know it is acceptable for you or not but, personally, I prefer lynx-cur because there are two branches of lynx in the upstream and the development version is called lynx-cur by the upstream. The name lynx-cur explicitly expresses that it is the developement version instead of stable version. By uploading a lynx binary package which was a transition, you *did* effectively hijack the lynx package, whether you meant to or not. It's certainly not Kohda's responsibility to deal with any of the breakage resulting. I suspect Andreas might only respect my desire. Don, I don't know how you read this thread carefully or not and it is rather difficult for me to explain full story in short but, at least, I accept Andreas' NMU with pleasure. Further, it is an examination period in Univ. of Japan and untill the middle of August, I'll have almost no time to maintain the package. This is the sort of change that should not be made in an NMU without the explicit blessing of the maintainer of both packages concerned unless you plan on hijacking, adopting, or being seriously involved in the maintenance of both. I think Andreas is seriously involved in the the maintenance of both, much more seriously than the present maintainers. (sorry on my part, but as I explained above.) At the same time that such an upload is made, a request for removal of the lynx-cur or lynx package should also have been made, coupled with the triaging and possible reassignment of lynx-cur or lynx bugs to the new set of binary packages. But I think the situation looks too ambiguous yet. Regards,2008-7-15(Tue) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
On Tue, 15 Jul 2008, Atsuhito Kohda wrote: On Mon, 14 Jul 2008 17:55:42 -0700, Don Armstrong wrote: Why is this important? It looks like a purely cosmetical question. (minor or wishlist.) Because it's something that should be resolved prior to release, and probably should even be RC. It certainly isn't the kind of breakage that should be introduced in an NMU. I don't know it is acceptable for you or not but, personally, I prefer lynx-cur because there are two branches of lynx in the upstream and the development version is called lynx-cur by the upstream. The name lynx-cur explicitly expresses that it is the developement version instead of stable version. It's your decision, but are you sure that you want to take on the repsonsibility of maintaining a development release of lynx throughout a stable release cycle instead of the stable release of lynx? I can't speak for the security team, but I'd be rather suprised if they'd be willing to support a development version in favor of a stable version of lynx. From where I sit, it seems like the wrong solution to #369386 was reached; lynx-cur should have an RC bug against it, but that RC bug should exist only to keep lynx-cur to transition to testing and then being released. A second lynx package should exist which is the most recent stable release of the lynx tree. [This situtation already exists for numerous -snapshot packages which should never be released with a Debian stable release.] An alternative possibility exists that the -cur release is actually the version that upstream plans on having long-term support for, and the lynx version is just for legacy users, but the bug thread (which I read) doesn't make this point clear. Don Armstrong -- NASCAR is a Yankee conspiracy to keep you all placated so the South won't rise again. -- http://www.questionablecontent.net/view.php?comic=327 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490265: Bug#369386: Patch for rc-bugs in lynx-cur
On 2008-07-11 Don Armstrong [EMAIL PROTECTED] wrote: clone 369386 -1 retitle -1 lynx-cur should be called lynx; ditch lynx transition package severity -1 important thanks Why is this important? It looks like a purely cosmetical question. (minor or wishlist.) On Sat, 28 Jun 2008, Andreas Metzler wrote: We end up with a dummy package lynx that depends on lynx-cur. (I think we should keep it permanently.) It should work correctly, lynx configuration files are handled as good as possible on upgrades: - if they are not modified locally thy are simply removed. - Otherwise they are moved to /etc/lynx-cur/ *unless* the config files in _that_ directory already exist. Why do we need a lynx transition package which depends on a lynx-cur package instead of just having a single lynx package? We can either have a lynx package and a lynx-cur transition package or the other way round if we want to provide upgrade path for users of both packages. I chose the latter in the NMU since there did not seem to be a strong preference for either by the lynx or the lynx-cur maintainer. Upgrading the lynx package to use 2.8.7dev9 sources would have been a lot more disruptive, requiring bigger changes than providing a lynx transtion package. (Mainly due to the existence of lynx-cur-wrapper.) Not a thing to be done in a NMU imho. And I do not want to adopt/hijack/maintain it. Clearly we're not going to have another lynx package, and having lynx-cur when we've never made a release of it seems silly. Furthermore, the debconf prompt about the /etc/lynx configuration file is just useless. Indeed, that's #489485. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
