Hi, 2012/3/20 Axel Beckert <[email protected]>: >> I don't know why even was allowed to drop into stable for such a >> sensitive/important package, > > Because Testing migration is based on source packages, not on binary > packages. If aptitude-gtk shouldn't have made it into stable, neither > should have aptitude (as both come from the same source package). > > If aptitude with aptitude-gtk included shouldn't have gone into > stable, it shouldn't have gone into unstable in the very beginning -- > i.e. it should have never left experimental.
I fully agree with this (and with the part of your email that I didn't include). I think I phrased things incorrectly leading you to think that I blame the technical machinery letting this happen, or the release managers. Let me rephrase it: I don't understand why Daniel Burrows (I guess that the decision was only his) let aptitude-gtk be shipped with stable release, moreso when RC bugs submitted against aptitude-gtk would hamper "mothership", aptitude-ncurses. So my proposal was: don't let this happen again -- until/unless -gtk (or -qt, or any other interface) meets some minimum quality standards. Maybe not with all of the features of -ncurses, but at least with a solid and finished interface, e.g. like synaptics. > But it did. So let's not look back or at Squeeze but at the future, > i.e. Wheezy. Yes, I meant exactly this... didn't imply trying to remove it from the current "stable" -- it doesn't make sense 1+ years after being released, anyway. > Well, there are quite some packages with a similar warning (like being > "alpha state" software) in stable and work quite well. Well, yes, but not all of these packages are package-managers ;) Also, another idea to make its status more visible is to provide a big dialog when aptitude-gtk starts, saying "This is really EXPERIMENTAL, some widgets don't work at all, there's missing functionality, etc". > If aptitude-gtk already would be a separate source package, I'd filed > an RFA or O WNPP bug now, but I'm not sure if filing an RFA/O against > a non-existing source package causes any problematic side effects. Another alternative is to provide aptitude-gtk as a separate version in experimental only. So, src:aptitude v0.6.5-featuring_gtk would be provided in experimental, and the regular releases of src:aptitude would contain only the -ncurses binary package. (For me having aptitude-gtk in unstable is OK as well, at least if we expect some visibility for other people to volunteer to develop it). > aptitude-gtk was created as a GSoC project. Maybe we should try to > find someone to get it in shape as another GSoC project. Ana (Cc'ed) > already asked if we have some ideas. Anyone would mentor further > aptitude-gtk developement? I don't know almost anything about GTK, and besides that, probably I'll be off-line during many weeks in summer. (And it's not as if I know enough of the internals to mentor anybody...) Cheers. _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
