From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29371 invoked from network); 17 Jun 2004 16:48:22 -0000 Received: from unknown (HELO lists.gnu.org) (199.232.76.165) by sourceware.org with SMTP; 17 Jun 2004 16:48:22 -0000 Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bb04t-0002iy-Bz for listarch-gnats-devel@sources.redhat.com; Thu, 17 Jun 2004 12:49:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bb04n-0002iY-Up for help-gnats@gnu.org; Thu, 17 Jun 2004 12:49:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bb04k-0002gT-RB for help-gnats@gnu.org; Thu, 17 Jun 2004 12:49:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bb04k-0002gJ-NQ for help-gnats@gnu.org; Thu, 17 Jun 2004 12:49:18 -0400 Received: from [199.199.210.160] (helo=chef.nerp.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bb02u-00037s-D8 for help-gnats@gnu.org; Thu, 17 Jun 2004 12:47:25 -0400 Received: from localhost (c-66-41-158-97.mn.client2.attbi.com [66.41.158.97]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by chef.nerp.net (Postfix) with ESMTP id 6A9D11FBAF for ; Thu, 17 Jun 2004 11:47:22 -0500 (CDT) Received: from chewie by localhost with local (Exim 4.32) id 1Bb02q-0007LI-3k for help-gnats@gnu.org; Thu, 17 Jun 2004 11:47:20 -0500 Date: Sun, 20 Jun 2004 17:06:00 -0000 From: Chad Walstrom To: help-gnats@gnu.org Message-ID: <20040617164719.GC21036@wookimus.net> Mail-Followup-To: help-gnats@gnu.org References: <20040615192846.GG19638@wookimus.net> <40D162AB.2030909@juniper.net> Mime-Version: 1.0 In-Reply-To: <40D162AB.2030909@juniper.net> X-Operating-System: Linux skuld 2.6.4-k7 X-GnuPG-Fingerprint: B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD Keywords: none User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: Re: The TODO list and planning a release schedule X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: General discussion about GNU GNATS List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0614194980==" Sender: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org Errors-To: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org X-SW-Source: 2004-q2/txt/msg00172.txt.bz2 --===============0614194980== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 13497 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. >=20 > 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=20 > > 4.Update Documentation: Set developer's policy. >=20 > 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=20 > > Priority: medium > > > > 3.Enable To: address@bogus.example.com syntax to queue-pr > >=20=20=20=20=20=20=20=20=20 > > Duration: incomplete Priority: medium >=20 > 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?=20 >=20 > 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 >=20 > 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.=20 > > 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 >=20 > 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 >=20 > 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. >=20 > 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.=20 >=20 > 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.=20 > > Duration: incomplete Priority: medium >=20 > 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.=20 > > Duration: incomplete Priority: medium >=20 > 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=20 > > Priority: medium >=20 > 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. >=20 > 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.=20 > > incomplete Duration: incomplete Priority: low >=20 > 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.=20 >=20 > 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). >=20 > 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. --=20 Chad Walstrom http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0csXDMcLGCBsWv0RAk3uAKCqaKP/PAsdMkn62rtDtNNgNDaqUwCePxtM 2YrhdUSjhyFggR7bVdL1y3g= =HjsW -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- --===============0614194980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 140 _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats --===============0614194980==--