Re: [fetchmail-devel] Re: Can this stuff be removed?

[Rob F. <rf...@fu...>]

Graham Wilson wrote:
> I believe any of the website related stuff should be moved out of the
> trunk. If we still want to keep it under version control, we can create
> a new directory in the top-level of the repository for the files.

I'd prefer to keep the top level of the repository at just the trunk, 
branch, tag stuff.  That matches up best with the subversion documentation 
and various auxiliary tools.

I'd be in favor of making a subdirectory for the web stuff though.  I need 
to look at the index generatorscript to see how much we need to change 
anyway.

> > > Also, are we planning on using the testing framework and tools that
> > > esr used?
> >
> > Rob was pondering about how to reactivate the testing framework. As
> > far as I've read between the lines he wrote, he'd like to conduct
> > regression tests before releasing the next version.

Ideally I'd like to do that, but I'm not sure how much we'll be able to.  
There are lots of passwords that can't be shared, and I'm not even sure 
how many of the server owners are willing to transfer their permission for 
testing away from ESR to us.  I think some of the entries on the test list 
are even ESR's own accounts.

> I think we should move the testing scripts (torturetest.* and test*)
> should be moved to dist-tools/test/.
>
> The other scripts that esr used (getstats.py, growthplot, indexgen.sh,
> listsize, makerelease, timeplot, timeseries, upload, and uploadfaq that
> I can see) should be moved to dist-tools/.

Sounds good to me.  Paths will probably need to be changed in them though.
(Some need even more work than that.)


Is CHANGES required for some autotools stuff?  It looks like a placeholder 
to me.

I believe bighand.png is intended as the web page logo, so that should be 
kept.

I'm fine with dropping funny.html if nobody wants it in the new web page.  
We might want to wait until we have such a web page built before actually 
getting rid of it though.

If the libntlm and mime64 contents are not used in the actual fetchmail 
code, we can probably get rid of them.  On the other hand, README.NTLM 
seems to go with the copies of the libntlm files that we're actually 
distributing, so should probably stay.

OPTIONS seems to belong in some sort of historical archive.

RFC/ could go in a document archive area (alongside OPTIONS?), or could be 
considered redundant.  If deleted, I'd prefer to replace it with an HTML 
file of links to canonical locations of the same documents.

Isn't rh-config/ necessary for building the rpm?

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"