Re: GNOME 2.12
Hi,
On Sun, Oct 02, 2005, Sven Luther wrote:
> It was my impression from previous mails here, that 2.10 in etch was almost
> there, and there where only a couple of packages missing or something, which
> could well have been uploaded throught t-p-u. But maybe my understanding is
> flawed, and i didn't look in detail though.
This is also my impression, I disagree on the t-p-u part though, and
I'd prefer the remaining issues to be addressed right now through
unstable instead.
> Yeah, t-p-u was only there to put aside any arguments against uploading 2.12
> right now :) A fallback if there is only minor work being done on 2.10, or to
> handle upcoming bugs that absolutely need fixing.
Aha.
> I still feel that any work on 2.10 now is going to be obsoleted by a futur
> 2.12 upload, and thus not worth it, unless it is really very few things
> missing and they can and will be done in short order, but if we are going to
> wait an indifinite time for random transition and blockages, i would go with
> 2.12 asap.
What about preparing 2.12 in experimental as is done right now while
the remaining transitions and fixes happen through unstable?
> But i am not the gnome team, and can thus only offer my opinion, and may have
> missed some serious problems or otherwise misunderstood the problem, i just
> wanted to say that t-p-u could be a solution if 2.10 is almost fully in etch
> and only a few bits are missing.
The problem is that it is hard to have a concrete measure of the number
of uploads and the number of fixes that should happen on 2.10. I
didn't give any exact list of uplaods that I would think should happen
for example because it would take a lot of time to prepare and
coordinate, and I don't have that time. Instead, I tried expressing
the checks that the current packages should pass to ensure there in a
good shape in G 2.10, and decide the work is done; I also listed some
in my opinion important issues which have to be addressed,
non-exhaustively.
I welcome any help in building a package status for all GNOME 2.10
packages, and/or a blockers list.
One way to do this would be a web page with the list of issues to
address, or a bug report with "block/blocked by" references.
For example, a big blocker is mozilla which blocks epiphany and
-extensions, and only two solutions can address the problem:
firefox-dev or fixing mozilla, either of which will take a while to
resolve, and requires a lot of maintainer's time.
Not only are blockers a lot of work, but the review process to prepare
the list of blockers is a lot of work too.
Cheers,
--
Loïc Minier <lool@dooz.org>
Reply to: