public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
From: Mel Hatzis <hatzis@juniper.net>
To: Chad Walstrom <chewie@wookimus.net>
Cc: help-gnats@gnu.org
Subject: Re: GNATS debian package cleanups
Date: Wed, 07 Apr 2004 17:59:00 -0000	[thread overview]
Message-ID: <40743697.9040207@juniper.net> (raw)
In-Reply-To: <20040407155341.GB30144@wookimus.net>

Hi Chad, ...

On 04/07/2004 08:53 AM, Chad Walstrom submitted:
> More cleanup notes.  It looks like there was a couple missing manpages
> for gnats.  "getclose" was one of them.  I wrote a new manpage a couple
> nights ago using the existing ones as a template.  It is attached.
> 
> I also realized that the install-sid shell script did not have a
> manpage.  In researching the script to find out what it did, I was
> puzzled as to why it even existed.  All it does is replace the
> Submitter-Id environment variable in the send-pr script.   The send-pr
> script already references a configuration file (shell script),
> /etc/gnats/send-pr.conf, to override the default variables in the script
> itself.

Note that the send-pr.conf file is not part of the GNATS install...it's
something that the GNATS administrator must manually setup.

> Does anyone see a need to keep install-sid around?  In order to use it
> on a send-pr installed in /usr/bin, the user must be root anyway.  It is
> an administrator tool, and as an administrator, I cringe at the prospect
> of having to remount /usr as read-write just to change a shell
> environment variable in some random script.
> 

The idea of setting a default Submitter-Id in send-pr (which is what
install-sid exists for) assumes a usage model for GNATS in which
multiple separate organizations are filing PRs against a centralized
GNATS datastore, and each organization is equipped with a send-pr which
identifies it for PRs submitted from that organization.

In an organization running it's own GNATS server, the submitter-id
is generally of limited value.

Considering the first usage model (multiple disparate organizations
filing against a single GNATS repository), is is useful for the
centralized GNATS server to identify where the PR originates.

Now that we have that out of the way, we can begin to consider why
install-sid is around. It's a question of how send-pr is installed.
If one wanted to supply a single version of send-pr that could be
distributed to many organizations, say, as part of a standard set
of OS utilities, one obviously, cannot assume a submitter-id. How
would the submitter-id be defined for each organization?

Before the send-pr.conf file it probably seemed appropriate to have a
"random script" for defining the default submitter-id in send-pr if
one was not already defined.

Now that we have send-pr.conf, I suggest we get rid of install-sid and
modify the send-pr error message (referring to install-sid) so that
it instead, references the send-pr.conf file.

As for organizations running their own private GNATS server, the GNATS
installer ought to use the '--with-submitter' and '--with-organization'
configure options to setup appropriate defaults. This will allow them
to operate without installing a send-pr.conf file. Of course, there's
no harm in using one in any case, though I prefer not to install files
unless it's necessary.

--
Mel Hatzis


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

  reply	other threads:[~2004-04-07 17:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-05 22:45 Chad Walstrom
2004-04-07 15:55 ` Chad Walstrom
2004-04-07 17:59   ` Mel Hatzis [this message]
2004-04-07 18:16     ` Yngve Svendsen
2004-04-14 15:51     ` Chad Walstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40743697.9040207@juniper.net \
    --to=hatzis@juniper.net \
    --cc=chewie@wookimus.net \
    --cc=help-gnats@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).