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 Sat, Apr 13, 2013 at 09:48:05PM +0200, Anton Gladky wrote:
On 04/13/2013 04:18 PM, Dirk Eddelbuettel wrote:
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F,
On Sat, Apr 13, 2013 at 09:18:05AM -0500, Dirk Eddelbuettel wrote:
Charles, failing that, shall we coordinate off-list? Re-building in chroot
takes about a minute or two each but sadly some of these package appear
effectively orphaned (eg gpplot2, single upload 15 months ago -- is that
really
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:
Le Sat, Apr 13, 2013 at 09:18:05AM -0500, Dirk Eddelbuettel a écrit :
I would be really terrific if the the debian-med, debian-science, debichem
teams could update some of these packages.
Charles, failing that, shall we coordinate off-list? Re-building in chroot
takes about a minute or
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p | grep Maintainer | \
sed -e 's/.*//'
On 04/13/2013 04:18 PM, Dirk Eddelbuettel wrote:
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p |
2013/4/9 Thomas Goirand z...@debian.org:
If I upload new packages A and B, that A depends and B, and
that A gets approved, but B doesn't, then we end up with
package A being in Debian, but never installable.
That is unlikely to happen: dak has a colour scheme to identify
missing packages. It's
On Wed, Apr 10, 2013 at 02:52:20AM +0800, Thomas Goirand wrote:
If I upload new packages A and B, that A depends and B, and
that A gets approved, but B doesn't, then we end up with
package A being in Debian, but never installable.
Has this ever happened? I believe the FTP masters do look at
On 04/03/2013 04:34 AM, Thomas Goirand wrote:
On 04/01/2013 11:06 PM, Luca Falavigna wrote:
On the other hand, FTP Team is willing to fast-track NEW packages
anytime, if needed.
That's simply not truth. I can't let you say that and not reply.
Hi,
I would like to publicly thanks Luca for all
On Tue, Apr 9, 2013 at 3:15 PM, Thomas Goirand z...@debian.org wrote:
On 04/03/2013 04:34 AM, Thomas Goirand wrote:
On 04/01/2013 11:06 PM, Luca Falavigna wrote:
On the other hand, FTP Team is willing to fast-track NEW packages
anytime, if needed.
That's simply not truth. I can't let you say
On 02.04.2013 22:48, Thomas Goirand wrote:
On 04/02/2013 12:16 AM, Luca Falavigna wrote:
In a perfect world there wouldn't be any need for a NEW queue at
all.
But we have to face with the reality.
We try to do our best to improve things where we can. From the FTP
Team side, we always try to be
On 04/09/2013 11:54 PM, Bernd Zeimetz wrote:
So when did you offer yourself to join the FTP team?
I didn't offer to completely join forever, but I offered my help,
few months ago. Though considering the mistakes I did in
the past (and still do from time to time, despite my (probably
wrong)
On 09/04/13 17:54, Bernd Zeimetz wrote:
On 02.04.2013 22:48, Thomas Goirand wrote:
On 04/02/2013 12:16 AM, Luca Falavigna wrote:
In a perfect world there wouldn't be any need for a NEW queue at all.
But we have to face with the reality.
We try to do our best to improve things where we can.
On 07.04.2013 03:07, Julian Gilbey wrote:
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
as the source package is *not* dependent upon the R version, only the
On Sun, Apr 07, 2013 at 11:17:31AM +0200, Philip Rinn wrote:
On 07.04.2013 03:07, Julian Gilbey wrote:
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
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
On 7 April 2013 at 13:01, Julian Gilbey wrote:
| On Sun, Apr 07, 2013 at 11:17:31AM +0200, Philip Rinn wrote:
| On 07.04.2013 03:07, Julian Gilbey wrote:
| Ah, thanks Chris, I wasn't aware of that! But then it seems to me
| that the correct lines should be:
|
| Build-Depends: ...,
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 Fri, Apr 05, 2013 at 09:04:41PM -0500, Dirk Eddelbuettel wrote:
First off, let me apologize. I clearly did this the wrong way and should have
contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
this created for the release managers and maintainer, particularly at
On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey j...@debian.org wrote:
So something doesn't make sense somewhere: if my package doesn't care
which version of R it's building against, but R itself cares, then
surely there should be some way of querying r-base-dev during the
build process to
On 6 April 2013 at 19:30, Chris Lawrence wrote:
| On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey j...@debian.org wrote:
| So something doesn't make sense somewhere: if my package doesn't care
| which version of R it's building against, but R itself cares, then
| surely there should be some way
On 6 April 2013 at 21:55, Julian Gilbey wrote:
| R print(todo[ order(todo[,2]), ], row.names=FALSE)
| pkg
maint
| r-cran-erm
j...@debian.org
| r-cran-raschsampler
On Sat, Apr 06, 2013 at 07:48:20PM -0500, Dirk Eddelbuettel wrote:
| If you're using cdbs and r-cran.mk in debian/rules, you can add
| Depends: ${R:Depends} to debian/control to pick up the current binary
| dependency. I've migrated almost all of my packages over and it makes
| life easier.
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
First off, let me apologize. I clearly did this the wrong way and should have
contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
this created for the release managers and maintainer, particularly at this
time.
R 3.0.0 was released on April 3 as scheduled. As usual, I
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
The NEW queue is not just for double-checking licenses.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013040318.GB11273@debian
On Wed, Apr 03, 2013 at 03:44:48PM +0100, Jonathan Dowland wrote:
The NEW queue is not just for double-checking licenses.
But it should be.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
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 04/01/2013 11:06 PM, Luca Falavigna wrote:
On the other hand, FTP Team is willing to fast-track NEW packages
anytime, if needed.
That's simply not truth. I can't let you say that and not reply.
And I'm happy we come to this topic.
I've sent a mail to the FTP masters last January (IIRC)
On 04/02/2013 12:16 AM, Luca Falavigna wrote:
In a perfect world there wouldn't be any need for a NEW queue at all.
But we have to face with the reality.
We try to do our best to improve things where we can. From the FTP
Team side, we always try to be quick and helpful with our fellow
1 - 100 of 170 matches
Mail list logo
