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
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 wrote:
> > >> Oh, that's a good point. Yes, I hadn't thought about that specific case
> > >> for testing ABI breakage in experimental.
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
> On 2013-04-18, Goswin von Brederlow 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 hor
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 writes:
> > >
> > > > FWIW, I've done ABI-incompatible uploads of perl to experiment
On 2013-04-18, Goswin von Brederlow 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 perl package
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 writes:
> >
> > > FWIW, I've done ABI-incompatible uploads of perl to experimental in the
> > > past without changing the perlapi-* virtual package n
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
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 wo
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
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
> Niko Tyni 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 configu
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
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
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 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-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 i
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
> rea
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" | so
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 minut
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
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 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
2013/4/9 Thomas Goirand :
> 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 also nice to
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 whe
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) feeli
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 Tue, Apr 9, 2013 at 3:15 PM, Thomas Goirand 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 that
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
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 ve
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: .
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 t
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 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, onl
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 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-raschsampl
On 6 April 2013 at 19:30, Chris Lawrence wrote:
| On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey 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
On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey 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 enquire which ver
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 t
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 pa
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 package
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 bui
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
> exist
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 bet
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 us
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 UN
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
>
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
incr
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.
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 s
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, wha
]] 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 pre
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 ic
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:
> http://www.h-online.com/open/news/item/Security-updates-br
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" u
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 w
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 rel
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:
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 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 s
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote:
> Vincent Lefevre 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 g
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
On 2013-04-02 09:50:23 -0700, Russ Allbery wrote:
> Vincent Lefevre 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 pack
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
> > http://lists.
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 in
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
Niko Tyni 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 long doubles.
On Tue, Apr 02, 2013 at 09:50:23AM -0700, Russ Allbery wrote:
> Vincent Lefevre 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 would you not t
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
> dev
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) abo
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
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
]] 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 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
[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 i
Vincent Lefevre 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.
> and upgrade from a
Vincent Lefevre 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 tools improve
Jonathan Dowland 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 the pain
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, a
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:
Tha
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,
> >
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 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.
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 (alm
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 softwa
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 wit
On Tue, 2 Apr 2013 15:15:38 +0200
Vincent Lefevre 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: until yo
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
On Tue, 2 Apr 2013 15:09:33 +0200
Vincent Lefevre 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 projects are no
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote:
> On Mon, 1 Apr 2013 17:42:29 +0600
> Andrey Rahmatullin 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.
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 ma
On Tue, 2 Apr 2013 14:52:35 +0200
Vincent Lefevre 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 - I count m
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
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 coun
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 vers
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 rel
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 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 obj
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-fadin
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 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.
> Unst
1 - 100 of 170 matches
Mail list logo
