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
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 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 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
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 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
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
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, a
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 i
While I realize that it's very hard to put off discussions when they're
raised in interesting-looking threads, this case in particular is one
where it's quite helpful socially to pick the right time to have this
discussion.
Absolutely nothing is going to change the release process for wheezy at
th
Le 01/04/2013 00:39, Dirk Eddelbuettel a écrit :
> I didn't mean to create extra work. We had two such transitions for R before
> in the last five years, and they just worked.
No. I suffer from partial upgrade and "solved it" by upgrading all
installed r related packages. The dependency system s
Hello,
[ some quotes reordered ]
2013-04-01 16:45, Neil McGovern:
> As for consensus, have a read over this thread to see if there's anyone
> supporting your views.
Well, if you resort to this argument, here I am, supporting some part of
those views. Not supporting the rude tone though.
> http:
On Mon, Apr 01, 2013 at 12:16:23AM +0200, Josselin Mouette wrote:
>
> Not only your reverse dependencies
> should only depend on the *sufficient* version of R (in this case,
> certainly not the R version used to compile the package, which will lead
> to transition blockades to testing), but they s
On Monday, April 01, 2013 09:54:51 AM Don Armstrong wrote:
> 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 di
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: r-bas
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, beca
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
>
On Mon, 1 Apr 2013 16:42:26 +0200
Rene Engelhard 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 Debian. It is
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 t
On Mon, 1 Apr 2013 15:36:35 +0100
Neil Williams wrote:
> On Mon, 1 Apr 2013 15:46:44 +0200
> Rene Engelhard 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 Mon, Apr 01, 2013 at 02:23:36PM +0
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:46:44 +0200
Rene Engelhard 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 need an a
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
> affect
On Mon, 1 Apr 2013 14:59:14 +0200
Rene Engelhard 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 to go to e
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:26:58 +0200
Rene Engelhard 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 developme
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 d
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 accus
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 no
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. The harm has already been done, so somebody
> > > should probably go and c
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 par
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 ex
1 - 100 of 139 matches
Mail list logo
