Feature Wish List

Here are some of the dreams I have, either because I thought of them or because I didn't.

This list should be thought of the pre-tasklist, task list. When either someone voluntiers for taking on one of these dreams, or I think the time is right, dreams from here will but entered into the Source Forge task list and assigned.

Obviously, this page serves as a non-feature list.
That is it enumerates what MidWatch can't do, but could and should do.

In no particular order:

• FIFO kit deletion
  MidWatch generates setup kits and then copies them to some destination point, typically a network distribution point where developers and QA testers can install from. The trouble is that MidWatch doesn't delete kits, and they can fill the disk space to 100% and one day, the new kits are not distributed beacuse there is no room on the disk!
  Well, it would be nice if MidWatch counted the kits that were out there and knocked off the old kits when either the disk is at a certain percentage full, or a configureable number of kits are published (say 30), or kits reach a configureable age ( a month).
  Note there has to be some provision for marking important kits so that they are not deleted. (i.e. something that got shipped, or is likely to be shipped.)
• Estimated Time of Arrival Reporting
  This is a tricky one, I had written this in the original version of MidWatch, but it ain't in this one. Why? because I started from scratch when I joined BMC Software and this was not a core function to getting the build out.
  Well, what makes this tricky is that we have to count all of the time we spend doing things like label drops, view updates, builds, packaging etc. We have to have pretty high granularity to this, we have to store the information on a per product basis and then we want to have a moving average of this information say over 3-5 builds.
• Building of VB and Java Projects
  This shouldn't be too hard to do, I just haven't had the time yet. MidWatch builds project by project in a linear fashion. The architecture allows that a project could be something other than VC++. All we have to do is have something respond to a "This is a VB project" message so that we get out the VB complier and build the project. This way MidWatch would be capable of building your product though it has multiple computer language components.
• Automatic Report Generation
  i.e. write a build report, and e-mail it. Currently MidWatch has a realtime HTML report and I suppose we could e-mail that but I think that there are other details that could be sumarized and sent as an e-mail. My group likes e-mails, personally, I wonder why they don't just look at the real-time build report. I suppose the answer is simply "tradition" :)
• Conversion from DAO to ADO
  Rehan Khwaja pointed out that the use of DAO vice ADO limits MidWatch to using Access 97. A major overhaul on this point would allow Access 2000 to get in and modify the tables directly. I agree that this would be a great improvement.