problems with the concept of unstable -> testing

classic Classic list List threaded Threaded
106 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

problems with the concept of unstable -> testing

Russell Coker
Currently any time I want to update a package for Lenny it has to go through
unstable and testing first.

If the Lenny freeze time was short this MIGHT be considered to be only a minor
obstacle to development.  But as the freeze is getting longer and we have a
GR which could make it a lot longer this seems like a significant problem.

If I upload a significantly newer version to unstable (which I would like to
do for some of my packages as part of ongoing development that will lead to
Lenny+1) then AKAIK there is no way to put a minor update in Lenny (unless I
was to use an epoch change which would be horrible and might require changes
to several other packages).

I think that we need a way to upload to Lenny without involving unstable.

I don't think that my suggestion is anything new, it is the practice on every
other large software development project that I have seen which has been
reasonably well run.

While changes to the processes for uploading new packages are probably not
desirable when a freeze is starting, it seems that Lenny might be delayed for
a while.  So if the GR on the Lenny release ends up actually changing
anything then I suggest that we make some changes to prevent stalling all
development.

Failing that I will create my own repository for unstable versions of my
packages - which of course won't give as good a result as most users of
Unstable won't get them.

--
[hidden email]
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Steffen Joeris
Hi Russell

> If I upload a significantly newer version to unstable (which I would like
> to do for some of my packages as part of ongoing development that will lead
> to Lenny+1) then AKAIK there is no way to put a minor update in Lenny
> (unless I was to use an epoch change which would be horrible and might
> require changes to several other packages).
You can upload to testing-proposed-updates (testing in the changelog will work
too). Then the package will be autobuild on the archs and released into
testing by the release team. Nonetheless, it should be discussed with the
release team first, if such an upload is desired.

The same goes for security. There is testing-security, which is accepted on
security.debian.org. Once it is released there as a DTSA, the packages will
be copied to ftp-master and then go into the testing-proposed-updates queue
and eventually end up in testing. (Of course it should be coordinated with
the security team to avoid confusion, broken uploads and duplicated work :))

Is that what you were after?

Cheers
Steffen

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Michal Čihař-2
In reply to this post by Russell Coker
Hi

Dne Tue, 16 Dec 2008 07:02:59 +1100
Russell Coker <[hidden email]> napsal(a):

> Currently any time I want to update a package for Lenny it has to go through
> unstable and testing first.
>
> If the Lenny freeze time was short this MIGHT be considered to be only a minor
> obstacle to development.  But as the freeze is getting longer and we have a
> GR which could make it a lot longer this seems like a significant problem.
>
> If I upload a significantly newer version to unstable (which I would like to
> do for some of my packages as part of ongoing development that will lead to
> Lenny+1) then AKAIK there is no way to put a minor update in Lenny (unless I
> was to use an epoch change which would be horrible and might require changes
> to several other packages).
>
> I think that we need a way to upload to Lenny without involving unstable.
I thought testing-proposed-updates is for that...

--
        Michal Čihař | http://cihar.com | http://blog.cihar.com

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Cyril Brulebois-4
In reply to this post by Russell Coker
Russell Coker <[hidden email]> (16/12/2008):
> I think that we need a way to upload to Lenny without involving
> unstable.

Or you might use experimental, and keep unstable for lenny.

Mraw,
KiBi.

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Cyril Brulebois-4
In reply to this post by Michal Čihař-2
Michal Čihař <[hidden email]> (15/12/2008):
> I thought testing-proposed-updates is for that...

tpu is considered a last resort measure in case it's not possible to fix
a package through unstable. Less testing (hmm) through tpu than through
unstable is a part of the problem with pushing things this way rather
than letting them flow in through unstable + unblocks.

Oh, and please note the hard freeze we entered, too.

Mraw,
KiBi.

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Julien BLACHE
In reply to this post by Russell Coker
Russell Coker <[hidden email]> wrote:

Hi,

> I think that we need a way to upload to Lenny without involving unstable.

Something like testing-proposed-updates, which already exists today, and
also existed for previous releases?

> Failing that I will create my own repository for unstable versions of my
> packages - which of course won't give as good a result as most users of
> Unstable won't get them.

You mean, something like experimental?

You failed "Basic research 101". And it was as simple as going to
<http://release.debian.org> and read the Lenny freeze announcement
<http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html>
that is linked under the "Lenny frozen" title.

JB.

--
 Julien BLACHE - Debian & GNU/Linux Developer - <[hidden email]>
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Noah Slater-6
On Mon, Dec 15, 2008 at 09:30:33PM +0100, Julien BLACHE wrote:
> You mean, something like experimental?
>
> You failed "Basic research 101". And it was as simple as going to
> <http://release.debian.org> and read the Lenny freeze announcement
> <http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html> that is
> linked under the "Lenny frozen" title.

Is there any need for such rude condescension?

--
Noah Slater, http://tumbolia.org/nslater


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Bastian Venthur-3
In reply to this post by Russell Coker
Russell Coker schrieb:
[...]
> While changes to the processes for uploading new packages are probably not
> desirable when a freeze is starting, it seems that Lenny might be delayed for
> a while.  So if the GR on the Lenny release ends up actually changing
> anything then I suggest that we make some changes to prevent stalling all
> development.

I support that request. Not only is unstable quite outdated already
(bleeding edge?) it also becomes more and more a problem since the
kernel and Xorg aren't updated anymore in unstable. That means that
newer hardware (especially Laptops) don't fully work anymore (WLAN,
Graphic, Sound).

Since we're making it very hard for our users to get their new hardware
working seamlessly, unstable becomes more and more unattractive compared
to other distributions.

Some suggest to cherry pick packages from experimental, but first some
packages like the kernel aren't even available there and second, since
experimental is not part of the unstable > testing > stable flow, it has
the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
And officially we don't even recommend using unstable, aren't we? So for
me that argument is invalid.

What I'd like to see is a solution where unstable is *never* frozen,
maybe by replacing the current frozen unstable with something temporary
and putting it between unstable and testing, where all the fixes go
while all the new stuff can still go into unstable but cannot enter the
next step while we're in the freeze:

Normal:

experimental || unstable > testing > stable

Freeze:

experimental || unstable || $something frozen > testing > stable

Basicly we already have this with:

            experimental || unstable > testing > stable

but that's an abuse of experimental (as a substitute for unstable), not
everyone uses it to upload new packages and it still has the
I'll-break-you-box-aura.


Cheers,

Bastian


--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Cyril Brulebois-4
Bastian Venthur <[hidden email]> (15/12/2008):
> Some suggest to cherry pick packages from experimental, but first some
> packages like the kernel aren't even available there and second,

AFAICT since kernel people are already busy with getting the kernel in
shape for lenny. Not because of some classification. IMHO, IANAKM, etc.

> since experimental is not part of the unstable > testing > stable
> flow, it has the aura of
> sandbox/playground/if-your-box-breaks-its-your-own-fault.

So is unstable. Or even testing, to a lower extent.

> And officially we don't even recommend using unstable, aren't we? So
> for me that argument is invalid.

Which argument?

Mraw,
KiBi.

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Didier Raboud-5
In reply to this post by Bastian Venthur-3
Bastian Venthur wrote:

> Russell Coker schrieb:
> [...]
>> While changes to the processes for uploading new packages are probably
>> not desirable when a freeze is starting, it seems that Lenny might be
>> delayed for
>> a while.  So if the GR on the Lenny release ends up actually changing
>> anything then I suggest that we make some changes to prevent stalling all
>> development.
>
> I support that request. Not only is unstable quite outdated already
> (bleeding edge?) it also becomes more and more a problem since the
> kernel and Xorg aren't updated anymore in unstable. That means that
> newer hardware (especially Laptops) don't fully work anymore (WLAN,
> Graphic, Sound).
>
> Since we're making it very hard for our users to get their new hardware
> working seamlessly, unstable becomes more and more unattractive compared
> to other distributions.
>
> Some suggest to cherry pick packages from experimental, but first some
> packages like the kernel aren't even available there and second, since
> experimental is not part of the unstable > testing > stable flow, it has
> the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault.
> And officially we don't even recommend using unstable, aren't we? So for
> me that argument is invalid.
>
> What I'd like to see is a solution where unstable is *never* frozen,
> maybe by replacing the current frozen unstable with something temporary
> and putting it between unstable and testing, where all the fixes go
> while all the new stuff can still go into unstable but cannot enter the
> next step while we're in the freeze:
>
> Normal:
>
> experimental || unstable > testing > stable
>
> Freeze:
>
> experimental || unstable || $something frozen > testing > stable
>
> Basicly we already have this with:
>
>             experimental || unstable > testing > stable

Something like

        experimental || unstable-be || unstable-pt > testing >> stable

with:

experimental    Real sandbox/playground/if-your-box-breaks-its-your-own-fault
unstable-be     Bleeding-Edge   Constantly updated to "newest upstream"
unstable-pt     Pre-Testing     Last "considered long-time and stable" upstream
                                Bug-fixing, actual "unstable"
testing         as actually     Future Stable

?

--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Bastian Venthur-3
Didier Raboud schrieb:

> Bastian Venthur wrote:
>> What I'd like to see is a solution where unstable is *never* frozen,
>> maybe by replacing the current frozen unstable with something temporary
>> and putting it between unstable and testing, where all the fixes go
>> while all the new stuff can still go into unstable but cannot enter the
>> next step while we're in the freeze:
>>
>> Normal:
>>
>> experimental || unstable > testing > stable
>>
>> Freeze:
>>
>> experimental || unstable || $something frozen > testing > stable
>>
>> Basicly we already have this with:
>>
>>             experimental || unstable > testing > stable
>
> Something like
>
>         experimental || unstable-be || unstable-pt > testing >> stable
>
> with:
>
> experimental    Real sandbox/playground/if-your-box-breaks-its-your-own-fault
> unstable-be     Bleeding-Edge   Constantly updated to "newest upstream"
> unstable-pt     Pre-Testing     Last "considered long-time and stable" upstream
>                                 Bug-fixing, actual "unstable"
> testing         as actually     Future Stable
>
> ?

Something like that, I don't really care about the name. The important
thing is, that unstable is never frozen, but temporarily disconnected
from the unstable > testing > stable flow.

Another way to see it is that unstable is constantly flowing and we're
just forking a stable distribution from it from time to time.


Cheers,

Bastian

--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Cyril Brulebois-4
Bastian Venthur <[hidden email]> (15/12/2008):
> Another way to see it is that unstable is constantly flowing and we're
> just forking a stable distribution from it from time to time.

It's called Ubuntu.
 
Mraw,
SCNR,
KiBi.

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Didier Raboud-5
In reply to this post by Bastian Venthur-3
Bastian Venthur wrote:

> Didier Raboud schrieb:
>> Bastian Venthur wrote:
>>> What I'd like to see is a solution where unstable is *never* frozen,
>>> maybe by replacing the current frozen unstable with something temporary
>>> and putting it between unstable and testing, where all the fixes go
>>> while all the new stuff can still go into unstable but cannot enter the
>>> next step while we're in the freeze:
>>>
>>> Normal:
>>>
>>> experimental || unstable > testing > stable
>>>
>>> Freeze:
>>>
>>> experimental || unstable || $something frozen > testing > stable
>>>
>>> Basicly we already have this with:
>>>
>>>             experimental || unstable > testing > stable
>>
>> Something like
>>
>>         experimental || unstable-be || unstable-pt > testing >> stable
>>
>> with:
>>
>> experimental    Real
>> sandbox/playground/if-your-box-breaks-its-your-own-fault
>> unstable-be     Bleeding-Edge   Constantly updated to "newest upstream"
>> unstable-pt     Pre-Testing     Last "considered long-time and stable"
>> upstream
>>                                 Bug-fixing, actual "unstable"
>> testing         as actually     Future Stable
>>
>> ?
>
> Something like that, I don't really care about the name. The important
> thing is, that unstable is never frozen, but temporarily disconnected
> from the unstable > testing > stable flow.
>
> Another way to see it is that unstable is constantly flowing and we're
> just forking a stable distribution from it from time to time.

Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) in
which updates occur in 2 stages to finalize and "stable"ize one particular
snapshot ?

Note that forking+stable'izing Sid is what Ubuntu does every six months.

/me scratches head.

--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Bastian Venthur-3
Didier Raboud schrieb:

> Bastian Venthur wrote:
>> Something like that, I don't really care about the name. The important
>> thing is, that unstable is never frozen, but temporarily disconnected
>> from the unstable > testing > stable flow.
>>
>> Another way to see it is that unstable is constantly flowing and we're
>> just forking a stable distribution from it from time to time.
>
> Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) in
> which updates occur in 2 stages to finalize and "stable"ize one particular
> snapshot ?

I'm not sure what you're asking but by temporarily insterting a
$frozen-something between unstable and testing, we basically have the
same flow as currently just with the benefit of a living unstable. I
don't see the problem:

currently during the freeze:

            unstable (frozen) > testing > stable

new:

unstable || unstable (frozen) > testing > stable

>
> Note that forking+stable'izing Sid is what Ubuntu does every six months.

Is that important? Unstable is frozen for nearly 1/2 year now, that's a
problem we should try to solve if we don't want to degrade ourselves to
a server-only distribution.


Cheers,

Bastian

--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Didier Raboud-5
In reply to this post by Russell Coker
Hmmm.

Thinking about it again:

* For now, until the Lenny Release, there is testing-proposed-updates, which
should maybe pushed more for users and DD's to use.

* http://wiki.debian.org/ReleaseProposals has enough thoughts about possible
changes. Maybe develop ideas further more directly in the wiki. After,
AFTER, after releasing Lenny, propose a GR for changing the Release
Process.


--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Stefano Zacchiroli
In reply to this post by Noah Slater-6
On Mon, Dec 15, 2008 at 08:41:06PM +0000, Noah Slater wrote:
> > You failed "Basic research 101". And it was as simple as going to
> > <http://release.debian.org> and read the Lenny freeze announcement
> > <http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html> that is
> > linked under the "Lenny frozen" title.
>
> Is there any need for such rude condescension?

No.

The pointers conveyed by the follow-up were great, the tone terrible.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Didier Raboud-5
In reply to this post by Bastian Venthur-3
Bastian Venthur wrote:

> Didier Raboud schrieb:
>> Bastian Venthur wrote:
>>> Something like that, I don't really care about the name. The important
>>> thing is, that unstable is never frozen, but temporarily disconnected
>>> from the unstable > testing > stable flow.
>>>
>>> Another way to see it is that unstable is constantly flowing and we're
>>> just forking a stable distribution from it from time to time.
>>
>> Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…)
>> in which updates occur in 2 stages to finalize and "stable"ize one
>> particular snapshot ?
>
> I'm not sure what you're asking but by temporarily insterting a
> $frozen-something between unstable and testing, we basically have the
> same flow as currently just with the benefit of a living unstable. I
> don't see the problem:
>
> currently during the freeze:
>
>             unstable (frozen) > testing > stable
>
> new:
>
> unstable || unstable (frozen) > testing > stable

That's

http://wiki.debian.org/AddAnotherRepositoryBetweenUnstableAndTesting

Which needs update and clarification…

>> Note that forking+stable'izing Sid is what Ubuntu does every six months.
>
> Is that important?

No. But if Debian was to adopt the same Release Process as Ubuntu, why not
joining forces, entirely ?

I ''guess'' that it wouldn't be the "fun in Debian"…

> Unstable is frozen for nearly 1/2 year now, that's a problem we should try
> to solve if we don't want to degrade ourselves to a server-only
> distribution.

100% ACK.

My feeling is that a release per sub-system [0] could be viable and could
make Debian a really dynamic and up to date distro, but adding a repository
between Sid and Testing is a good way to go.

Best regards,

OdyX

[0] http://wiki.debian.org/ReleasePerSubsystem
--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Bastian Venthur-3
Didier Raboud schrieb:
> Bastian Venthur wrote:

>> currently during the freeze:
>>
>>             unstable (frozen) > testing > stable
>>
>> new:
>>
>> unstable || unstable (frozen) > testing > stable
>
> That's
>
> http://wiki.debian.org/AddAnotherRepositoryBetweenUnstableAndTesting
>
> Which needs update and clarification…

Not quite. If I understand correctly the above proposes a permanent
repository between unstable and testing. I'm suggesting a temporary
repository during the freeze periods. Sorry if that wasn't clear.


Cheers,

Bastian

--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Romain Beauxis-2
In reply to this post by Bastian Venthur-3
Le Monday 15 December 2008 23:19:55 Bastian Venthur, vous avez écrit :
> > Note that forking+stable'izing Sid is what Ubuntu does every six months.
>
> Is that important? Unstable is frozen for nearly 1/2 year now, that's a
> problem we should try to solve if we don't want to degrade ourselves to
> a server-only distribution.

You can't get both recent *and* stabilized software. For a solid release to be
done, one needs to hold new improvements for a while.

I am proud that we can take this time freely from any commercial constraints.
The main problem is that this needs to be explained to users. Most likely,
people want both recent versions and stability, which is just impossible.
(and yes, these sort of issues happen in Ubuntu).

Besides, I don't see the polemic with this "upload to unstable or
experimental" issue. I get the impression that some developpers confuse their
own comfort with the interest of the distribution somehow.


Romain


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problems with the concept of unstable -> testing

Didier Raboud-5
Romain Beauxis wrote:

> You can't get both recent *and* stabilized software. For a solid release
> to be done, one needs to hold new improvements for a while.

Yes. But there is a bunch of non-DD people that strongly want to use Debian
and prefer the recent software over the stabilized one. With the new
laptops coming out every two weeks, having the latest kernel, Xorg or hal
is no caprice, it's needed…

Debian Testing before the freeze is satisfying for most geeks that run their
own laptop only, and not a great bunch of desktops.

> I am proud that we can take this time freely from any commercial
> constraints. The main problem is that this needs to be explained to users.
> Most likely, people want both recent versions and stability, which is just
> impossible. (and yes, these sort of issues happen in Ubuntu).

Define "people"… I guess that with various user's types, you get various
hopes.

> Besides, I don't see the polemic with this "upload to unstable or
> experimental" issue. I get the impression that some developpers confuse
> their own comfort with the interest of the distribution somehow.
>
>
> Romain

Maybe the problem comes from the time needed to package and test a new
upstream version.

Look for example at the upcoming KDE4.2 : KDE4.0 ("public beta") went out in
january 2008. Since then and 'because' of the unstable-to-testing pipe,
KDE4.0 has only lived in experimental with the big fat blinking
red "WARNING" sign above.

KDE4 was then hard to test for "testing" users that don't play with
apt-pinning and KDE4 will not be part of Lenny (even if it could…), roughly
15 months after its release.

That's not a problem from Debian stable users, who need a "stable before
all" release. But for the FLOSS community and the geeky users, I guess that
it is in fact a problem.

With a less jungle experimental which you could trust as the unfrozen
unstable or with a constantly unfrozen unstable, this would not be an
issue.

Anyway, time to sleep.

'night !

OdyX

--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

1234 ... 6