Re: GNOME 2.2 summary 22/06/2003
On Tue, Jun 24, 2003 at 09:08:24PM +0200, Marcelo E. Magallon wrote:
> On Mon, Jun 23, 2003 at 09:46:20PM +0200, Johannes Rohr wrote:
>
> > But if the package info on packages.q.d.o says "package foobar is
> > buggy (3 > 0), then, how else does it determine that it is the
> > version in unstable that all 3 RC bugs apply to while the one in
> > testing is not affected by any of them? Does the BTS keep track, to
> > which version a bug report applies?
>
> Last time I asked the answer to that was "it doesn't" or similar. The
> situation might or might not have changed since then[0].
>
> > About a year ago I saw real flamefests happening on this list
> > concerning the piecemal Gnome transition in unstable. Now, I looks
> > like very few people care about the poor picture of Gnome in testing,
> > probably because no DD uses testing, which is quite natural. Still I
> > think that what is happening now in testing is worse than what
> > happened when Gnome 2 entered unstable.
>
> That's offtopic for this list, but just as info, I stopped using
> testing about a year ago, give or take some months. Previously I
> *tried* using testing for about two years until the day when I became
> clear that even if it sounds great on paper, in reality it's utterly
> broken. It works on the assumption that things like the ones you
> pointed out are going to be prevented by dependencies. I don't know
> why having gnome-session 2.x and control center 1.4 installed at the
> same time doesn't make sense, but I'll take your word for it. Is there
> a technical reason why that shouldn't happen? Apparently not. Both
> programs can be installed at the same time and apparently both programs
> can run at the same time. Does gnome-session have some sort of
> dependency on a newer release of the control center? If that's the
> case it went unnoticed, because in _unstable_ the situation required
> for someone to notice the problem was not possible. So a package with
> missing dependencies filtered thru the cracks.
>
> One of the biggest problems with testing is that the migration from
> unstable to testing is unpredictable by design. Even if _right now_
> package A could enter testing, it only takes someone uploading
> something only slightly related to A to unstable and that could prevent
> A from going in (say A depends on B which depends on C which is going
> into testing, too, but the maintainer of C finds some free time to fix
> a couple of bugs and makes an upload).
>
> Is testing better than the previous situation? Can't say for sure. I
> haven't really perceived any benefits. The RM surely disagrees.
In reallity, i think testing is not better than the previous situation,
it is complementary. The testing migration works mostly, as it is with
its imperfection and problems and all, but for complicated situations,
where there is a whole group of interdependent packages that have to go
into testing together, there is a blocking, a blocking that previously
where solved by the freeze period. Today we have no official freeze
period, or at least no freeze period advertized as such.
What i believe to be the right solution would be to hold kind of
mini-freezes. The RM or the responsibles of a group of packages would
identify problematic groups, and then the packagers of the whole group
of packages would held a concerted mini-freeze period, where uploading
to unstable is voluntary hold until said group of packages enter
testing.
To show that i don't speak wind, let me show an example. I maintain
ocaml, and with a (rather smallish) group of ocaml related package
maintainers, we decided to hold a mini-freeze to make ocaml 3.06 enter
testing. It didn't work as such, because there was blocking from
postgresql which in turn was blocked by python and perl, and also from
one of the audio libs. Since only two minor packages blocked the
transition, we decided after much though to remove them from testing,
and sollicited the RM, who was busy in other things and didn't notice
until i reptedly posted to d-d, but that is another issue. Once those
problematic packages did get removed, ocaml 3.06 did enter testing, and
the mini-freeze was over.
Friendly,
Sven Luther
Reply to: