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.
As of December 2000, this wish list will slowly be converted into
use cases for the version 0.5.xx MidWatch to
be written in C++. The design effort will be posted on this website for the
world to see.
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.