Re: send-pr, time to borgify it?

["Mark D. Baushke" <mdb@cvshome.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chad Walstrom <chewie@wookimus.net> writes:

> Well, the adventure with automake continues. I'm starting to get a
> good feel for things. Reading the automake manual requires you to pay
> attention, but most of the information I need is there.

Yup.

> One thing I've come to question is whether or not we care to retain
> the separate send-pr directory.  It appears that send-pr was intended
> to operate with or without the presence of pr-edit and query-pr,
> falling back to sendmail.  It could be distributed to your
> customer/client as a generic shell script with no external
> dependencies.

I agree.

> Currently, I've retained and updated the configure.ac file in send-pr,
> added Makefile.am and dumped Makefile.in (built by automake).  We
> *could* distribute send-pr independent of GNATS, but *should* we?
> (This isn't rhetorical.  I would really like to know your opinions.)

I would say no, do not distribute it independently.

> Over the years, it appears that the send-pr.texi manual has been fully
> integrated into the GNATS manual. Additionally, the emacs *.el file
> has been dropped in favor of the gnats.el file. By all indications,
> send-pr doesn't appear to exist separately from GNATS at all. If one
> wishes to distribute send-pr to a customer, she could tarball up
> send-pr, send-pr.1, install-sid, and install-sid.8. Even that is not
> highly necessary. The functionality of install-sid (updating a config
> file) could be rolled into send-pr.

Yup. Especially necessary if an installed userbase finds that there are
multiple configurations depending on the package that is providing a
send-pr for reporting bugs.

> Hmm...  I just did a search against help-gnats for send-pr to see if
> this conversation had popped up in the past and found an interesting
> post. [1]_  It appears that Yngve had created a manpage for
> send-pr.conf back in 2001 that doesn't appear to exist in our CVS
> repository.  We should probably roll that in, updated for today's use.
> ;-)

This seems like a good idea to me.

> So, what do you folks say?  Roll send-pr into GNATS proper and dump
> the extra build infrastructure or keep it pseudo-separate?
> 
> .. [1] http://lists.gnu.org/archive/html/help-gnats/2001-05/msg00040.html

I would suggest dumping the extra build infrastructure in this case. 

When multiple packages try to distribute a send-pr script for their
projects, but each altered to suite their own needs (very easy to do),
the user needs must worry that they are getting the correct version of
the 'send-pr' script for the tool they are trying to report bugs. For
example, multiple instances of send-pr may have different customerid
fields for install-sid to want to install.

In my opinion, it would be better for project folks that are considering
shipping something like send-pr for their 'customers' to roll their own
special code and if they are going to do that anyway, there is no real
reason for the gnats project to keep stuff separately.

	Enjoy!
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCaymf3x41pRYZE/gRAmnlAJsEMVUDuZ18bssBFpSL419AbNbYXACfaVIY
+FabMypF/SUcaRawEcGFF40=
=6Yvs
-----END PGP SIGNATURE-----


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats