* David Kalnischkies [2010-08-28 16:23 +0200]:
> 2010/8/26 Carsten Hey :
> > * David Kalnischkies [2010-08-26 17:43 +0200]:
> >> Long story short:
> >> If you want to get updates from an archive only if you pushed a version
> >> previously from it: 100 => pin > 500.
> >
> > Wouldn't adding a new fi
2010/8/26 Carsten Hey :
> * David Kalnischkies [2010-08-26 17:43 +0200]:
>> Long story short:
>> If you want to get updates from an archive only if you pushed a version
>> previously from it: 100 => pin > 500.
>
> Wouldn't adding a new field to Release files similar to 'Not-Automatic'
> but pin to
Quoting Otavio Salvador (ota...@ossystems.com.br):
> Hello,
>
> On Wed, Aug 25, 2010 at 7:38 AM, Christian PERRIER wrote:
> > I wonder whether we (in D-I) could add t-p-u to the list of proposed
> > repositories when users install testing. We already propose security
> > and volatile (defaulting
Hello,
On Wed, Aug 25, 2010 at 7:38 AM, Christian PERRIER wrote:
> I wonder whether we (in D-I) could add t-p-u to the list of proposed
> repositories when users install testing. We already propose security
> and volatile (defaulting to both added): the same mechanism could be
> made for t-p-u wh
* David Kalnischkies [2010-08-26 17:43 +0200]:
> Long story short:
> If you want to get updates from an archive only if you pushed a version
> previously from it: 100 => pin > 500.
Wouldn't adding a new field to Release files similar to 'Not-Automatic'
but pin to 101 instead of 1 if this new field
2010/8/26 Paul Wise :
> AFAIK to achieve that you need pinning priorities > 500 and < 1000.
A pin-value >= 100 is enough in this scenario.
> 500 would have maybe even the wrong effect, as repositories
which are not from the default-release - if set at all - get 500 per default
(expect if the Relea
On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER wrote:
> Quoting Russ Allbery (r...@debian.org):
>
>> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>>
>> Mostly because there isn't any large pool of systems using t-p-u the way
>> there is for unstable, so the aging process where we get
Chris writes:
> I admit, I am still very new to this process.
> If I can, I would be glad to help out during the Freeze process
> if any kind soul would be willing to discuss this off list with me.
For the benefit of readers of debian-devel who don't read
debian-mentors:
I already replied to Ch
On Wed, 25 Aug 2010 02:09:03 +0100
Ben Hutchings wrote:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can
> add stuff to the next release.
>
> Ben.
>
Greetings everyone,
I admit, I am still very new to th
* Ian Jackson [2010-08-25 13:42 +0100]:
> Perhaps the right answer is to simply ask people to upload
> non-release-related stuff to experimental rather than unstable. That
> way one can do the itch-scratching right away; moving packages from
> experimental to unstable later is easy ...
>
> Even be
Mike Hommey writes ("Re: For those who care about their packages in Debian"):
> On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> > Even better would be an option to write something in your .dsc which
> > would cause automatic transfer of your package into uns
On Wed, 25 Aug 2010 13:42:34 +0100, Ian Jackson
wrote:
>Perhaps the right answer is to simply ask people to upload
>non-release-related stuff to experimental rather than unstable. That
>way one can do the itch-scratching right away;
... if apt would finally support wildcards in preferences file'
On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> > Ben Hutchings writes:
> >
> > > Please stop filing ITPs and concentrate on packages that should be
> > >
Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> Ben Hutchings writes:
>
> > Please stop filing ITPs and concentrate on packages that should be
> > included in squeeze. The sooner squeeze is out, the sooner you can add
> > st
On Wed, 2010-08-25 at 00:45 -0700, Russ Allbery wrote:
[...]
> That last bucket of time is simply not available to work on the squeeze
> release, period. If I weren't spending it on packaging new things for
> Debian, I would not be spending it on Debian *at all*. I don't think you
> actually woul
Quoting Russ Allbery (r...@debian.org):
> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable, so the aging process where we get testing in
> unstable before migrating the package never happens.
On 25/08/10 at 11:43 +0200, Yves-Alexis Perez wrote:
> On 25/08/2010 10:13, Russ Allbery wrote:
> > Yves-Alexis Perez writes:
> >> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> >
> > Mostly because there isn't any large pool of systems using t-p-u the way
> > there is for unstable,
>
> Y
On 25/08/2010 10:13, Russ Allbery wrote:
> Yves-Alexis Perez writes:
>> Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable,
Yeah, good point.
>
>> Would it be possible (at one point) to “fix”
Yves-Alexis Perez writes:
> On 25/08/2010 10:02, Russ Allbery wrote:
>> Uploading new versions of leaf software isn't *as* big of a disaster,
>> but it does mean that updates to that software that should go into
>> testing can't go through the normal testing process and have to go
>> through test
On 25/08/2010 10:02, Russ Allbery wrote:
> Uploading new versions of leaf software isn't *as* big of a disaster, but
> it does mean that updates to that software that should go into testing
> can't go through the normal testing process and have to go through
> testing-proposed-updates, which is way
Ben Finney writes:
> But the solution would best entail allowing ‘unstable’ to continue to be
> used for the same purpose regardless of whether a freeze is currently
> active, no?
This, *in general*, doesn't work because of the way library transitions
work. If you upload a new upstream version
Russ Allbery writes:
> I, and I suspect many other people who are working on packaging new
> software for their own reasons, am quite aware of the release and are
> trying to stay out of the way.
+1
Though I'm not currently packaging any new software during this freeze,
I've worked with people
Ben Hutchings writes:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
This comes up with every release, so I guess I'll reiterate what I end up
saying during every release.
Le mercredi 25 août 2010 à 02:09 +0100, Ben Hutchings a écrit :
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I second that, and would also suggest to extend this to the ti
Ben Hutchings wrote:
Hi,
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I'd add: stop uploading new upstream versions to unstable, or actually
any revision that isn't nee
Please stop filing ITPs and concentrate on packages that should be
included in squeeze. The sooner squeeze is out, the sooner you can add
stuff to the next release.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a
26 matches
Mail list logo
