On onsdagen den 6 mars 2013, Neil McGovern wrote:
On Wed, Mar 06, 2013 at 08:04:45AM +0100, intrigeri wrote:
C. Not shipping pike7.8 in Wheezy.
I'm very much in doubt what the best course of action for Wheezy is, but I'm a bit tempted to recommend C based on the information I have.
Agreed, removal hint added.
So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were "rather serious". Can you help me elaborate on that? (pike-jira.lysator.liu.se seems rather down at the moment.) Certainly 7.8.352 is better than nothing at all?
On Sun, Mar 10, 2013 at 03:52:23PM +0100, Magnus Holmgren wrote:
C. Not shipping pike7.8 in Wheezy.
I'm very much in doubt what the best course of action for Wheezy is, but I'm a bit tempted to recommend C based on the information I have.
Agreed, removal hint added.
So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were "rather serious". Can you help me elaborate on that? (pike-jira.lysator.liu.se seems rather down at the moment.) Certainly 7.8.352 is better than nothing at all?
well, if there are not enough debian users, what does it matter to them? sure it matters to us because we want pike easely available, but that's hardly an argument.
can you try referencing the release-notes on the nature of the bugs? which serious bugs have been fixed?
btw: for anyone interested i located the message quoted above: http://lists.debian.org/debian-release/2013/03/msg00277.html
the question here is: what information would they need in order to choose a or b?
if there are only few users is the risk of regressions more serious than not shipping pike at all? which will hurt users more? wouldn't dropping pike be the worst of all choices? i'd certainly call it a regression to pre-squeeze days.
unfortunately myself i am not really using debian anymore so i can't argue from an active user perspective.
would it help to have a maintainer team to prevent this from happening again?
i have been thinking about the idea of forming a team that includes all distributions, and as a team we'd maintain packages for debian, foresight, gentoo, osx and possibly also fedora, arch and others. i think most packaging problems are similar across distributions, so being one team we could help and support each other.
greetings, martin.
I for one would appreciate if pike were available in the Debian repo.
I seem to use debian derivates everywhere at the moment...
On Sun, Mar 10, 2013 at 03:40:01PM +0000, Mirar @ Pike developers forum wrote:
I for one would appreciate if pike were available in the Debian repo. I seem to use debian derivates everywhere at the moment...
could the new version go into debian-backports instead? backports have just been added to the main debian archive, so they are as official as anything else, and as a debian user that would be enough for me.
greetings, martin.
On Mon, Mar 11, 2013 at 2:31 AM, Martin Bähr mbaehr@email.archlab.tuwien.ac.at wrote:
if there are only few users is the risk of regressions more serious than not shipping pike at all? which will hurt users more? wouldn't dropping pike be the worst of all choices? i'd certainly call it a regression to pre-squeeze days.
I use Debian, and have one of my boxes on Wheezy. But I don't use Pike from the repo, because I prefer to run 7.9.5 straight from git, so popcon won't register me as a Pike user. The last time I apt-getted (apt-got?) a Pike was on an Ubuntu system that had only 7.6; after that, I just started building from source, and never went back to look in the repo.
Is there any chance to get 7.8.700 into sid now, and give it enough time for testing/unstable before Wheezy gets released? Or is it too late for that?
ChrisA
Magnus Holmgren wrote:
On onsdagen den 6 mars 2013, Neil McGovern wrote: So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were "rather serious". Can you help me elaborate on that? (pike-jira.lysator.liu.se seems rather down at the moment.) Certainly 7.8.352 is better than nothing at
Browsing through the commitlogs since Sep 22nd 2009 (=7.8.352) I don't see any obvious security leaks being fixed. So the question indeed is, what is considered "rather serious" ? I'd say having 7.8.352 ok, having 7.8.700 is better, but when 7.8.700 is not (yet) available, having 7.8.352 is good enough.
Which begs another question: why is 7.8.700 not being considered in the first place? I can only imagine that it is a drop-in replacement for 7.8.352 and therefore a nobrainer to update the package.
On Tue, Mar 12, 2013 at 10:09:59PM +0100, Stephen R. van den Berg wrote:
Which begs another question: why is 7.8.700 not being considered in the first place? I can only imagine that it is a drop-in replacement for 7.8.352 and therefore a nobrainer to update the package.
it wasn't available before the freeze for the next release. after that point updates are only allowed in in exceptional cases which will be carefully reviewed.
dropping in 7.8.700 is not a no-brainer because there might be regressions, and there is no more time to test for them.
and note that just being stable upstream is not good enough, it needs to be verivied to be stable running on debian without breaking anything else.
now for a programming language that no other package depends on this is mostly a no-brainer still, but any exception on the rules opens the door for others wanting exceptions too, slowing down the release as it is.
greetings, martin.
Magnus Holmgren wrote:
On onsdagen den 6 mars 2013, Neil McGovern wrote: So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were "rather serious". Can you help me elaborate on that? (pike-jira.lysator.liu.se seems rather down at the moment.) Certainly 7.8.352 is better than nothing at
Browsing through the commitlogs since Sep 22nd 2009 (=7.8.352) I don't see any obvious security leaks being fixed.
Neither do I. There's the SSL renegotiation stuff, that might be considered a security problem, but it apparently didn't work anyway...
So the question indeed is, what is considered "rather serious" ?
There were a NULL-deref or two fixed and a couple of memory leaks, which I'd consider serious, but not a showstopper.
I'd say having 7.8.352 ok, having 7.8.700 is better, but when 7.8.700 is not (yet) available, having 7.8.352 is good enough.
That's my opinion as well.
Which begs another question: why is 7.8.700 not being considered in the first place? I can only imagine that it is a drop-in replacement for 7.8.352 and therefore a nobrainer to update the package.
We aim for backward compatibility, though I see that we changed the directory for installed modules to reflect the ABI in one of the early commits after 7.8.352 this was to fix a complaint by the Gentoo installer. This might affect the OS packaging system, but any Pike programs that care about where the modules are installed should query the master anyway.
I don't know of any Pike programs that work in 7.8.352, but fail with 7.8.700, that aren't broken to begin with (ie the 7.8.700 compiler might detect logic errors that the 7.8.352 compiler didn't, but these would cause runtime errors there instead).
/grubba
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Magnus Holmgren -
Martin Baehr -
Martin Bähr
-
Mirar ＠ Pike developers forum
-
Stephen R. van den Berg