[whups] Using whups moving forward

[Mike Baptiste]

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

Gary Weinreb wrote:

| Mike,
|
| It's nice to see your post.  I divide my time between Durham and
| Charlotte, so perhaps as our mutual Whups-based projects progress we can
| meet in Durham and chat...
|
Sure!  Let me know next time you're in town (mike.baptiste@duke.edu)

| Are you specifically looking at using Whups for "Bug Tracking"? or are
| you interested in using it for other things?


Both.  We want to use it as our main IT Support trouble ticket system
(trouble tickets, install requests, special projects, etc)  This will be
our first implementation.  We might even use it for facilities requests
which aren't much different than IT requests.

We also want to use it to track bugs in any custom software we write
(web apps, OSS stuff, etc)  Expanding beyond bugs, we have ideas ot use
horde and many of its packages as a Sourceforge like environment for our
projects here in the engineerring school and perhaps elsewhere at Duke.

| This seems similar to why I'm interested in some sort of templating
| mechanism.  I, as you may have gathered, am very interested in modifying
| Whups for Project/Workflow Management.  I have recurring Clients and
| Projects, and I don't want to have my users recreate States, Priorities,
| Responsible Users, People to Notify, etc. over and over again...

I think there is potential here.  One of the nice things with Scarab was
you created a type of issue and could use it in ANY module.  With all
the states and such.  I like the idea of being able to let folks choose
their states and priorities for bug reports for their own development
project in our system, but the option to inhierit them from a root
'object' would be nice - and change them if you like.  The problem here,
of course, is queries and reporting.  This isn't a HUGE issue, buut for
reportrting and such its nice to have qualifiers like platform, OS, etc.
~ We also might like to have the Cc: concept from Bugzilla so folks can
become 'listeners'  From the code I've seen this seems reasonably easy
(the table's already in the DB - maybe the code is already started.  /me
plans to look)

|
| > What are the plans for email notifications ala, ticket changes and
|
| It seems that Chuck is rolling ahead in fleshing out the Permissions and
| Notification stuff.  I'm looking forward to seeing what he comes up
| with...

Me too.  I really like the current implementation but hope we can make
it more granular and perhaps come up with a more direct link to non SQL
backend authentication.  For example, I'm using imp for authentication
since Duke's email system uses a central kerberos system to
authenticate.  We could use the K5 library backend, but some users have
their own mail servers - so the email auth over SSL POP/IMAP is the best
option for us right now.  So when a user logs in, if their email address
isn't set in IMP and they use whups beyond reading (ie add comments) you
are prompted for an email address (or maybe have an option where we take
their userid which IS the userid@domain email address)  Easy enough to do.

| That's me.  Glad you like.  I'd like to hear how you are thinking about
| using Whups.  Maybe you can help shape my ideas towards a solution that
| will serve you as well...

I think the appeal of this for us was related to using Chora, WHups,
Natg, and others to make a code development environment - I see huge
potential here since so much is already 'done'.  The idea being we
create a code 'repository' that creates a user group which is then used
for prefs and authorization needs across the various horde packages.
Kind of a SourceForge on steroids with a coherent interface and GUI
across all modules.

| > Am I totally off base here?
|
| I don't think so.  As a relative newcomer to the Horde project, but with
| 20+ years of IT consulting experience, I think this is a very serious
| solution to a broad spectrum of IT needs.  As a framework it is very
| flexible and easily scalable, two attributes I look for...  I have
| always preferred having source code to software that I haven't written,
| but which am responsible for implementing.

I agree.  I've always liked IMP - still believe its best in class.  Then
I fell for Chora and realized the power of the framework - obvious for
folks who are heavily involved in development here, but for me its a
matter of being able to take something that's already there and extend
it as Horde really seems to be the best combination.

But that's all find and dandy - right now I need to get an issue tracker
going :)  Off to play in whups code!

Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9xv2Utbf8BjvL+3ERArsEAJwI/8HsJ7y0jtQOZZFru8PMBcv2eQCgoHoz
SRXDLfPqVfTzaRSNmJtX5uw=
=KMqY
-----END PGP SIGNATURE-----