[Anil Madhavapeddy]

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>