|
Home > Archive > Debian Developers > March 2005 > Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
|
|
| David Schmitt 2005-03-16, 6:06 pm |
| On Wednesday 16 March 2005 18:12, Adrian Bunk wrote:
> I already sent two mails [1,2] where I expressed my opinion that dumping
> testing might be an option since it's the main reason for the underlying
> problems that seem to cause the proposed removal of two third of the
> Debian architectures from the Debian releases while it hasn't proven to
> bring any real benefits for the release.
>
> The interesting thing is that while people answered to other parts of
> these emails, noone said anything about my points regarding testing -
> neither in favor nor against them.
You fail to list and address the points testing claims to address.
Therefore I judge this part of your otherwise quite sensible mail ranting I=
=20
don't have to argue for or against because it has no real content except=20
expressing your personal animosities.
Ouch. Seems like I fell into the communication trap myself. Here is a weak =
try=20
at refuting your proposal:
To archive a stable release, arches have to be in sync, there should be onl=
y a=20
single version of every library and packages have to be installable. This=20
seem to be the problems I believe testing was designed to solve. Incidental=
ly=20
this almost the list of "problems" you identify being the cause of testings=
=20
problems. Kinda matches. Going back to a frozen-only release cycle would=20
ignore these problems until half a year before the release. Then the same=20
work that is now done for testing would have to be done anyways: arches=20
brought to sync, libraries transitioned and package installability=20
guaranteed.
Thus I make two observations:
1) Only dropping testing would increase the risk (by delaying the detection=
of=20
the problems) without noticeable reductions in amount of work (if Debian=20
still aims at a 12-18 month release cycle)
2) Providing a better alternative is more efficiently done by those=20
dissatisfied with the status-quo (i.e. you) as opposed to those who worked=
=20
hard to establish the status-quo as solution to their problems (i.e.=20
ftp-master and release team).
Thank you for still caring about Debian!
Regards, David
=2D-=20
=2D hallo... wie gehts heute?
=2D *hust* gut *rotz* *keuch*
=2D gott sei dank kommunizieren wir =FCber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
| |
| Adrian Bunk 2005-03-16, 6:06 pm |
| On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote:
> On Wednesday 16 March 2005 18:12, Adrian Bunk wrote:
>
> You fail to list and address the points testing claims to address.
>
> Therefore I judge this part of your otherwise quite sensible mail ranting I
> don't have to argue for or against because it has no real content except
> expressing your personal animosities.
>
> Ouch. Seems like I fell into the communication trap myself. Here is a weak try
> at refuting your proposal:
>
> To archive a stable release, arches have to be in sync, there should be only a
> single version of every library and packages have to be installable. This
> seem to be the problems I believe testing was designed to solve. Incidentally
> this almost the list of "problems" you identify being the cause of testings
> problems. Kinda matches. Going back to a frozen-only release cycle would
> ignore these problems until half a year before the release. Then the same
> work that is now done for testing would have to be done anyways: arches
> brought to sync, libraries transitioned and package installability
> guaranteed.
I agree with you that testing helps with some problems like getting
packages in sync and installable.
But currently testing needs regular manual help by the five members of
the release team to keep on running.
Exactly the same amount of work they are currently doing [1] might bring
the same effect without testing since this information (and much more)
is also available without testing.
"libraries transitioned" is a big point against testing:
Transitions of API-compatible libraries are a pain _only_ due to
testing. In unstable, such a transition can easily be done within a few
days.
But the transition to testing requires that all affected packages (which
might be 100 source packages for some transitions) are ready _at the
same time_, more exactly:
- each package mustn't have more more RC bugs than the testing scripts
estimate for the version in testing
- each package must be built on every single architecture
- the dependencies of every single affected package must be met after
the transition - this way, often several transition generate a
mega-transition of packages that have to go into testing at the same
time
Even if all this was fulfilled, a manual hint is still required.
And for bigger transitions, there are always manual adjustments required
since these requirements aren't fulfillable in practice.
Check how many of the announcements of your release team mention as an
important point that this transition was finally finished or that
transition is the next important milestone.
And without testing, all these transition problems wouldn't exist.
> Thus I make two observations:
>
> 1) Only dropping testing would increase the risk (by delaying the detection of
> the problems) without noticeable reductions in amount of work (if Debian
> still aims at a 12-18 month release cycle)
As I tried to explain above, the same information is already available
elsewhere and the same amount of work currently spent into testing might
as well suffice to treat them equally.
> 2) Providing a better alternative is more efficiently done by those
> dissatisfied with the status-quo (i.e. you) as opposed to those who worked
> hard to establish the status-quo as solution to their problems (i.e.
> ftp-master and release team).
Was this meant ironically?
In case it was:
If you work in a field, it often happens (and it's unfortunately quite
normal) that you get a narrow view.
> Thank you for still caring about Debian!
>
> Regards, David
cu
Adrian
[1] as already said:
I do not deny that the release team does much work
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2005-03-16, 8:47 pm |
| I demand that Adrian Bunk may or may not have written...
[snip]
> And without testing, all these transition problems wouldn't exist.
And without testing, there are those who currently use testing who'd use
stable instead, or possibly go elsewhere.
(I'm currently using testing. Updating an installation from unstable over a
dial-up connection isn't /quite/ what I want...)
[snip]
--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html>
Wit has truth in it. Wisecracking is simply calisthenics with words.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2005-03-16, 8:47 pm |
| On Thu, Mar 17, 2005 at 12:29:28AM +0000, Darren Salt wrote:
> I demand that Adrian Bunk may or may not have written...
>
> [snip]
>
> And without testing, there are those who currently use testing who'd use
> stable instead, or possibly go elsewhere.
>
> (I'm currently using testing. Updating an installation from unstable over a
> dial-up connection isn't /quite/ what I want...)
Even if you are using unstable, noone forces you to update all packages
on a daily basis.
The main reason of people I know who are currently using testing is
simply that Debian stable is much too outdated for being useful.
I do believe that it was still possible to release a new stable Debian
once a year [1] - and that this was still possible using a "traditional
freeze" without testing.
For making testing really usable, security support would be required.
This requires manpower (that might perhaps be available).
And it requires something else:
The testing scripts would have to handle build dependencies as if they
were dependencies.
This shouldn't be too hard to implement, but my impression is, that the
sole reason why it isn't implemented until now is, that it would
increase the amount of manual work required by both the release team and
all Debian developers even more.
And this leaves still the question whether it's worth sacrificing eight
architectures.
cu
Adrian
[1] no, I'm not talking about point releases
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2005-03-17, 3:24 am |
| I demand that Adrian Bunk may or may not have written...
> On Thu, Mar 17, 2005 at 12:29:28AM +0000, Darren Salt wrote:
[vbcol=seagreen]
> Even if you are using unstable, noone forces you to update all packages on
> a daily basis.
True, but even with (say) weekly updates, the quantity of packages is likely
to be lower due to things like RC bugs, uploads of newer versions before the
previous versions have made it into testing, etc.
> The main reason of people I know who are currently using testing is simply
> that Debian stable is much too outdated for being useful.
There's that too; and yes, that's one of the reasons why I'm using it.
[snip rest; I'll let others argue about it all or whatever...]
--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| Let's keep the pound sterling
Do not clog intellect's sluices with bits of knowledge of questionable uses.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Schmitt 2005-03-17, 5:56 pm |
| On Thursday 17 March 2005 00:21, Adrian Bunk wrote:
> On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote:
> "libraries transitioned" is a big point against testing:
>
> Transitions of API-compatible libraries are a pain _only_ due to
> testing. In unstable, such a transition can easily be done within a few
> days.
Which leaves one with the problem that the new library might break any or a=
ll=20
of the depending packages, which testing would catch, while transitioning=20
unstable might not. But I have to admit that I didn't follow debian=20
development as closely as I do now in the times before testing and thus mig=
ht=20
be arguing against the wind.
Perhaps the best would be to prepare the transition beforehand in experimen=
tal=20
and push the packages together into unstable, like GNOME and KDE did their=
=20
respective last big updates? This also would be a step towards reducing=20
dependency on work from the central teams.
Regards, David
=2D-=20
=2D hallo... wie gehts heute?
=2D *hust* gut *rotz* *keuch*
=2D gott sei dank kommunizieren wir =FCber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
| |
| Adrian Bunk 2005-03-18, 5:57 pm |
| On Thu, Mar 17, 2005 at 09:39:10PM +0100, David Schmitt wrote:
> On Thursday 17 March 2005 00:21, Adrian Bunk wrote:
>
> Which leaves one with the problem that the new library might break any or all
> of the depending packages, which testing would catch, while transitioning
> unstable might not. But I have to admit that I didn't follow debian
> development as closely as I do now in the times before testing and thus might
> be arguing against the wind.
This is possible (but see your own comment below).
The bigger problems from the point of view of users aren't transitions
(which usually go smooth - you simply have two versions of a library
installed) but breakages like accidential ABI changes without an so-name
change. These aren't necessarily caught be testing (except through the
RC bug count), and libtiff is a good example where such a usere-visible
problem made it into testing.
> Perhaps the best would be to prepare the transition beforehand in experimental
> and push the packages together into unstable, like GNOME and KDE did their
> respective last big updates? This also would be a step towards reducing
> dependency on work from the central teams.
That's a good idea and already done.
But this is independent of the question whether testing is present or
not.
> Regards, David
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|