[Aptitude-devel] About status of aptitude-gtk -- split off into separate source package? (GSoC project?)

[Manuel A. Fernandez Montecelo]

Hi,

2012/3/20 Axel Beckert <abe at debian.org>:
>> 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.