On Mon, 16 Jun 2014, Hans wrote:
> Why not fix it directly in testing? I always thought, packages in
> testing are already tested (for a time). Follwing your desription, it
> would be better, to run sid than testing, as the fix is faster in sid,
> than in testing.
The fix may be faster in unstable
Tom Furie writes:
> If you are looking for bleeding edge (bear in mind it's called
> bleeding edge for a reason), and are comfortable with fixing breakages
> or can configure around breakage until it's fixed then sid may be the
> path to take. If you are looking to test the next stable-in-waiting,
On Mon, Jun 16, 2014 at 09:28:41PM +0200, Hans wrote:
> Why not fix it directly in testing? I always thought, packages in testing are
> already tested (for a time). Follwing your desription, it would be better, to
> run sid than testing, as the fix is faster in sid, than in testing.
Packages a
Am Montag, 16. Juni 2014, 12:13:32 schrieb Don Armstrong:
> > in sid, should move to testing and then to sid.
My fault! Should be " ..in sid, should move to testing and then to
stable. (Sorry!)
>
eappear again testing,
>
> This is generally because the packages are specifically removed
On Mon, 16 Jun 2014, Hans wrote:
> from time to time I discover packages, which are in stable and sid,
> but NOT in testing. This looks weired for me, as packages, which are
> in sid, should move to testing and then to sid.
As is documented in https://www.debian.org/devel/testing, this is
incorrec
On Mon, 16 Jun 2014 20:44:19 +0200
Hans wrote:
> from time to time I discover packages, which are in stable and
> sid, but NOT in testing. This looks weired for me, as packages,
> which are in sid, should move to testing and then to sid.
https://www.debian.org/devel/testing
--
Hey, how much i
6 matches
Mail list logo
