removal suggestion: port rpm

[Joshua Root]

Yes, that's the sort of thing I was suggesting.

Nowhere in my message did I say that unused code should not be removed,
or that it needs to be comprehensively documented. I'm just saying that
there is value in making removed features discoverable, both for
historical interest and just in case one of them turns out to have been
an idea ahead of its time.

Here, I'll get us started:
<https://trac.macports.org/wiki/RemovedFeatures>

- Josh

On 2013-8-21 23:56 , David Strubbe wrote:
> Let me offer a suggestion from other software projects, regarding
> whether this feature could be found in the history if removed: make a
> list somewhere (Trac, wiki, etc.) of "removed features" with a note
> about in which svn revision they were removed. Then, one can easily find
> them to resurrect or reimplement them.
> 
> David
> 
> 
> On Wed, Aug 21, 2013 at 9:30 AM, Clemens Lang <cal at macports.org
> <mailto:cal at macports.org>> wrote:
> 
>     On Wed, Aug 21, 2013 at 10:31:20AM +1000, Joshua Root wrote:
>     > It's technically true that deleted code is all there in the history,
>     > but practically speaking nobody is ever going to find it because
>     > they'll have no way of even knowing to look for it. It needs to be
>     > documented somewhere for this to be realistic.
> 
>     What would be appropriate documentation for that? Isn't that what we
>     have mailinglist archives for? What are the chances that we will need
>     rpm/srpm and dpkg output ever again? Wouldn't is be just as easy to
>     re-create them from scratch (we're only talking about 750 LOC here) if
>     we really needed them and nobody remembered we used to have that?
> 
>     We could of course switch back to CVS, so we could get an Attic
>     directory. That would solve all our code removal problems.
> 
>     > (And that of course applies to code previously removed too.)
> 
>     So you're proposing I should document the mports:// source now that I
>     have removed it, even though there have been no repositories providing
>     the format required by mports:// in at least 5 years?
> 
>     I wonder why when it comes to removing code that hasn't been used by
>     anybody in _years_, suddenly lots of people see value in keeping it in a
>     potential broken state rather than throwing it out to make MacPorts base
>     a little cleaner.
> 
>     Let me make this clear to you: macports1.0 (and especially
>     macports1.0/macports.tcl) is a complete mess. If you don't want me to
>     clean it up, I'll be happy to leave it alone and spend my time on
>     something else.