Sent from my MetroPCS 4G LTE Android device
On Fri, 2013-04-05 at 13:09:51 +0100, Ian Jackson wrote:
Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required
rebuilds of all reverse Depends: of R)):
Well, I strongly disagree that in general using epochs for packaging
mistakes is a good practice (and I've thought so
On Fri, Apr 19, 2013 at 12:16:11PM +0300, Niko Tyni wrote:
On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote:
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
Niko Tyni nt...@debian.org writes:
FWIW, I've done ABI-incompatible uploads of perl to
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote:
Oh, that's a good point. Yes, I hadn't thought about that specific case
for testing ABI breakage in experimental.
But then that simply is a broken upload. It will
On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote:
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote:
Oh, that's a good point. Yes, I hadn't thought about that specific case
for testing ABI breakage in
On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote:
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
Niko Tyni nt...@debian.org writes:
FWIW, I've done ABI-incompatible uploads of perl to experimental in the
past without changing the perlapi-* virtual
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote:
Oh, that's a good point. Yes, I hadn't thought about that specific case
for testing ABI breakage in experimental.
But then that simply is a broken upload. It will break horribly if you
install the experimental perl but keep other
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote:
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote:
Actually that hits another problem. Namely that the epoch does not
appear in the binary package filename. While wheezy would have 1.2.3-1
and unstable would have 1:1.2.3-1
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
Niko Tyni nt...@debian.org writes:
FWIW, I've done ABI-incompatible uploads of perl to experimental in the
past without changing the perlapi-* virtual package name or the libperl
SONAME. The aim was to experiment with
On 2013-04-18 10:48 +0200, Goswin von Brederlow wrote:
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote:
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote:
Actually that hits another problem. Namely that the epoch does not
appear in the binary package filename. While wheezy
On 04/18/2013 10:48, Goswin von Brederlow wrote:
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote:
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote:
Actually that hits another problem. Namely that the epoch does not
appear in the binary package filename. While wheezy would have
On Thu, Apr 18, 2013 at 11:04:11AM +0200, Ansgar Burchardt wrote:
On 04/18/2013 10:48, Goswin von Brederlow wrote:
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote:
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote:
Actually that hits another problem. Namely that the epoch
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote:
Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit :
Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4)
or you could have an API virtual package:
r-base-api-3.0
Hi Dirk and everybody,
On 2013-04-04 21:08:45 +0200, Philipp Kern wrote:
On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote:
I wonder whether there are packaged extensions […]
So you didn't actually look. EOT from me, it's wasting my time.
Sorry, I meant why instead of whether. As I've said in my
On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote:
So, transitions could be avoided in a social way. No need for a freeze.
Let's see how well that works - look at the very first message in this
thread.
Neil
--
signature.asc
Description: Digital signature
On 2013-04-15 15:31:38 +0100, Neil McGovern wrote:
On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote:
So, transitions could be avoided in a social way. No need for a freeze.
Let's see how well that works - look at the very first message in this
thread.
My point is that:
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote:
Actually that hits another problem. Namely that the epoch does not
appear in the binary package filename. While wheezy would have 1.2.3-1
and unstable would have 1:1.2.3-1 they both produce the same
foo_1.2.3-1_amd64.deb. But for certain the
Holger Levsen wrote:
On Montag, 1. April 2013, Steve M. Robbins wrote:
Rather than accept the harm, surely the release team could simply roll
back the upload in some manner?
As I understand it, only by introducing an epoch in the package version.
Or by using the 9.0.0+really0.99-1 version
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote:
I like the idea of an api virtual package, as it requires little work from the
parties involved and solves most of the problem.
I do not only like this but IMHO it is perfectly needed (as for any
other language system we are
On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote:
A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual
according the the release plan and announcements [1].
It contains major internal changes [2] and requires rebuilds of all R
packages. As I usually
Le Fri, Apr 05, 2013 at 08:53:52AM +0100, Julian Gilbey a écrit :
On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote:
I am a little unclear what is required; is a binary rebuild
sufficient, or is some change in the source code necessary? If the
former, would it not be better
Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required
rebuilds of all reverse Depends: of R)):
Well, I strongly disagree that in general using epochs for packaging
mistakes is a good practice (and I've thought so even before Ubuntu
existed). The main purpose of epochs
Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit :
Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4)
or you could have an API virtual package:
r-base-api-3.0
Hi Dirk and everybody,
since we already have a substitution variable in most of the R packages
]] Vincent Lefevre
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote:
Just to expand slightly on this, the problem you're both poking at is
that during a freeze, our incentives are directed towards fixing RC bugs
(because then we can release, which means we can then do what we prefer
On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote:
It seems that most reverse dependencies for iceweasel are l10n
packages and extensions, so that one can consider them as part
of the upgrade. The remaining dependencies seem to have a form
like iceweasel | www-browser. So, what
On 2013-04-04 16:23:33 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote:
It seems that most reverse dependencies for iceweasel are l10n
packages and extensions, so that one can consider them as part
of the upgrade. The remaining dependencies seem to
On Wed, 2013-04-03 at 20:18:44 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote:
On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote:
And not, we do not have epochs to temporarily downgrade a package
after a botched upload.
c.f.
On Thu, Apr 04, 2013 at 08:09:27PM +0200, Guillem Jover wrote:
Also as it can be seen on the archive, once
a version has been tainted (!?), uploaders tend to lower their
resistance to increase the epoch even further.
But once an epoch has been added, there is (arguably?) no problems with
On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote:
I wonder whether there are packaged extensions […]
So you didn't actually look. EOT from me, it's wasting my time.
Multiple transitions then get entangled.
I don't understand what you mean here. The freeze doesn't prevent
that
On Fri, Apr 05, 2013 at 01:00:52AM +0600, Andrey Rahmatullin wrote:
But once an epoch has been added, there is (arguably?) no problems with
increasing it further.
You're not really increasing ugliness in that case, but you are
still screwing with any extant versioned relationships.
--
To
On 2013-04-02 13:37:59 -0500, Peter Samuelson wrote:
[Vincent Lefevre]
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed, there would be (almost) no delay. I suspect that the
length of the freeze is due to the fact that the freeze occurred
while too many RC bugs
On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote:
And not, we do not have epochs to temporarily downgrade a package
after a botched upload.
c.f. imagemagick
I'm pretty sure we do.
It seems we usually upload a 2really1 package to fix that particular
mistake without introducing
On Tue, 2013-04-02 at 17:24 +0100, Adam D. Barratt wrote:
On 02.04.2013 16:35, Svante Signell wrote:
The best solution would be having unstable _never_ frozen, at the
cost
of another repository during the freeze period. This was proposed
some
time ago, see
On 2013-04-02 09:50:23 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
There are various problems with experimental, in particular dependencies
are not necessarily listed,
Huh? I have no clue what you could possibly be talking about, unless
you're just saying that
On 2013-04-02 21:53:08 +0200, Philipp Kern wrote:
Vincent,
am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben:
I don't think that the status even of a big package like iceweasel
is satisfactory.
I pretty much agree. But what's the problem here? That xulrunner and
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
That is not how it actually works out. Policy changes are made which
require old packages to build with new flags, compilers and toolchain
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote:
Just to expand slightly on this, the problem you're both poking at is
that during a freeze, our incentives are directed towards fixing RC bugs
(because then we can release, which means we can then do what we prefer
to, which (as you can see
On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote:
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote:
Just to expand slightly on this, the problem you're both poking at is
that during a freeze, our incentives are directed towards fixing RC bugs
(because then we can release,
On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote:
I pretty much agree. But what's the problem here? That xulrunner and
iceweasel have rdeps in the archive that aren't necessarily
compatible with a new version of iceweasel and hence introducing yet
another transition whenever
On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote:
On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote:
And not, we do not have epochs to temporarily downgrade a package
after a botched upload.
c.f. imagemagick
I'm pretty sure we do.
It seems we usually upload
On 2013-04-03 20:14:32 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote:
In general, bug-fix releases (which are also blocked by the freeze)
don't introduce new bugs.
Case in point:
On 2013-04-03 20:17:47 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote:
I pretty much agree. But what's the problem here? That xulrunner and
iceweasel have rdeps in the archive that aren't necessarily
compatible with a new version of iceweasel
On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote:
When I said peripheral I meant in the sense that none of the Depends are
used by anything else beyond R. I know it is not small -- there are now
4400 R packages on CRAN, and we have about 150 of those in Debian.
I think it must
Le 02/04/2013 08:40, Jukka Ruohonen a écrit :
On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote:
When I said peripheral I meant in the sense that none of the Depends are
used by anything else beyond R. I know it is not small -- there are now
4400 R packages on CRAN, and we have
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote:
IMO it's important to remember that it's fundamentally the release team
that is at fault for problems here, not the R maintainer.
Can you please remind me what you do for Debian? Aside from flame debian-devel.
I've forgotten.
On Mon, Apr 01, 2013 at 12:15:17AM +0200, Arno Töll wrote:
So help speeding up the release process.
The universal rebuttal to all complaints about the release process. Sadly
it misses the point at the heart of most complaints: far too much work is
needed to become release-ready, and there is not
On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote:
I don't think the time for this discussion is now, so I'll restrain
myself from saying more. The release is near, and there's going to
be plenty of time until the next freeze :)
When the pain of the freeze will be a fast-fading
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
You seem to believe that unstable is more important than stable
releases. I do not. One of us is in the wrong project.
If, you are suggesting here, that the release process in Debian is utterly
set in stone and nobody may raise
Le mardi 02 avril 2013 à 09:15 +0100, Jonathan Dowland a écrit :
The universal rebuttal to all complaints about the release process. Sadly
it misses the point at the heart of most complaints: far too much work is
needed to become release-ready, and there is not enough resource to do it.
On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
The length of the freeze is not the fault of the release team.
The length of the freeze is down to all of the contributors to Debian
not fixing enough RC bugs - I count myself in that, I've managed to get
massively less done for this release
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote:
This is indeed Debian’s problem and needs discussion, but the roots lie
in upstreams. It mostly comes down to the fact that upstreams of a
growing number of projects are not able to synchronize their releases so
that a single set of
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
The length of the freeze is not the fault of the release team.
The length of the freeze is down to all of the contributors to Debian
not fixing enough RC bugs - I count myself
On 02.04.2013 13:52, Vincent Lefevre wrote:
I suspect that the
length of the freeze is due to the fact that the freeze occurred
while too many RC bugs were already open.
If so, there was a good reason for that (i.e. pre-announced time-based
freeze). As others have said (although ymmv) I don't
On Tue, 2 Apr 2013 14:52:35 +0200
Vincent Lefevre vinc...@vinc17.net wrote:
On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
The length of the freeze is not the fault of the release team.
The length of the freeze is down to all of the contributors to Debian
not fixing enough RC bugs -
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed,
Problem is: until you freeze, new RC bugs keep getting introduced.
But I would say, not many. Or
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote:
On Mon, 1 Apr 2013 17:42:29 +0600
Andrey Rahmatullin w...@wrar.name wrote:
On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
Thanks for trading the R release cycle with Debian's and for
delaying the
On Tue, 2 Apr 2013 15:09:33 +0200
Vincent Lefevre vinc...@vinc17.net wrote:
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote:
This is indeed Debian’s problem and needs discussion, but the roots lie
in upstreams. It mostly comes down to the fact that upstreams of a
growing number of
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit :
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed,
Problem is: until you freeze,
On Tue, 2 Apr 2013 15:15:38 +0200
Vincent Lefevre vinc...@vinc17.net wrote:
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed,
Problem is:
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
Having latest upstream versions easily available to users is important
for the development of many projects,
That's what experimental is for.
There are various problems with
On 2013-04-02 14:17:17 +0100, Neil Williams wrote:
The release happens when (almost) all RC bugs are fixed, the freeze is
to allow the existing bugs to be fixed whilst *protecting* the other
packages from breakage caused by new software being uploaded.
You can still fix bugs while new software
On 2013-04-02 15:23:18 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit :
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
That is not how it actually works out. Policy changes are made which
require old packages to build with new flags, compilers and toolchain
packages get upgraded and introduce new failure modes, QA tools improve
and catch more corner cases.
Vincent Lefevre, le Tue 02 Apr 2013 17:20:52 +0200, a écrit :
This is also due to the fact that more people are working on fixing RC
bugs *now* instead of doing that before.
Which is one of the goals of freezing.
I'm just tired of argumenting over something that was already
discussed. Let's
On Tue, 2013-04-02 at 16:29 +0200, Vincent Lefevre wrote:
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
Having latest upstream versions easily available to users is important
for the development of many projects,
That's
On 02.04.2013 16:35, Svante Signell wrote:
The best solution would be having unstable _never_ frozen, at the
cost
of another repository during the freeze period. This was proposed
some
time ago, see
http://lists.debian.org/debian-devel/2013/01/msg00273.html
repeated here for convenience:
On Tue, 02 Apr 2013, Jukka Ruohonen wrote:
On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote:
When I said peripheral I meant in the sense that none of the Depends are
used by anything else beyond R. I know it is not small -- there are now
4400 R packages on CRAN, and we have
Jonathan Dowland j...@debian.org writes:
On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote:
I don't think the time for this discussion is now, so I'll restrain
myself from saying more. The release is near, and there's going to be
plenty of time until the next freeze :)
When
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
That is not how it actually works out. Policy changes are made which
require old packages to build with new flags, compilers and toolchain
packages get upgraded and introduce new failure modes, QA
Vincent Lefevre vinc...@vinc17.net writes:
There are various problems with experimental, in particular dependencies
are not necessarily listed,
Huh? I have no clue what you could possibly be talking about, unless
you're just saying that some packages in experimental are critically
buggy.
[Jonathan Dowland]
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
You seem to believe that unstable is more important than stable
releases. I do not. One of us is in the wrong project.
If, you are suggesting here, that the release process in Debian is utterly
set in stone
[Vincent Lefevre]
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed, there would be (almost) no delay. I suspect that the
length of the freeze is due to the fact that the freeze occurred
while too many RC bugs were already open.
Agreed: in July 2012, many - too
]] Russ Allbery
and this doesn't prevent developers from fixing RC bugs.
Nothing prevents developers from fixing RC bugs at any time. They just
don't in sufficient numbers to keep ahead of the incoming rate except
during a freeze, both because the freeze drops the incoming rate (by,
Vincent,
am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben:
I don't think that the status even of a big package like iceweasel
is satisfactory.
I pretty much agree. But what's the problem here? That xulrunner and iceweasel
have rdeps in the archive that aren't necessarily
Goswin,
am Tue, Apr 02, 2013 at 03:18:24PM +0200 hast du folgendes geschrieben:
And not, we do not have epochs to temporarily downgrade a package
after a botched upload.
c.f. imagemagick
I'm pretty sure we do.
SCNR
Philipp Kern
signature.asc
Description: Digital signature
On Tue, Apr 02, 2013 at 09:50:23AM -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
and upgrade from an experimental package is not supported (it generally
works, but the maintainer doesn't have to take that into account).
This is a bizarre statement to me. Why
Niko Tyni nt...@debian.org writes:
FWIW, I've done ABI-incompatible uploads of perl to experimental in the
past without changing the perlapi-* virtual package name or the libperl
SONAME. The aim was to experiment with different configuration options,
particularly 64-bit integers and 128-bit
On Mon, Apr 01, 2013 at 05:23:08AM +0600, Andrey Rahmatullin wrote:
And even a month ago [1] there were no RC bugs that could be helped with
by a random contributor, and that was the case for some time already.
So I think it is unfair to say that random contributors are responsible
for the
Hi,
On Montag, 1. April 2013, Steve M. Robbins wrote:
Rather than accept the harm, surely the release team could simply roll
back the upload in some manner?
As I understand it, only by introducing an epoch in the package version.
Which, understandably, is often frowned upon as an epoch never
On Sun, 31 Mar 2013 17:45:15 -0500
Dirk Eddelbuettel e...@debian.org wrote:
On 1 April 2013 at 00:16, Josselin Mouette wrote:
| I don’t understand how you can say it “worked before”.
| Let’s say you backport a R package from wheezy to squeeze (something we
| tried recently at work). The new R
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
Thanks for trading the R release cycle with Debian's and for
delaying the release. The harm has already been done, so somebody
should probably go and create a transition tracker for it?
Rather than accept the harm, surely
Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
It is not. You can't reasonably install things from
Hi all,
while this thread may have the outcome of having Debian's R packages following
a similar convention as with the perl-api package (why not, it does not seem to
cost much), I hope that it is fairly clear for everyone that it will not change
how we release or how we use experimental: this
On Mon, 1 Apr 2013 17:42:29 +0600
Andrey Rahmatullin w...@wrar.name wrote:
On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
Thanks for trading the R release cycle with Debian's and for
delaying the release. The harm has already been done, so somebody
should probably go
On 01-04-13 13:38, Uoti Urpala wrote:
Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
It is not. You can't
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
It is not. You can't reasonably install things from experimental rather
than unstable by default, nor is there a flag for this really should be
in unstable if not for badly managed release
I'm getting rather annoyed by this
Hi,
On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
Which does
On Mon, 1 Apr 2013 14:26:58 +0200
Rene Engelhard r...@debian.org wrote:
Hi,
On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software
On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote:
... and those uploads go into experimental as well. What's wrong with that?
That non-processed NEW for packages which in turn is needed for other
packages to go to experimental for getting them tested blocks those packages
from being
On Mon, 1 Apr 2013 14:59:14 +0200
Rene Engelhard r...@debian.org wrote:
On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote:
... and those uploads go into experimental as well. What's wrong with that?
That non-processed NEW for packages which in turn is needed for other
packages
On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
NEW processing happens whether the new package is meant for unstable or
experimental. Whether the package is in unstable or experimental does
True.
not change how that package gets tested. It can affect how that package
affects
On Mon, 1 Apr 2013 15:46:44 +0200
Rene Engelhard r...@debian.org wrote:
On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
Having packages in experimental does not block the ability to test or
upload other packages which depend on functionality in those new
versions - you just
On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote:
It is installable from experimental if the local setup is correct. It's
only a change to apt sources and preferences, in a chroot if necessary.
This Debian. It is uninstallable there. And people (NOT ME!) can't install
it. Which is
On Mon, 1 Apr 2013 15:36:35 +0100
Neil Williams codeh...@debian.org wrote:
On Mon, 1 Apr 2013 15:46:44 +0200
Rene Engelhard r...@debian.org wrote:
Apologies Rene, got you mixed up with Dirk re the R packages.
The bit about the epoch and the upload was intended for the R
maintainers.
On
Neil McGovern wrote:
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
It is unreasonable to tell the users and upstreams that Debian is
going to keep users on a known inferior version by default for a long
time, just in case more testing is needed to discover problems in the
On Mon, 1 Apr 2013 16:42:26 +0200
Rene Engelhard r...@debian.org wrote:
On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote:
It is installable from experimental if the local setup is correct. It's
only a change to apt sources and preferences, in a chroot if necessary.
This
On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote:
Neil McGovern wrote:
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
It is unreasonable to tell the users and upstreams that Debian is
going to keep users on a known inferior version by default for a long
time,
Hi,
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote:
You seem to believe that unstable is more important than stable
releases. I do not. One of us is in the wrong project.
That's easy to answer: It must be you,
On Sun, 31 Mar 2013, Dirk Eddelbuettel wrote:
It really does not add much as well already have a, say, Dependds:
r-base-core (= 3.0.0~20130327) so we are really just trading one
for the other as far as I can tell.
The difference is that you can do the following:
r-base-core Provides:
1 - 100 of 139 matches
Mail list logo
