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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
