public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
* The TODO list and planning a release schedule
@ 2004-06-17  9:24 Chad Walstrom
  2004-06-17 16:48 ` CVS Branching and Merging Chad Walstrom
  2004-06-20 16:43 ` The TODO list and planning a release schedule Mel Hatzis
  0 siblings, 2 replies; 4+ messages in thread
From: Chad Walstrom @ 2004-06-17  9:24 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 10754 bytes --]

I figured I'd throw this out for discussion to see what people feel are
priorities for the GNATS software and what type of release schedule we
should try to hold to.  The following list is the text output of the XML
.todo file that has been checked into CVS.

I'm fishing for comments here, so please let us know what your
impressions are.  I've copied in almost all of the old TODO list into
the 'Unassigned' list item.  These are trivial to reparent to different
releases.  If a task isn't "assigned" to someone, it's because this is
still a work in progress or because no one has mentioned interest in it.

Also, our GNATS database, although recovered from the old fencepost
backups, has not been reinstalled or reinstated.  Consider every release
a bugfix release, although notable ones may show up on this list.  I'm
awaiting a fencepost account, and we have requested that the GNATS
database be installed and restored to its former glory from the GNU
sysadmin's.  Adam or I will keep you all posted.

A '-' in front of a list item indicates it's finished.

As far as a timeline, I would like to start preparing a 4.1 pre-release
ASAP.  There have been some CVS updates since the original 4.0 release,
and it's a good time mark the codebase before branching off for the big
changes in 4.2 and 5.0.

    GNATS General TODO List
  1.Release 4.1: Code cleanups, bug fixes, documentation updates
    Added: Fri Jun 11 10:36:54 2004  Completed: incomplete
    Duration: incomplete  Priority: high

    - 1.Prepend $(DESTDIR) to Makefile.in installation targets (Chad)
        Added: Fri Jun 11 11:08:38 2004  Completed: completed on Fri Jun 11 14:07:23 2004
        Duration: 2h 58m  elapsed  Priority: veryhigh

        (Committed this to CVS two days ago.)
      2.Add missing manpages -- one manpage for each application
        Added: Fri Jun 11 11:11:57 2004  Completed: incomplete
        Duration: incomplete  Priority: high

      3.Kill install-sid script and update documentation
        Added: Fri Jun 11 11:09:17 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      4.Update Documentation: Set developer's policy.
        Added: Fri Jun 11 14:45:45 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

  2.Release 4.2: New Features
    Added: Fri Jun 11 10:37:02 2004  Completed: incomplete
    Duration: incomplete  Priority: medium

      1.Mail handling enhancements
        Added: Fri Jun 11 14:48:24 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

          1.Mail-based manipulation of GNATS database (Mel)
            Added: Fri Jun 11 14:49:11 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

          2.Trigger-based mail format replies (Mel)
            Added: Fri Jun 11 14:49:28 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

          3.Enable To: address@bogus.example.com syntax to queue-pr
            Added: Fri Jun 11 14:49:40 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

      2.MIME Handling
        Added: Fri Jun 11 14:50:49 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

          1.Detach files appropriately for GNATS DB format
            Added: Fri Jun 11 14:51:48 2004  Completed: incomplete
            Duration: incomplete  Priority: high

          2.Convert HTML to TXT?
            Added: Fri Jun 11 14:51:15 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

  3.Release 5.0: New Features, Major Changes to DB Layer, RDBMS
    Added: Fri Jun 11 10:37:07 2004  Completed: incomplete
    Duration: incomplete  Priority: medium

      1.Database Enhancements
        Added: Fri Jun 11 14:53:57 2004  Completed: incomplete
        Duration: incomplete  Priority: high

          1.DB Abstraction Layer (Mel)
            Added: Fri Jun 11 14:52:27 2004  Completed: incomplete
            Duration: incomplete  Priority: high

          2.Oracle RDBMS Backend
            Added: Fri Jun 11 14:52:39 2004  Completed: incomplete
            Duration: incomplete  Priority: high

      2.Mail handling enhancements
        Added: Fri Jun 11 14:55:10 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

          1.Maintain mbox archive of all emails
            Added: Fri Jun 11 14:55:27 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

          2.Fake Audit trail entries as emails and append to mbox archive
            Added: Fri Jun 11 14:55:41 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

          3.Continue to use existing PR datafile for logging events, keywords, and metadata
            Added: Fri Jun 11 14:55:58 2004  Completed: incomplete
            Duration: incomplete  Priority: medium

      3.Account enhancements
        Added: Fri Jun 11 14:56:29 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

          1.PAM Authentication (Pankaj)
            Added: Fri Jun 11 14:56:45 2004  Completed: incomplete
            Duration: incomplete  Priority: high

            (Pankaj expressed interest in this on 2004-06-14)
  4.Unassigned
    Added: Fri Jun 11 13:50:51 2004  Completed: incomplete
    Duration: incomplete  Priority: medium

      1.Add squirrels, to make pst happy.
        Added: Fri Jun 11 14:42:32 2004  Completed: incomplete
        Duration: incomplete  Priority: high

      2.Add conditional formats
        Added: Fri Jun 11 13:56:21 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      3.Add script hooks, probably for edit formats and such.  Need to think about how to
        integrate in changes to the PR done by the script
        Added: Fri Jun 11 13:57:38 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

        (after all, that's really the whole point)
      4.Allow fields to not exist; add a "field-always-present" option to the field description
        Added: Fri Jun 11 13:58:17 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      5.Add virtual fields.
        Added: Fri Jun 11 13:59:28 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

        (The output format can use the existing format mechanism. This would necessitate having a
        "no-display" field flag, so that some fields don't show up in a "full" query (adding all
        the fields to full" is a rather obnoxious requirement).  There should also be a "raw"
        query that dumps all the real fields as raw contents, for editing purposes (and perhaps
        for other things).)
      6.Revise access control mechanisms.
        Added: Fri Jun 11 14:39:12 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      7.Should PRs have a ">Database-Name:" header?  Probably, and probably immutable.  Can be
        used when editing a PR, or submitting an initial one.
        Added: Fri Jun 11 14:39:27 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      8.Append-only fields.  Need to revise access control first.
        Added: Fri Jun 11 14:40:05 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

      9.Document functions.  Many of them are undocumented (even newly-added ones, shame).
        Added: Fri Jun 11 14:41:10 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     10.See how much farther we can go with removing knowledge of particular fields from the
        gnats code.
        Added: Fri Jun 11 14:42:03 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     11.Make it possible to include adm field contents in the configuration file, instead of
        always using an external config file.
        Added: Fri Jun 11 14:42:59 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     12.The database state is not clean.  There should be a struct that describes the current
        database, and is passed around as needed.
        Added: Fri Jun 11 14:43:22 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     13.The client state is not clean.  The API is horrid; clients should not know or care if
        they're communicating via the network or locally.  The original solution was to just
        allow network access, but that's not really fixing the problem.  (We'll know we're there
        when gnatsd can act as a relay.)
        Added: Fri Jun 11 14:43:55 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     14.The client connection to the server should also be encapsulated in a struct as well. That
        is, something to describe the client (its hostname, username, password, access level). 
        Could eventually allow for a single server process that handles multiple connections.
        Added: Fri Jun 11 14:44:32 2004  Completed: incomplete
        Duration: incomplete  Priority: medium

     15.Change edit-pr to include the "Changed-Why:" header in the initial PR template instead of
        a separate prompt.  Maybe.
        Added: Fri Jun 11 14:24:46 2004  Completed: incomplete
        Duration: incomplete  Priority: low

     16.Should all the fields listed in the input section be required? Configurable? How about
        rejecting initial erroneous PRs (PRs with bad fields) instead of fixing them up? It sucks
        that pr-edit --submit < /dev/null could quite presumably create a valid PR.
        Added: Fri Jun 11 14:25:50 2004  Completed: incomplete
        Duration: incomplete  Priority: low

     17.The initial PR filing stuff is way too complicated.  In particular, the various field
        checks should be configured in dbconfig.  That would let us remove more builtin fields.
        Added: Fri Jun 11 14:38:18 2004  Completed: incomplete
        Duration: incomplete  Priority: low

     18.Decide if the "exec gnatsd locally" option is a security hole.  (Probably.) Make it #if
        TESTING only?
        Added: Fri Jun 11 14:38:30 2004  Completed: incomplete
        Duration: incomplete  Priority: low

     19.Come up with a better name for the lexer source file.
        Added: Fri Jun 11 14:41:35 2004  Completed: incomplete
        Duration: incomplete  Priority: low



-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* CVS Branching and Merging
  2004-06-17  9:24 The TODO list and planning a release schedule Chad Walstrom
@ 2004-06-17 16:48 ` Chad Walstrom
  2004-06-20 16:43 ` The TODO list and planning a release schedule Mel Hatzis
  1 sibling, 0 replies; 4+ messages in thread
From: Chad Walstrom @ 2004-06-17 16:48 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]

Chad Walstrom wrote:
> As far as a timeline, I would like to start preparing a 4.1
> pre-release ASAP.  There have been some CVS updates since the original
> 4.0 release, and it's a good time mark the codebase before branching
> off for the big changes in 4.2 and 5.0.

Let me rephrase that.  We should probably branch releases and leave the
trunk as the development branch.  In which case, we tag the trunk for
the 4.1 release as release_4_1, then create the maintenance branch as
release_4_1_branch.  Patch releases to the 4.1 series would then be
tagged from that branch: release_4_1_1, etc.

We don't need to get carried away with judicious branching, but if you
feel comfortable using a branch to work on feature enhancements, please
feel free to do so.  Let's leave the trunk for merging.  For example,
Mel is planning big changes, so perhaps he branches off the trunk as

    {featurename|author}_{revision-branching-from}_dev
    
And, when you're ready to merge to the trunk, merge from the trunk to
get the updates and tag (with '_merge') after conflicts are resolved.
Then whoever is in charge of merging to the trunk will pull from that
tag.  Once merged, we can tag the target trunk/branch with a "_merged"
tag.

Ideas?  Overkill?

I know CVS operations to savannah are a bit slow, but it's workable.
What do you all think of judicious tagging?  i.e.  Tagging the
merge-points of bug fixes or feature additions?

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: The TODO list and planning a release schedule
  2004-06-17  9:24 The TODO list and planning a release schedule Chad Walstrom
  2004-06-17 16:48 ` CVS Branching and Merging Chad Walstrom
@ 2004-06-20 16:43 ` Mel Hatzis
  2004-06-20 17:06   ` Chad Walstrom
  1 sibling, 1 reply; 4+ messages in thread
From: Mel Hatzis @ 2004-06-20 16:43 UTC (permalink / raw)
  To: Chad Walstrom; +Cc: help-gnats

Hi Chad, thanks for putting this together...it's a great starting point
for where we're going next. I have more comments below, but before we
delve into them, let me first say thanks for stepping up and taking on
the role of GNATS maintainer.

On 06/15/2004 12:28 PM, Chad Walstrom submitted:
> I figured I'd throw this out for discussion to see what people feel are
> priorities for the GNATS software and what type of release schedule we
> should try to hold to.  The following list is the text output of the XML
> .todo file that has been checked into CVS.
> 
> I'm fishing for comments here, so please let us know what your
> impressions are.  I've copied in almost all of the old TODO list into
> the 'Unassigned' list item.  These are trivial to reparent to different
> releases.  If a task isn't "assigned" to someone, it's because this is
> still a work in progress or because no one has mentioned interest in it.
> 
> Also, our GNATS database, although recovered from the old fencepost
> backups, has not been reinstalled or reinstated.  Consider every release
> a bugfix release, although notable ones may show up on this list.  I'm
> awaiting a fencepost account, and we have requested that the GNATS
> database be installed and restored to its former glory from the GNU
> sysadmin's.  Adam or I will keep you all posted.

Cool.

> 
> A '-' in front of a list item indicates it's finished.
> 
> As far as a timeline, I would like to start preparing a 4.1 pre-release
> ASAP.  There have been some CVS updates since the original 4.0 release,
> and it's a good time mark the codebase before branching off for the big
> changes in 4.2 and 5.0.
> 
>     GNATS General TODO List
>   1.Release 4.1: Code cleanups, bug fixes, documentation updates
>     Added: Fri Jun 11 10:36:54 2004  Completed: incomplete
>     Duration: incomplete  Priority: high
> 
>     - 1.Prepend $(DESTDIR) to Makefile.in installation targets (Chad)
>         Added: Fri Jun 11 11:08:38 2004  Completed: completed on Fri Jun 11 14:07:23 2004
>         Duration: 2h 58m  elapsed  Priority: veryhigh

While we're here, if you try building from a directory other than
the top-level source directory, say by creating $topdir/objdir
and running ../configure from the objdir directory, the --with-submitter
and --with-organization configure flags end up getting ignored.

I've got a fix for this...which basically involves removing all
references to the DEFAULT_ORGANIZATION and SUBMITTER macros from the
$topdir/gnats build files - thereby preventing the config-send-pr
target from screwing things up for send-pr.

I've also got a patch for the doc/Makefile.in so that no attempt
is made to build the info targets if the 'makeinfo' program cannot
be found.

Finally, it'd be really cool if we could add 'make test' to the
build/install process. The real difficulty in achieving this, IMO,
is that there's no way to run gnatsd without first installing it
...since it looks for the databases file. Perhaps adding a command
line switch to gnatsd for specifying the path to the databases
file would work around this limitation.

I've put together a regression test suite which I may be able to
work into the build process. Unfortunately, it uses a small perl
component for setting up the database which will need to be
reworked as a shell script.

> 
>         (Committed this to CVS two days ago.)
>       2.Add missing manpages -- one manpage for each application
>         Added: Fri Jun 11 11:11:57 2004  Completed: incomplete
>         Duration: incomplete  Priority: high
> 
>       3.Kill install-sid script and update documentation
>         Added: Fri Jun 11 11:09:17 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>       4.Update Documentation: Set developer's policy.
>         Added: Fri Jun 11 14:45:45 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

All the above are good. I need to dig around...I have many bug
fixes to provide. Since they've been made in the context of the
gnats-dbi project I've been working on, it's going to be a little
bit of a hassle finding them all and putting patches together.

> 
>   2.Release 4.2: New Features
>     Added: Fri Jun 11 10:37:02 2004  Completed: incomplete
>     Duration: incomplete  Priority: medium
> 
>       1.Mail handling enhancements
>         Added: Fri Jun 11 14:48:24 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>           1.Mail-based manipulation of GNATS database (Mel)
>             Added: Fri Jun 11 14:49:11 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium
> 
>           2.Trigger-based mail format replies (Mel)
>             Added: Fri Jun 11 14:49:28 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium
> 
>           3.Enable To: address@bogus.example.com syntax to queue-pr
>             Added: Fri Jun 11 14:49:40 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium

I'm not clear on #3...can you elaborate.

Also, I've recently implemented something else you might find
valuable...it's a filter which you can apply to a mail-format
for limiting the list of recipients. This is useful in the
context of a view into the PR database...which is possible
with the Oracle backend.

e.g. You might allow a certain class of user to create PRs
but wish to prevent that class of user from receiving particular
GNATS mail notifications.

The feature is also useful in preventing mail loops.

The dbconfig syntax (which is entirely optional) is as follows:

mail-filter "foo" {
     # don't allow email to fred
     deny "^fred.*"
     # allow foo internal email addresses
     allow "[[:alnum:]._-]\+(@foo\.com)\?$"
     # all other email addresses are disallowed
     policy deny
}

mail-format "initial-response-to-submitter" {
     trigger on-create "Category!=\"sw-tools\""
     ...other mail-format elements
     apply-filter "foo"
     ...other mail-format elements
}

The above example would restrict the initial-response-to-submitter
notification so that it would only go to users with a foo email
address (or a non-qualified/internal address).

> 
>       2.MIME Handling
>         Added: Fri Jun 11 14:50:49 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>           1.Detach files appropriately for GNATS DB format
>             Added: Fri Jun 11 14:51:48 2004  Completed: incomplete
>             Duration: incomplete  Priority: high
> 
>           2.Convert HTML to TXT?
>             Added: Fri Jun 11 14:51:15 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium

I like these...I started scoping this using the MIME::Parser and
MIME::Decoder perl modules but didn't get very far. MIME handling
could also support an attachment feature which I would love to
see added to the project.

> 
>   3.Release 5.0: New Features, Major Changes to DB Layer, RDBMS
>     Added: Fri Jun 11 10:37:07 2004  Completed: incomplete
>     Duration: incomplete  Priority: medium
> 
>       1.Database Enhancements
>         Added: Fri Jun 11 14:53:57 2004  Completed: incomplete
>         Duration: incomplete  Priority: high
> 
>           1.DB Abstraction Layer (Mel)
>             Added: Fri Jun 11 14:52:27 2004  Completed: incomplete
>             Duration: incomplete  Priority: high
> 
>           2.Oracle RDBMS Backend
>             Added: Fri Jun 11 14:52:39 2004  Completed: incomplete
>             Duration: incomplete  Priority: high

You might want to add PostgreSQL as a 3rd item. I've started putting
this together.

The development for the Oracle backend is pretty much done...we've been
using it at Juniper for about a year and no additional effort has
been required. This will largely be a matter of review and integration.

A 4th item for Release 5.0 features might be support for transactions.
After doing away with the need for a global gnats lock (using the
Oracle backend), it has become an interesting challenge to see how
far one can go in removing the need for a user to take out a PR lock.
In organizations with large user bases and large numbers of PRs,
the current method of having an edit client lock the PR is sub-optimal.

> 
>       2.Mail handling enhancements
>         Added: Fri Jun 11 14:55:10 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>           1.Maintain mbox archive of all emails
>             Added: Fri Jun 11 14:55:27 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium
> 
>           2.Fake Audit trail entries as emails and append to mbox archive
>             Added: Fri Jun 11 14:55:41 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium
> 
>           3.Continue to use existing PR datafile for logging events, keywords, and metadata
>             Added: Fri Jun 11 14:55:58 2004  Completed: incomplete
>             Duration: incomplete  Priority: medium
> 
>       3.Account enhancements
>         Added: Fri Jun 11 14:56:29 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>           1.PAM Authentication (Pankaj)
>             Added: Fri Jun 11 14:56:45 2004  Completed: incomplete
>             Duration: incomplete  Priority: high
> 
>             (Pankaj expressed interest in this on 2004-06-14)
>   4.Unassigned
>     Added: Fri Jun 11 13:50:51 2004  Completed: incomplete
>     Duration: incomplete  Priority: medium
> 
>       1.Add squirrels, to make pst happy.
>         Added: Fri Jun 11 14:42:32 2004  Completed: incomplete
>         Duration: incomplete  Priority: high
> 
>       2.Add conditional formats
>         Added: Fri Jun 11 13:56:21 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Need more information - what is this?

> 
>       3.Add script hooks, probably for edit formats and such.  Need to think about how to
>         integrate in changes to the PR done by the script
>         Added: Fri Jun 11 13:57:38 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Ahh, script hooks. This would be extremely valuable.

> 
>         (after all, that's really the whole point)
>       4.Allow fields to not exist; add a "field-always-present" option to the field description
>         Added: Fri Jun 11 13:58:17 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 

Need more information - what is this?

While we're here, together with a work colleague, we've revised the way
'required' fields are implemented. Our primary motivation was to simplify
the way they're expressed in the dbconfig and also to enhance the validation
logic (check_pr) so that missing required field errors are caught prior to a
PR being submitted.

This feature does away with the requirement to have an "on-change { require }"
clause in each required field along with a "require { field }" clause in the
initial-fields section of the dbconfig. These are replaced with a simple
"required" flag in the field definition.

We're adding an optional condition to this flag...so that it's possible
to have conditional required fields. The value of doing it this way
is that the dbconfig syntax required for defining a required field is
localized to the field definition and not spread out in different
areas of the dbconfig. This makes it very easy to follow the "required
field logic" in the dbconfig and assists the GNATS administrator in
preventing errors.

>       5.Add virtual fields.
>         Added: Fri Jun 11 13:59:28 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>         (The output format can use the existing format mechanism. This would necessitate having a
>         "no-display" field flag, so that some fields don't show up in a "full" query (adding all
>         the fields to full" is a rather obnoxious requirement).  There should also be a "raw"
>         query that dumps all the real fields as raw contents, for editing purposes (and perhaps
>         for other things).)
>       6.Revise access control mechanisms.
>         Added: Fri Jun 11 14:39:12 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Cool...I think this would be a valuable endevour.

> 
>       7.Should PRs have a ">Database-Name:" header?  Probably, and probably immutable.  Can be
>         used when editing a PR, or submitting an initial one.
>         Added: Fri Jun 11 14:39:27 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Hmmm, this reminds me of another feature I've been considering.
It'd be valuable to investigate the use of non-numeric PR ids.
For example, a 3 letter prefix to the PR number might provide
a useful way to route PRs to a specific GNATS database.

> 
>       8.Append-only fields.  Need to revise access control first.
>         Added: Fri Jun 11 14:40:05 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>       9.Document functions.  Many of them are undocumented (even newly-added ones, shame).
>         Added: Fri Jun 11 14:41:10 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>      10.See how much farther we can go with removing knowledge of particular fields from the
>         gnats code.
>         Added: Fri Jun 11 14:42:03 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Yes...I think this would be a valuable endevour.

> 
>      11.Make it possible to include adm field contents in the configuration file, instead of
>         always using an external config file.
>         Added: Fri Jun 11 14:42:59 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

I'm not sure I see the benefit.

> 
>      12.The database state is not clean.  There should be a struct that describes the current
>         database, and is passed around as needed.
>         Added: Fri Jun 11 14:43:22 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

Isn't this the DatabaseInfo struct?

> 
>      13.The client state is not clean.  The API is horrid; clients should not know or care if
>         they're communicating via the network or locally.  The original solution was to just
>         allow network access, but that's not really fixing the problem.  (We'll know we're there
>         when gnatsd can act as a relay.)
>         Added: Fri Jun 11 14:43:55 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium

localhost mode must die. If the original solution was to do away with localhost mode
and rely solely on network mode, why doesn't this fix the problem exactly?

> 
>      14.The client connection to the server should also be encapsulated in a struct as well. That
>         is, something to describe the client (its hostname, username, password, access level). 
>         Could eventually allow for a single server process that handles multiple connections.
>         Added: Fri Jun 11 14:44:32 2004  Completed: incomplete
>         Duration: incomplete  Priority: medium
> 
>      15.Change edit-pr to include the "Changed-Why:" header in the initial PR template instead of
>         a separate prompt.  Maybe.
>         Added: Fri Jun 11 14:24:46 2004  Completed: incomplete
>         Duration: incomplete  Priority: low

Or, at least bounce the user into a second edit session to specify the reason.
The current method of prompting the user for the reason provides no avenue of
escape if the user decides they want to change a line above.

> 
>      16.Should all the fields listed in the input section be required? Configurable? How about
>         rejecting initial erroneous PRs (PRs with bad fields) instead of fixing them up? It sucks
>         that pr-edit --submit < /dev/null could quite presumably create a valid PR.
>         Added: Fri Jun 11 14:25:50 2004  Completed: incomplete
>         Duration: incomplete  Priority: low

I would argue that they should *not* all be required. Configurable yes...this is
essentially what I described above in #4 I believe.

> 
>      17.The initial PR filing stuff is way too complicated.  In particular, the various field
>         checks should be configured in dbconfig.  That would let us remove more builtin fields.
>         Added: Fri Jun 11 14:38:18 2004  Completed: incomplete
>         Duration: incomplete  Priority: low

Yep. Anything we can do to remove the builtin fields is worthwhile.

> 
>      18.Decide if the "exec gnatsd locally" option is a security hole.  (Probably.) Make it #if
>         TESTING only?
>         Added: Fri Jun 11 14:38:30 2004  Completed: incomplete
>         Duration: incomplete  Priority: low
> 
>      19.Come up with a better name for the lexer source file.
>         Added: Fri Jun 11 14:41:35 2004  Completed: incomplete
>         Duration: incomplete  Priority: low
> 

I've grown rather fond of fconfigl.l ;-)

Extending on these unassigned items, it'd be wothwhile considering how one might
go about creating dynamic views - i.e. to narrow down on applicable field values based
on the selection of other field values. As an example, when class is set to 'hw-bug'
only show the h/w categories to the user. This would obviously be handled (or not)
by the client, however, before considering how the client does this, we should
consider how we can capture the necessary information to allow the client to
implement this. I think the dbconfig would be the right place to capture this
and have some ideas about how this might be expressed (which build on the filtering
idea I presented above for mail-format recipients).

Finally, it's also worthwhile considering a PR version feature. Often times, a PR
manifests itself differently on different platforms, or is in different states for
different releases. I've put together a rough draft of a design document for
how this might be done...which I'd be happy to share with you after I review it a
few more times.

--
Mel Hatzis


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: The TODO list and planning a release schedule
  2004-06-20 16:43 ` The TODO list and planning a release schedule Mel Hatzis
@ 2004-06-20 17:06   ` Chad Walstrom
  0 siblings, 0 replies; 4+ messages in thread
From: Chad Walstrom @ 2004-06-20 17:06 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 13734 bytes --]

Mel Hatzis wrote:
> While we're here, if you try building from a directory other than the
> top-level source directory, say by creating $topdir/objdir and running
> ../configure from the objdir directory, the --with-submitter and
> --with-organization configure flags end up getting ignored.
> 
> I've got a fix for this...which basically involves removing all
> references to the DEFAULT_ORGANIZATION and SUBMITTER macros from the
> $topdir/gnats build files - thereby preventing the config-send-pr
> target from screwing things up for send-pr.

The fixes are certainly welcome.  I'm not the most familiar with
autoconf scripts, but I have a feeling I'll become much more intimately
knowledgeable in the near future. ;-) I think there could definitely be
some improvement and streamlining to the build process.  I always found
it confusing why we have multiple configure scripts instead of just one.
Something to look at, anyway.

> I've also got a patch for the doc/Makefile.in so that no attempt is
> made to build the info targets if the 'makeinfo' program cannot be
> found.

Excellent.

> Finally, it'd be really cool if we could add 'make test' to the
> build/install process. The real difficulty in achieving this, IMO, is
> that there's no way to run gnatsd without first installing it ...since
> it looks for the databases file. Perhaps adding a command line switch
> to gnatsd for specifying the path to the databases file would work
> around this limitation.

Great suggestion!  I would suggest these types of feature enhancements
go into the 4.2 release.

> I've put together a regression test suite which I may be able to work
> into the build process. Unfortunately, it uses a small perl component
> for setting up the database which will need to be reworked as a shell
> script.

Cool.

> > 2.Add missing manpages -- one manpage for each application
> > 3.Kill install-sid script and update documentation 
> > 4.Update Documentation: Set developer's policy.
> 
> All the above are good. I need to dig around...I have many bug fixes
> to provide. Since they've been made in the context of the gnats-dbi
> project I've been working on, it's going to be a little bit of a
> hassle finding them all and putting patches together.

Take your time.  Unless it's a critical functionality fix, security fix,
or simple fix, it should probably be moved to later releases anyway.

> >  2.Release 4.2: New Features
> >      1.Mail handling enhancements
> >          1.Mail-based manipulation of GNATS database (Mel)
> >
> >          2.Trigger-based mail format replies (Mel)
> >          14:49:28 2004 
> >          Priority: medium
> >
> >          3.Enable To: address@bogus.example.com syntax to queue-pr
> >         
> >          Duration: incomplete  Priority: medium
> 
> I'm not clear on #3...can you elaborate.

The listserver munged the email address.  Let's try it in a way it won't
easily recognize my intention:

    prnumber-AT-domain-DOT-tld

I would love to queue off the PR number directly, the same way that the
Debian BTS handles bug tracking.  It's far, far easier to parse a number
than subject lines.  The whole "CATEGORY/PRNUMBER:" is difficult for me
to sell, even our staff.  I have one co-worker who refuses to send email
to help--at--domain--dot--tld because she can never remember (refuses to
remember) that syntax requirement.  Were I to CNAME the bug server and
send to prnumber-AT-help-DOT-domain-DOT-tld

> Also, I've recently implemented something else you might find
> valuable...it's a filter which you can apply to a mail-format for
> limiting the list of recipients. This is useful in the context of a
> view into the PR database...which is possible with the Oracle backend.

Sweet. ;-)

> >      2.MIME Handling
> >          1.Detach files appropriately for GNATS DB format
> >          2.Convert HTML to TXT? 
> 
> I like these...I started scoping this using the MIME::Parser and
> MIME::Decoder perl modules but didn't get very far. MIME handling
> could also support an attachment feature which I would love to see
> added to the project.

I would love to leverage the GNU Mailutils project for these
mail-handling libraries.  Perhaps item 2.2. should be titled "MIME
Filtering" so we could define rules based on MIME type of the
submission.  Additionally, these MIME features could be held off until
after your big DB abstraction and rolling in your existing fixes and
features.  Let's take advantage of what we have before extending our
reach too far.

> >  3.Release 5.0: New Features, Major Changes to DB Layer, RDBMS
> >      1.Database Enhancements
> >          1.DB Abstraction Layer (Mel)
> >          2.Oracle RDBMS Backend
> 
> You might want to add PostgreSQL as a 3rd item. I've started putting
> this together.

Will do.

> The development for the Oracle backend is pretty much done...

Sweet!

> A 4th item for Release 5.0 features might be support for transactions.
> After doing away with the need for a global gnats lock (using the
> Oracle backend), it has become an interesting challenge to see how far
> one can go in removing the need for a user to take out a PR lock.  In
> organizations with large user bases and large numbers of PRs, the
> current method of having an edit client lock the PR is sub-optimal.

Should we hold this off until 5.1, or do you think this support could be
rolled in with the DB changes you've already made?

> > 4.Unassigned
> >      1.Add squirrels, to make pst happy. 
> >      2.Add conditional formats
>
> Need more information - what is this?

Honestly, I don't know.  All of these "Unassigned" items were in the old
TODO list.  I didn't even go over them in detail.  If some of the
old-school developers could pipe in, we may gain some more insight.  If
I had to guess, I'm assuming that conditional formats may mean
flow-control logic.  if-then-else and while-do statements?  Not sure if
this is needed.

> >      3.Add script hooks, probably for edit formats and such.  Need
> >      to think about how to integrate in changes to the PR done by
> >      the script
> 
> Ahh, script hooks. This would be extremely valuable.

*NOD*

> > 4.Allow fields to not exist; add a "field-always-present" option to
> >   the field description
> 
> Need more information - what is this?

Again, not sure.  I'm assuming that it's an implication toward the
database format itself.  There are many fields that we don't touch as a
Help-Center tool.  We just want to know the Originator, a description of
the problem, and have a way to assign the problem to techs.  Since we're
not doing Accounts Receivable, trying to track time, or categorizing bug
types (much), a slimmed down database would really help.

> While we're here, together with a work colleague, we've revised the
> way 'required' fields are implemented. Our primary motivation was to
> simplify the way they're expressed in the dbconfig and also to enhance
> the validation logic (check_pr) so that missing required field errors
> are caught prior to a PR being submitted.
> 
> This feature does away with the requirement to have an "on-change {
> require }" clause in each required field along with a "require { field
> }" clause in the initial-fields section of the dbconfig. These are
> replaced with a simple "required" flag in the field definition.
>
> We're adding an optional condition to this flag...so that it's
> possible to have conditional required fields. The value of doing it
> this way is that the dbconfig syntax required for defining a required
> field is localized to the field definition and not spread out in
> different areas of the dbconfig. This makes it very easy to follow the
> "required field logic" in the dbconfig and assists the GNATS
> administrator in preventing errors.

Sweet!  Yet another Mel & Co addition that I'd love to have in 5.0.

> >      7.Should PRs have a ">Database-Name:" header?  Probably, and
> >      probably immutable.  Can be used when editing a PR, or
> >      submitting an initial one. 
> 
> Hmmm, this reminds me of another feature I've been considering.  It'd
> be valuable to investigate the use of non-numeric PR ids.  For
> example, a 3 letter prefix to the PR number might provide a useful way
> to route PRs to a specific GNATS database.

Or simply a UUID generated hash, but then that gets to be too
"difficult" for end-users to deal with.  Although a 3-letter prefix
specific to the database may be useful when routing PR's for multiple
databases through the same host name in emails.

    To: pfx-prnumber--at--host-domain-tld OR
    Subject: PFX-PRNUM: Blah blah blah

The cagetory is mostly useless for determining what identity of the PR
is.

> >     11.Make it possible to include adm field contents in the
> >     configuration file, instead of always using an external config
> >     file. 
> >     Duration: incomplete  Priority: medium
> 
> I'm not sure I see the benefit.

I agree.  Perhaps someone could shed some light on this one?

> >
> >     12.The database state is not clean.  There should be a struct
> >     that describes the current database, and is passed around as
> >     needed. 
> >     Duration: incomplete  Priority: medium
> 
> Isn't this the DatabaseInfo struct?

Probably a legacy TODO that didn't get scratched off the list.  I'll
remove it.

> >     13.The client state is not clean.  The API is horrid; clients
> >     should not know or care if they're communicating via the network
> >     or locally.  The original solution was to just allow network
> >     access, but that's not really fixing the problem.  (We'll know
> >     we're there when gnatsd can act as a relay.)
> >     14:43:55 2004 
> >     Priority: medium
> 
> localhost mode must die. If the original solution was to do away with
> localhost mode and rely solely on network mode, why doesn't this fix
> the problem exactly?

Again, not sure.  Anyone?  I don't see any reason why a local client
can't talk to gnatsd through the local loopback device.  I don't know of
a modern operating system that doesn't work perfectly well this way.
IMHO, the clients should only operate through the daemon.  Let the
daemon handle locking issues and file permissions rather than relying
upon client knowledge of the filesystem.  We can take a closer look at
this and see what the current state of the code is.

> >     15.Change edit-pr to include the "Changed-Why:" header in the
> >     initial PR template instead of a separate prompt.  Maybe.
> 
> Or, at least bounce the user into a second edit session to specify the
> reason.  The current method of prompting the user for the reason
> provides no avenue of escape if the user decides they want to change a
> line above.

Integrating libreadline into console clients would help this out.  Allow
the user to decide when to enter an external editor (i.e. the 'v' key in
vi editing-mode).

> >     16.Should all the fields listed in the input section be
> >     required?  Configurable? How about rejecting initial erroneous
> >     PRs (PRs with bad fields) instead of fixing them up? It sucks
> >     that pr-edit --submit < /dev/null could quite presumably create
> >     a valid PR. 
> >     incomplete Duration: incomplete  Priority: low
> 
> I would argue that they should *not* all be required. Configurable
> yes...this is essentially what I described above in #4 I believe.

Agreed.  Should I kill this one, then?

> >     17.The initial PR filing stuff is way too complicated.  In
> >     particular, the various field checks should be configured in
> >     dbconfig.  That would let us remove more builtin fields. 
> 
> Yep. Anything we can do to remove the builtin fields is worthwhile.

Agreed.

> I've grown rather fond of fconfigl.l ;-)

;-)

> Extending on these unassigned items, it'd be wothwhile considering how
> one might go about creating dynamic views - i.e. to narrow down on
> applicable field values based on the selection of other field values.
> As an example, when class is set to 'hw-bug' only show the h/w
> categories to the user. This would obviously be handled (or not) by
> the client, however, before considering how the client does this, we
> should consider how we can capture the necessary information to allow
> the client to implement this. I think the dbconfig would be the right
> place to capture this and have some ideas about how this might be
> expressed (which build on the filtering idea I presented above for
> mail-format recipients).
> 
> Finally, it's also worthwhile considering a PR version feature. Often
> times, a PR manifests itself differently on different platforms, or is
> in different states for different releases. I've put together a rough
> draft of a design document for how this might be done...which I'd be
> happy to share with you after I review it a few more times.

Good idea.

I think we should probably include a discussion document on planned
features that correlate to the TODO list.  DevTodo is a pretty nice
piece of software to manage lists, but it does have a way to go before
it's comment feature is well integrated.  Perhaps a TODO.Discuss or
TODO.Readme to which developers could add the "Why's" and "How's" would
be valuable.  I know not everyone is proficient with texinfo format
docs, but we could push these reasons into gnats-dev.texi document.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-06-17 16:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-17  9:24 The TODO list and planning a release schedule Chad Walstrom
2004-06-17 16:48 ` CVS Branching and Merging Chad Walstrom
2004-06-20 16:43 ` The TODO list and planning a release schedule Mel Hatzis
2004-06-20 17:06   ` Chad Walstrom

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).