[whups] Re: library conventions and state of play

[Chuck Hagenbuch]

Quoting Anil Madhavapeddy <anil@recoil.org>:

> Now, we have another kind of diff that can use the same data format
> (the strike-through diff), so it does make a lot more sense to shift the
> logic over to CVSLib_diff(View)_* classes and bundle up the presentation.

You're the master. =)

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"If you can't stand the heat, get out of the chicken!" - Baby Blues


>From anil@recoil.org Date: Thu,  4 Jan 2001 13:50:15 +0000
Return-Path: <anil@recoil.org>
Mailing-List: contact whups-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list whups@lists.horde.org
Received: (qmail 89100 invoked from network); 4 Jan 2001 13:50:18 -0000
Received: from total.recoil.org (212.25.240.40)
  by horde.org with SMTP; 4 Jan 2001 13:50:18 -0000
Received: (qmail 21301 invoked by uid 99); 4 Jan 2001 13:50:15 -0000
Received: from m175-mp1-cvx1a.lis.ntl.com ( [m175-mp1-cvx1a.lis.ntl.com])
	as user avsm@localhost by horde.recoil.org with HTTP;
	Thu,  4 Jan 2001 13:50:15 +0000
Message-ID: <978616215.3a547f978a602@horde.recoil.org>
Date: Thu,  4 Jan 2001 13:50:15 +0000
From: Anil Madhavapeddy <anil@recoil.org>
To: Cadden@ireland.com
Cc: whups@lists.horde.org
References: <5F493CE2122E4D115AB50005B8AC93DD@Cadden.ireland.com>
In-Reply-To: <5F493CE2122E4D115AB50005B8AC93DD@Cadden.ireland.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.6-cvs
Subject: Re: 

Quoting Cadden@ireland.com:

> A feature request (Wish List) is a request by either developers or 
> users of Extra features that a program might do and accepted requests 
> could be the added and generate a To Do list or Development roadmap 
> like http://www.phpslash.org/roadmap.php.
> 
> If a feature request is accepted a CVS fork is created to work on it 
> and when debugged and functional, it is then added in the main cvs 
> build and also in additional feature database and linked to the 
> original feature request thus creating a clear Picture 
> of the project Developement cycle. 

Hmm yeah, I've worked on projects that use this methodology, and I'd
be very reluctant to apply it as a generalisation to all projects
that would be used alongside WHUPS.

It works _really_ well if the project has been engineered well from
the start, and every developer has a clear set of UML/viz objects in
front of them to figure out what is going on.  That way, CVS branches
can persist for a length of time without creating massive conflicts
with other ones.

For example, if one feature request requires a fundamental re-design
of an API, that requires a great deal of communication with all the
other developers to ensure that their own feature branches work without
getting massively out of sync.  In open-source projects, this simply
isn't feasible; in Horde's case for example, the changes are 'just made'
and other features adapted to work with the new API.  Perhaps this is
weak from a specification->rollout lifecycle point of view, but I
doubt we have the resources to pull this off.

> I understand that but I remember reading a mail saying you would 
> welcome developers to help on the bugzilla part. 
> Give them mail to see if their interested in joining forces in 
> fowarding your impressive goal.
> I would like to help myself but I'm in the middle of exams at the 
> moment and php experience is still poor.

This is a good point; however, we aren't in a very good state to 
invite people to look at what we have, since we don't have very
much at the moment ;-)  

I'd like to kick off discussion now as to what we want WHUPS to be.
Personally, I don't think it's healthy to have it all integrated
in one, as is currently perceived to be the case.

Horde modules at the moment have one purpose, and they aim to fulfill
that as well as possible.  However, Project views, Bug tracking,
a FAQ-O-Matic, and CVS viewer are all wildly different, and could
survive very well as separate modules.

I view Horde as being the 'glue' that provides the integration and
possibility of interaction between these modules, via the registry
and the other objects.  So what do people think about saving WHUPS
for the ticket-tracking system, and moving the CVS viewer and 
FAQ system to other modules?

> 
> BTW: Another feature I was wondering could you create a php class to 
> generate a tar.gz file of a cvs repositiory using 
> http://www.php.net/manual/ref.zlib.php when you click on 
> a repository folder for instance.

That is actually already on my TODO list, but my initial prototype
placed a huge load on the web server when retrieving a given tag
(since it had to iterate through the entire directory tree).  This
_really_ depends on having a caching backend to make the queries
a bit less painful.

I'll place a TODO.CVS file in the WHUPS directory with this, and my
other half-baked ideas that have survived in my brain so far without
being committed :)  I had the branch-viewer brewing for ages and took
ages to get around to it.

> 
> As from your about page it is unclear how the merged cvs, bugzilla 
> and Faq-o-matic will interact.
> Sorry for bonbarding you with all these requests and questions, 
> sometimes I get over entusiastic. :)
> 

Interest is good!  Please keep the ideas and input coming so we can
kickstart this off!  As for how bugzilla, cvs and faq-o-matic will
interact - I have no idea either!

-- 
Anil Madhavapeddy, <anil@recoil.org>


>From chuck@horde.org Date: Thu,  4 Jan 2001 10:29:05 -0500
Return-Path: <chuck@horde.org>
Mailing-List: contact whups-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list whups@lists.horde.org
Received: (qmail 11534 invoked from network); 4 Jan 2001 15:29:53 -0000
Received: from r93aag000369.sbo-smr.ma.cable.rcn.com (HELO marina.horde.org) (209.6.192.126)
  by horde.org with SMTP; 4 Jan 2001 15:29:53 -0000
Received: by marina.horde.org (Postfix, from userid 33)
	id A17DC3974; Thu,  4 Jan 2001 10:29:05 -0500 (EST)
Received: from 206.243.191.252 ( [206.243.191.252])
	as user chuck@marina by marina.horde.org with HTTP;
	Thu,  4 Jan 2001 10:29:05 -0500
Message-ID: <978622145.3a5496c18aabd@marina.horde.org>
Date: Thu,  4 Jan 2001 10:29:05 -0500
From: Chuck Hagenbuch <chuck@horde.org>
To: whups@lists.horde.org
References: <5F493CE2122E4D115AB50005B8AC93DD@Cadden.ireland.com> <978616215.3a547f978a602@horde.recoil.org>
In-Reply-To: <978616215.3a547f978a602@horde.recoil.org>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.6-cvs
Subject: Re: [whups] Re: 

Quoting Anil Madhavapeddy <anil@recoil.org>:

> For example, if one feature request requires a fundamental re-design
> of an API, that requires a great deal of communication with all the
> other developers to ensure that their own feature branches work without
> getting massively out of sync.  In open-source projects, this simply
> isn't feasible; in Horde's case for example, the changes are 'just made'
> and other features adapted to work with the new API.  Perhaps this is
> weak from a specification->rollout lifecycle point of view, but I
> doubt we have the resources to pull this off.

Yeah... speaking about Horde specifically, well, I'm not _too_ ashamed that the 
system was NOT well designed from the start. Horde grew out of IMP and 
realizing that we'd written some code for IMP that would be useful for other 
webapps. The whole thing has "grown" in a rather organic fashion from there. 
One of my main goals right now with the cvs branches is to get everything 
sorted out into a set of sane APIs, and to make those APIs as robust as 
possible, in order to make the whole thing more suitable for use in the long 
term. Unfortunately, it means breaking a lot of stuff as I go. =)

> I view Horde as being the 'glue' that provides the integration and
> possibility of interaction between these modules, via the registry
> and the other objects.  So what do people think about saving WHUPS
> for the ticket-tracking system, and moving the CVS viewer and 
> FAQ system to other modules?

I agree with you. To get to where I sort of envisioned this being, it's going 
to take a much better implementation of the Registry than we currently have, 
but that's okay; it needs to be done for other reasons as well.

Moving the FAQ system to another won't be a problem, as currently there's no 
faq system. =) Anil, if you decide on a name for the cvs viewer, I'll move the 
files in the repository so we don't lose any history...

> That is actually already on my TODO list, but my initial prototype
> placed a huge load on the web server when retrieving a given tag
> (since it had to iterate through the entire directory tree).  This
> _really_ depends on having a caching backend to make the queries
> a bit less painful.

Okay, let's talk about the caching backend: is the db schema that you mentioned 
earlier (from bonsai) going to handle this particular need? Is it absolutely 
reliant on having a database? Or could this be more general - either a general 
caching scheme, or a cvs caching scheme generalized over multiple backends?

But, really, I don't see any reason to try harder than necessary to avoid 
requiring a database for this. It might be nice if most things worked without 
any cache at all, but someone running a cvs repository is probably going to 
have a database available to them. So if generalizing it to more than "generic 
sql" is silly, forget it.

> Interest is good!  Please keep the ideas and input coming so we can
> kickstart this off!  As for how bugzilla, cvs and faq-o-matic will
> interact - I have no idea either!

Well, the things I had in mind were things like:

- when a user searches the faq, bug reports are also searched. This way people 
find out if a bug is open, or has already been fixed, with one search, instead 
of two.

- it should be easy to maintain a link to a revision of a file (ie, without 
hardcoding a full url - just the revision and filename), to be used for example 
in the bugs interface so that if you go to a closed bug, you get a link to the 
patch that fixed it.

... stuff like that.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"If you can't stand the heat, get out of the chicken!" - Baby Blues