[Dev] PCR Cleanup

[bill-auger]

thanks for doing that clerical work - its a very good start for
a conversation - over-all, there is really only one general
criteria formula - that is the (desirability / work-load) factor
- even if the desirability is close to zero, if the work-load is
also near zero, as i the case for most of these, then there is
no hard in keeping them - it is only the ones with a low
(desirability / work-load) factor, which i would want to spend
time discussing, repairing, or even removing; because merely
discussing them also weighs upon to the work-load

the criteria proposed by theova, is more of a finer detailed
break-down, of how to determine the (desirability / work-load)
factor - we dont have any precedent or policy for that; so it is
good to discuss these - this is the algorithm i use:

* estimate the (desirability / work-load) factor - this includes:
  - is it known for certain that many people use this
  - is there any equivalent package for the same task
    (e.g. media players, text editors)
  - the historical record of workload impedance (e.g. mozilla)
  - license auditing for new additions
  - the number of dependencies which exists only for this package

* if is the (desirability / work-load) factor high
  - is it still usable? --> keep it
  - is it broken? then the work-load has increased
    --> defer to the next criteria

* if the (desirability / work-load) factor is low
  (or if it is broken)
  - if is it working as expected --> keep it
  - if it is broken
    - is it flagged out-of-date
      or has tickets on the bug tracker recently (~1-2 years)?
      - if no --> lose it
      - if yes, is there a replacement?
        - if yes, --> excellent, lose it
        - if no, does it have high desirability? 
          - if yes. --> fix it
          - if no. --> lose it

in addition, there is one important criteria not explicit on
that list - namely: "does some other package depend on it"? - if
yes, then the (desirability/workload) factor is the product of
it's dependents (desirability/workload) factors - so the above
criteria would need to be applied recursively on all of it's
dependents, in order to make a determination

oaken-source has suggested instantiating the long-dormant PUR
PKGBUILD repo, and modifying one of the AUR helpers (or better
yet, octopi, because we carry that anyways) to index and buld
the PUR PKGBUILDs - if that happens, then probably all of those
with a low (desirability / work-load) factor would be candidates
for the PUR repo

the problem with that though, is that we still would want to
maintain them in a working state, addressing bug reports,
out-of-date requests, and ensuring compatibility with the
standard system - but doing so, entails nearly the same
work-load as keeping them in PCR does - everything except for
the final `librestage && librerelase`, which are the most
trivial of the maintenance steps - concersely, if we will not
maintain them properly, then they may as well be put into the
arch AUR instead; because we should not recommend that anyone
use them

sometime last year, some users expressed an interest in a
parabola AUR equivalent - i suggested that we could not endorse
one, but that it would be great of some ambitious users would
host their own - then we could throw all of those to the
community-maintained PUR; and we would not need to maintain them


regarding the proposed removal list:

off-hand, [kurso-de-esperanto] is the only one that i am
aware of a good reason for preserving it - it is broken now,
because it needed to be ported to QT5 - that is done, and the new
version works perfectly; but i put off on releasing, it because
has some licensing issues with the artwork - i have a new
PKGBUILD for it now; and i have been in communication with the
upstream to resolve the problems

some [clang37, llvm37, llvm37-libs] for exmaple , are probably
there because some other package depends on them

some those names marked for removal, i do have recollection of
seeing mentioned - one of [lightspark, lightspark-git] for
example, i patched and rebuilt recently because someone
specifically asked for it

others [librevpn, librevpn-git] for exmaple, are there because
we use them internally

'phantomjs' is a good example of one that is no longer
maintained, but is still a very useful program, which has no
suitable FSDG-fit replacement - as long as it remains viable,
we should keep it