[Aptitude-devel] Plans for future major versions (0.8?)

[Manuel A. Fernandez Montecelo]

Hi Axel,

2015-11-11 08:33 Axel Beckert:
>Hi,
>
>Manuel A. Fernandez Montecelo wrote:
>> We don't even know if the code compiles today, and it's generally a
>> burden when one has to do mechanical modifications (e.g. C++/boost
>> related changes in the last few months) or simply grep for places that
>> might be affected by some bug or contain some piece of code.
>
>If it wouldn't be for the mechanical changes, I'd say we could keep
>it. But I see the argument, so let's remove it.

(This is long but not angry, just an explanation for posterity, if this
comes to be disabled).

Yes, it's not wanting to drop it just to have a neat repository, it's
because it's precisely because it is dead weight that costs effort to
carry around.

For example, when I had to do the C++11/gcc-5/shared_ptr stuff, it took
me several multi-hour sessions to get it to build again, part of which
were the modifications needed for the GTK and Qt parts (I estimate 1-2
hours in those, at least).

Another cost is when we have fragments of code that use deprecated apt
APIs, or similar cases -- I have to modify code blindly, because I don't
want to have to enable it and wait some minutes until it recompiles to
make sure that it works, just to disable again for a few
hours/days/weeks until the next changes that affect those parts.

To check all of this and keep consistency with other changes that I make
to the codebase, I use grep or other similar tools tools, and even if I
don't always have to modify code, at least I have to keep spending time
discarding places that do not need to be modified -- perhaps this is the
bigger cost of all.

On the other hand, if I don't make these changes blindly or keep track
of what needs changing, the code would have been uncompilable already
since August, so a person who wanted to ressurrect it would not have
context about the stream of changes needed, and would be fixing problems
for weeks/months just to bring it to the state where we already disabled
it back in 2012 because it was buggy and completely non-functional.

And this happens with just making mostly cosmetic and shallow changes to
the aptitude codebase that I've been doing lately, not refactoring or
deep changes that aptitude might need in the future.


So well, I also think that it's a pity, but I don't think that it makes
sense to continue spending time in a part of the project which was
abandoned 5 years ago, and in the case of Qt only after a few months of
work, and nobody appeared for a few years to try to carry the banner and
push these interfaces forward.


>> Similarly, I am not sure about GTK+, but I have heard that GTK+3 was
>> incompatible with v2 (and some projects like LXDE decided to migrate to
>> Qt instead of porting to v3), and it is unmaintained upstream (maybe
>> Cinnamon maintains that now?).
>
>I think you meant MATE. Cinnamon is GNOME 2 look build upon GTK+3.

Most probably, I knew that it was one of them but failed to go and check
which was the right one :)


>> They can always be disinterred from VCS if needed, in any case.
>
>Yep. Otherwise, the removal would hurt more.

IMO the real problem for a resurrection, apart from changes in
apt/aptitude, is that it will need heavy adaptations for the GUI -- and
these projects are mostly that, almost pure GUI.

As I said, both GUI libraries were changed enormously (and will probably
continue to change before an eventual resurrection), to the point that
also mostly-GUI projects like LXDE think that it's no more difficult to
switch over to the other GUI (Qt) rather than port to new versions of
the one that they were using until now.

So digging the dead body from the grave / VCS would be peanuts compared
to play doctor Frankenstein and bring them to life for real ;-)


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>