> We already have testing-proposed-updates with a different set of rules. See
> https://wiki.debian.org/TestingProposedUpdates
Ah, well ofcourse I knew about this. I ended up mis-taking it with the
companion suite proposed.
Please excuse me for being sloppy there :D
--
Sent from my Android de
On 20/08/21 7:22 pm, Nilesh Patra wrote:
> Well, I meant u-p-u and t-p-u as disconnected suites during freeze. Upload to
> u-p-u, stuff passing there migrates to t-p-u.
We already have testing-proposed-updates with a different set of rules.
See https://wiki.debian.org/TestingProposedUpdates
>
On 20 August 2021 7:00:15 pm IST, Pirate Praveen
wrote:
>
>
>On 20/08/21 4:51 pm, Nilesh Patra wrote:
>> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates
>> to t-p-u,
>> this could be completely mitigated.
>
>No, that will defeat the purpose of freeze. t-p-u is tar
On 20/08/21 4:51 pm, Nilesh Patra wrote:
> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates
> to t-p-u,
> this could be completely mitigated.
No, that will defeat the purpose of freeze. t-p-u is targeted at testing
without going via unstable.
If this has to happen t
On 8/20/21 3:51 PM, Stephan Lachnit wrote:
> On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote:
>> If you mean keeping unstable as is and uploading stuff for testing into
>> t-p-u, that's was always called a bad idea, as nobody tests stuff in
>> t-p-u.
>
> If you don't change anything
On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote:
> If you mean keeping unstable as is and uploading stuff for testing into
> t-p-u, that's was always called a bad idea, as nobody tests stuff in
> t-p-u.
If you don't change anything else, then you're right. If you enable
t-p-u by default
tal. Using experimental
> > directly is risky as it can have changes not ready for unstable also.
> > Proposed solution: open unstable-proposed-updates with freeze and close it
> > when freeze is lifted. The packages in this suite can migrate to testing,
> > this avoids manu
directly
> is risky as it can have changes not ready for unstable also.
> Proposed solution: open unstable-proposed-updates with freeze and close it
> when freeze is lifted. The packages in this suite can migrate to testing,
> this avoids manual reuploads to unstable after freeze is li
Samuel Thibault (2021-08-18):
> No. Enabling experimental in your sources.list doesn't actually change
> anything. You have to explicitly request installing a given package from
> experimental to pull it from experimental, and only that will be getting
> updated from experimental, you won't inadve
On Wed, Aug 18, 2021 at 10:14 pm, Samuel Thibault
wrote:
Nilesh Patra wrote:
Using experimental directly is risky as it can have changes not
ready for unstable also.
No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing
Nilesh Patra wrote:
> Using experimental directly is risky as it can have changes not ready for
> unstable also.
No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing a given package from
experimental to pull it from experimenta
t ready for unstable also.
> Proposed solution: open unstable-proposed-updates with freeze and close it
> when freeze is lifted. The packages in this suite can migrate to testing,
> this avoids manual reuploads to unstable after freeze is lifted.
+1 to this.
Please do not take this
also.
Proposed solution: open unstable-proposed-updates with freeze and close it when
freeze is lifted. The packages in this suite can migrate to testing, this
avoids manual reuploads to unstable after freeze is lifted.
Optional: create a companion testing suite say rolling which may be used during
Hi,
Le 26/08/10 01:20, Carsten Hey a écrit :
> * Russ Allbery [2010-08-25 01:13 -0700]:
>> Yves-Alexis Perez writes:
>>> Would it be possible (at one point) to “fix” it and stop using
>>> unstable as t-p-u and experimental as unstable when freeze is in
>>> action?
>>
>> We could try to get lots o
ges and
> distro is totally broken" effect :-).
I thought about something like this a while ago and would have called it
'unstable-proposed-updates'. Currently experimental is used for both,
experimental packages and packages the should go to unstable in future,
a new suite t
15 matches
Mail list logo
