midwatch-1mc Mailing List for MidWatch: Automated Build Engine
Status: Beta
Brought to you by:
woolhiser
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(14) |
Jun
|
Jul
(2) |
Aug
(8) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: gonmator <gon...@ol...> - 2002-05-07 16:07:55
|
Well, I do not have too much time, only a little. A little is more than nothing :) I can begin to translate the code to C++, if anybody want it, or I can wait for it and help in re-designing satabase. What do you think about it? Gonzalo. ----- Mensaje Original ----- De: "Woolhiser, Eric" <Eri...@bm...> Fecha: Martes, Mayo 7, 2002 3:50 pm Asunto: RE: [Midwatch-1mc] C++ status? > I haven't done very much at all with writing this in C++. > I have just returned to work after recovering from surgery, and > have some > other tasks ahead of developing Midwatch. > > I do welcome any help at all and would help you with any questions > you have. > > My current "thrust" in MidWatch's development is to modify the > Visual Basic > engine to use a shared data base on a MySQL server and a PHP > interface to > the database. > > At any time we could replace the VB with a C++ engine, how much > time do you > have? > > Getting back to my goals, what it means more than anything is to > re-design > the table structure of the database. We'd have to work out what > that would > be like. > > I can write C++ but my trouble has been getting along with COM in > C++. > Once the boiler plate of the C++ engine is written I can work on > it too, but > I need to acquire more technology understanding to get that > project started > myself. > |
From: Woolhiser, E. <Eri...@bm...> - 2002-05-07 13:50:47
|
I haven't done very much at all with writing this in C++. I have just returned to work after recovering from surgery, and have some other tasks ahead of developing Midwatch. I do welcome any help at all and would help you with any questions you have. My current "thrust" in MidWatch's development is to modify the Visual Basic engine to use a shared data base on a MySQL server and a PHP interface to the database. At any time we could replace the VB with a C++ engine, how much time do you have? Getting back to my goals, what it means more than anything is to re-design the table structure of the database. We'd have to work out what that would be like. I can write C++ but my trouble has been getting along with COM in C++. Once the boiler plate of the C++ engine is written I can work on it too, but I need to acquire more technology understanding to get that project started myself. > -----Original Message----- > From: gonmator [mailto:gon...@ol...] > Sent: Monday, May 06, 2002 12:06 > To: mid...@li... > Subject: [Midwatch-1mc] C++ status? > > > Hi All! > > I've arrived at Midwatch-1mc list now (and my english is some poor). I > am interested to cooperate to C++ version. > > What is the C++ design/implementation current status of MidWatch? I've > not found information about this propossed feature. > > Gonzalo. > > > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download > mirrors. We supply > the hardware. You get the recognition. Email Us: > ban...@so... > _______________________________________________ > Midwatch-1mc mailing list > Mid...@li... > https://lists.sourceforge.net/lists/listinfo/midwatch-1mc > |
From: gonmator <gon...@ol...> - 2002-05-06 23:58:12
|
Hi All! I've arrived at Midwatch-1mc list now (and my english is some poor). I am interested to cooperate to C++ version. What is the C++ design/implementation current status of MidWatch? I've not found information about this propossed feature. Gonzalo. |
From: Woolhiser, E. <Eri...@bm...> - 2002-02-16 00:30:07
|
Well I HAVE been coding. Check out http://phpsm.sourceforge.net . phpsm will be the basis of MidWatch's user authorization / session management system for the web console. As I have said before, I have to get this in place FIRST to make sure nobody messes with my database while I am developing code. It's nearly ready for me to use to develop MidWatch's web UI. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2002-02-01 15:58:43
|
Rommel Garcia Custodio wrote: >> >> You may have gathered that my new direction of development is to use >> MidWatch in combination with a MySQL server, and a PHP based web interface. >> Well, that also means I have to warm up to PHP and build some security >> infrastructure before I am ready to release any new code. > > i would gladly beta-test your releases. Well, I haven't even got the code through its first compile/syntax check yet let alone debug it. What I am doing right now is trying to write a session management class for PHP. I am also going to make it generic enough that it will be published on SourceForge as a separate module. Its appeal as a pure session manager will be broader than if I exclusively release it wrapped up in MidWatch code. Also, I'm no expert in SSL right now, if phpsm (PHP Session Manager) gets the eyes of some SSL savvy developer on it, we might truly get something secure later on down the road. Right now, I intend MidWatch to be deployed on a company intranet so the need for security is not terribly high, I just want to validate users so I can separate Product Managers, Developers, and Quality Assurance people from Build Meisters. Each group of people will have different rights and responsibilities in the MidWatch database. This has to be built as a foundation before I start writing the web interface (in PHP) and obsolete the VB GUI. Ideally, the MidWatch engine will be a headless service running on the build machine(s) and everything will be controlled by the MySQL/Apache server. |
From: Woolhiser, E. <Eri...@bm...> - 2002-02-01 14:23:40
|
> -----Original Message----- > From: Rommel Garcia Custodio [mailto:ro...@ci...] > Sent: Thursday, January 31, 2002 18:34 > To: Woolhiser, Eric > Subject: Re: Thanks for joining Midwatch-1mc > > > > > "Woolhiser, Eric" wrote: > > > > There hasn't been a lot of activity lately, because I have > been spending > > more time than I would like doing actual builds for my company and > > rebuilding servers. > > Presently, I am building 5 parallel branches of our > product, and any time > > there is a build failure, I have to hunt down the offending > developer and > > get it fixed. > > With five builds to watch, this happens almost every day. > However, this > > workload would not have been possible if it were not for MidWatch. > > > > I recognize that MidWatch is buggy in places, and horribly > difficult to > > configure the first time, but once it's in it works. > > i really havent setup it up yet as i dont have MS Access 97! :) > arrrrgh... > No trouble... read http://sourceforge.net/forum/forum.php?thread_id=26529&forum_id=12317 You can create an access2000 mdb and link your tables to the access 97 db. Works just fine. |
From: Woolhiser, E. <Eri...@bm...> - 2001-07-27 15:04:30
|
I'm stuck, so I thought I'd clue you into what I am working on. My objective is to get MidWatch to switch from using an Access 97 database on a local machine to using MySQL located on a remote Linux machine. There are numerous advantages. First, if the data is located on a central Linux box that is also running Apache and PHP, I could develop a web console for MidWatch that could control all MidWatches on the network. Currently, MidWatch writes an HTML file to report it's real time progress. It would be better is this report were generated with PHP. If the log files were stored in the database rather than ASCII flat files, it would be easier to generate performance statistics (how long the build is taking, how many builds succeed in a week etc.) Anyway, there's a lot of functionality I could develop into MidWatch if I break this technological barrier. Now, what's holding me up? MidWatch's communication with its database is based on Data Access Objects (DAO), Microsoft has a new technology to replace DAO called Active X Data Objects (ADO). To communicate with MySQL, I use an open source driver called MyODBC. My basic problem comes from the DAO.Recordset object. I have discovered that I can open a Recordset object in either dbOpenDynamic or dbOpenForwardOnly modes. The trouble is that in the dbOpenDynamic mode (which is preferred) the .Update method fails with "Error 3146: ODBC call failed" . If I use dbOpenForwardOnly (which is default), I can use the .AddNew and .Update methods successfully, but other methods like .MoveFirst and .MovePrevious are defined to be invalid. It seems that I should one day upgrade from DAO to ADO, but I have written some experimental code and I can't get ADO to work either. My choices are: 1) Download the source code for MyODBC and MySQL client and hope to find a bug there, and offer a patch to the open source community. (if I am really lucky) 2) Get (purchase) support from Microsoft and/or MySQL AB and nail this bug. 3) Write kludegy & buggy code where I replace .AddNew and .Update with the Database.Execute method and a SQL "INSERT INTO table ..." strings. 4) Abandon MySQL and use Microsoft's SQL Server. These are listed in order of preference because of long term goals they will serve. The 4th option is the worst. The reason is that last I checked, a SQL Server license costs $1400. If MidWatch required SQL Server to be installed, the cost of ownership of MidWatch would jump from free to $1400. This of course would doom MidWatch as an open source project. The 3rd option isn't so bad, but it would mean a lot of coding effort and the number of test paths I would have to travel to QA this thing would be very large. The 2nd option of course requires a tangible investment of cash. The 1st option requires an unknown investment in time. I'm not sure I have the skill to locate the bug in MyODBC, and the bug may in fact be in DAO, which is closed source to me. I have read through e-mails that are archived on geocrawler to wit: http://www.geocrawler.com/lists/3/Databases/13/75/6152725/ http://www.geocrawler.com/archives/3/13/2001/7/100/6100208/ http://www.geocrawler.com/archives/3/13/2001/6/50/5976792/ So I am not alone in the struggle, but I am still far from a solution. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-07-25 21:58:37
|
The next released version of MidWatch will be 0.2.xxx . This version designation indicates that some interfaces had to be broken. Particularly ISCMC, which will need the setup() function to change from: Public Function Setup(sDBPath As String) As weSCMCReturns To Public Function Setup(db As Database) As weSCMCReturns This is to facilitate the replacement with an Access 97 db with an ODBC connection to MySQL. Once I have a stable 0.2.xxx release, the 0.1.xxx images will be removed from the download page. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-07-13 22:59:48
|
This list has gotten too quiet. Lest you believe that MidWatch is dead, let me describe my next set of improvements on plan. The first is to get MidWatch to use MySQL instead of Access 97 for its table store. This will support a few ideas. First, running MySQL on a Linux box with Apache and PHP is very appealing to me. Since the engine basically takes its marching orders from the tables, I could build PHP interfaces to those tables so that MidWatch could be remotely controlled by a browser. My vision here is that several MidWatch build machines would connect to the same MySQL db, and the status of all MidWatches could be monitored through PHP pages. The next thing I have to do is to get rid of the Table/ASCII converter functions. What really should be done is a normal SQL dump of the tables into "CREATE TABLE" and "INSERT INTO" statements. This format will be much more merge-able for any table that persists in the SCM. Following that, I should get rid of the .apd file format and replace this with a table or set of tables. So, is anyone out there using MidWatch yet? I would really like to hear that someone is. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-04-04 19:45:43
|
Today I was able to set up a MySQL server on a Linux box, load MyODBC driver on my NT box, and write a quick VB app that was able to connect to a database on the MySQL server. It looks like I can modify MidWatch's current code to connect to MySQL instead of a local Microsoft Jet database, by changing ... oh 50-60 lines of code. The advantages are that I will obsolete the webwriter class, and replace those functions with PHP pages on the Linux box where MySQL is running. Some of you may have noticed that sometimes when your browser requests a signal bridge page, IIS or Apache only serves half the page. This is because MidWatch is not done writing the HTML. It was a poor man's way of creating "dynamic content". I've since learned enough PHP to hack a better solution. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-03-13 17:16:21
|
And while it may seem that very little has happened with MidWatch, quite a few invisible things have happened. The first and most significant is that Lisa Krasinski has left BMC Software, and is therefore not contributing to MidWatch. I'm afraid that the build business bored her silly. (She won't admit that because she's a classy lady.) We will miss her. Her contributions to understand the new architecture are very important, and I do think that we got good value from her short stay. On to other things: I have discovered PHP and MySQL. Well, I didn't actually discover them, but I am giving them very serious study. I believe, once I understand the MySQL security model better, that MySQL will become the data layer for MidWatch. The potential exists that with MySQL and PHP, I could write a web client for MidWatch, and COM be damned. I am a little unnerved that sourceforge has broken its statistical engine for a long time and that it is still broken. It appears that there have been no file downloads at all, and I hope that isn't true. It might be but I can't be sure. Anyway, Fair winds and following seas for now. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02454-9111 http://midwatch.org/pgp-key.html http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: <ACo...@ao...> - 2001-01-22 16:41:33
|
> At this point, I kind of felt that our use cases were not tuned well enough > for you to hold up as an example of how to do things. Ah, that's what they all say... I was chagrined that the book publisher wanted to clean up the UC samples inthere so much - I wanted to show them 'as is' the way projects really use them. Alistair Cockburn Humans and Technology 7691 Dell Rd. Salt Lake City, UT 84121 Work Phone: 801.947.9275 Fax: 775.416.6457 http://members.aol.com/acockburn write to: ali...@ac... |
From: Woolhiser, E. <Eri...@bm...> - 2001-01-22 16:31:37
|
At this point, I kind of felt that our use cases were not tuned well enough for you to hold up as an example of how to do things. But then again, if you're willing to casually review what we are doing, it will improve our set of use cases. So by all means, we could use a link from your websites. As you see the DB is already programmed to imbed links to your website into the use cases. BTW, everything done on MidWatch.org is under Gnu Public License so you are free to include them in your materials per the GPL. Still to come are the paper reports of the use cases, and inclusion of the scope and level icons. -----Original Message----- From: ACo...@ao... [mailto:ACo...@ao...] Sent: Monday, January 22, 2001 10:52 To: Eri...@bm... Subject: Re: Use Case database Great! I look forward to it. Your web UCs are way too cool. I love seeing the use of + and !, which certainly helps me navigate the list. Am I allowed to let anyone else know this URL? If not, perhaps I can get permission to post just a couple of these on www.usecases.org as samples (without all those page links to your design documentation :-) The one suggestion/comment I can offer from looking at the UCs for a couple of minutes is that "Start a build" is not the goal. "Do a build" is the goal, as I get from reading it. The goal that gets accomplished on successful completion is that the build is done (a phrase that fits neatly into the Success Guarantee field). "Start a build" is below sea level, I think and would be named "Start a build-". Main Success Scenario: 1. MidWatch: Start a log file for the build. 2. MidWatch: Load and validate the settings for the build. 3. MidWatch: Connect <http://midwatch.org/design/UC14.html> to SCM 4. MidWatch: Drop labels on dynamic view 5. MidWatch: Create Snapshot view 6. MidWatch: For each project, start the IDE, load the project and build. 7. MidWatch: Reset the Scheduler Thanks for sending me this note, cheers Alistair Cockburn Humans and Technology 7691 Dell Rd. Salt Lake City, UT 84121 Work Phone: 801.947.9275 Fax: 775.416.6457 http://members.aol.com/acockburn write to: ali...@ac... |
From: Woolhiser, E. <Eri...@bm...> - 2001-01-19 17:37:10
|
on the Use Case HTML pages. I was planning to do that today, but I actually finished last night. Visit http://midwatch.org/design/design.html This morning I was working on normal BMC build business and haven't done anything for development. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Krasinski, L. <Lis...@bm...> - 2001-01-18 20:26:44
|
Eric and I spent some time earlier this week going over some basic use cases. Today I've been expanding on these and defining the relationship between use cases. This will provide a rough framework for the new and improved Midwatch! We're going to maintain the use cases in a dB that Eric has designed (it looks and works great!). The dB is also linked to HTML and the content can be viewed at Midwatch.org/usecases. I encourage everyone to take a peek at the web site to see the progress we've made. Lisa M. Krasinski BMC Software, Inc. 880 Winter Street Waltham, Ma 02454-9111 (781) 663-4764 |
From: Woolhiser, E. <Eri...@bm...> - 2001-01-18 17:50:48
|
The UseCase.mdb now produces a glossary page and an actor list. The use case pages are still far from complete. Lisa is working on the content of the use cases and I have just uploaded to the website her most recent changes. The JavaScript navigation is not yet working as well as I would like, I'll probably dig into that tomorrow. I made a minor change to 0.1.x code this morning, I basically reduced an error message to a warning level. It's not even worth the effort to release. Later, -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-01-17 19:53:36
|
Ok, So I missed two days! I have set a re-occurring appointment in Outlook to remind me to write a report for the 1mc. I figure I'd do better with an after noon report rather than an end of the day report. During the Past two days I was able to finish the UseCase form in the UseCase.mdb I was modifying. I am now working on the HTML report generation. Lisa and I have listed about 20 use cases for MidWatch, but we haven't done any of the actual writing of the use cases. Over the next couple of days, Lisa will be concentrating on writing the use cases and putting them into the DB, meanwhile I will be writing more code in the .mdb to produce the reports, and fix and bugs Lisa finds. Lisa and I are meeting at least 2 hours each day to work up these use cases. You can see the very rough HTML use cases on http://midwatch.org/usecases . The navigation is nearly worthless at this point and the pages are very incomplete. I will have new uploads every few hours as I test my HTML on the website. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2001-01-12 17:18:52
|
Well, I've been away from work since the car accident on the 21st of December. I have just been asked by my manager to write my "brag sheet" for the past quarter, and I am afraid that it will be a little thin. However, I thin that reading this mail archive will be helpful. Looking forward, I want to be in a better position next quarter which means daily 1mc reports. (BTW Lisa, this means you too :) I have not completed work on the UseCase relational DB that I started before the Accident/Christmas Break. I'm kind of stuck on this one subform not working and if I don't solve it soon, I think we will have to abandon the project and just write up our use cases in HTML and be careful not to get too fancy so that we waste a lot of time maintaining the HTML. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Woolhiser, E. <Eri...@bm...> - 2000-12-16 00:17:34
|
I believe that I mentioned I was reading this before. I went to his website http://www.usecases.org earlier this week and found an Access database on his website for tracking use cases. The database was written two years ago, and does not reflect his current thinking in the book. I am fiddling around with the DB and making it conform to his "Fully Dressed" use case template in chapter 11. The value of this DB will be that we will be able to rename use cases, actors and stuff and keep all references updated. I will write a couple of functions that will export all of the use cases to HTML so that I can easily upload them to http://midwatch.org . Since use cases often refer to other use cases in the system under discussion (SuD), I'll have the HTML reports link to each other for easy browsing on the website. Of course in keeping with the open source spirit, once I get this DB up to date, Cockburn gets a free copy under GPL. I only hope that he gives us a link back to midwatch.org ! -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Krasinski, L. <Lis...@bm...> - 2000-12-14 22:26:07
|
Today I've been examining the MSF design methodology which contains some interesting guidelines for the Design Phase of a project. The Design Phase is broken down into three parts: 1) Conceptual Design: Research and Analysis (Use Cases) 2) Logical Design: Relationships b/w objects, attributes and services 3) Physical Design: Implementation Although we haven't formally been following MSF, much of the work we've done so far has been in keeping with this outline. For example, we've been developing use case scenarios and examining the scope of our project. Once this is complete we hope to be able to move into the logical design phase which will bridge the gap between our use case scenarios and actual implementation. I'll need to look at this further to see if MSF would be a useful guideline for a project like Midwatch. (Note: I'm finally connected to sourceforge using ssh! Just don't ask me how I did it!) Lisa M. Krasinski BMC Software, Inc. 880 Winter Street Waltham, Ma 02454-9111 (781) 663-4764 |
From: Woolhiser, E. <Eri...@bm...> - 2000-12-13 23:44:03
|
I just came across an "a-ha", that some Access user will think is a "duh". For anyone using MidWatch 0.1.xx, if you don't have access 97 installed, but you do have Access 2000, there is a pretty simple way to get to the MidWatch tables. You can not convert the db.mdb file up to Access 2000 and have something that MidWatch can read. What you can do is: -create a new .mdb (I call db2000.mdb) -click the Insert > Tables menu item -select Link Table -Then select the db.mdb file (still in Access 97) -select all tables and click OK. Now you have a Access 2000 .mdb file that links to the tables used by MidWatch. I don't know why I didn't think of this before! -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Krasinski, L. <Lis...@bm...> - 2000-12-13 21:26:37
|
This week I've been trying to set up remote access to the CVS repository on sourceforge using ssh. I don't have my public/private keys set up appropriately and I'm having trouble connecting. Hopefully I'll be able to iron this out by the end of the week. Lisa M. Krasinski BMC Software, Inc. 880 Winter Street Waltham, Ma 02454-9111 (781) 663-4764 |
From: Woolhiser, E. <Eri...@bm...> - 2000-12-13 20:35:33
|
Thanks Rehan, I think we are in agreement with a lot of your points. For example, I was trying to point out that if the database was accessed only by MidWatch, and that the UI was strong enough to handle all manipulations, it really doesn't matter what the format of the data is. However, you remind me that if many people are going to want to work on this project that the data structure should not be so constrained that it suits only my tastes. I'm not a SQL expert, I can hack enough of it to get by. MidWatch currently uses DAO not because it was the best way to do it, but because it was the first way I learned to do it. DAO satisfied my needs, so I didn't need to look further to find if it was the best solution. I think though, that whatever the next data solution will be, the primary concern will be cost of ownership. I should not say for example: MidWatch requires that you have SQL Server 7.0 installed. However MidWatch communicates with its data store, it should be abstracted so that anything could be used, including MySQL/mSQL. This way, if you already have Microsoft SQL server you could us it, and if you have nothing you use some open source alternative. >however, I personally think that the systems in place >should allow developers to build these things and get >to the code via normal drive mappings or what ever and >therefore MidWatch should be able to go the same >route. i.e. I think that the "remote" aspect of >things should be dealt with at a lower level. I'm not perfectly clear on what you are saying here. My thought at remoting is to solve a couple of things. 1) My commute to work is about 1.5 hours each way. If I am asked to baby-sit a build some Friday or Saturday night, it might be cool to do this from my DSL line at home. 2) BMC is a multi-site corporation. Our headquarters are in Houston. We have some products where some of the components are built in Waltham, MA, and some are built in Texas. As a Build Engineer, I may be interested in a build occurring in Texas, and someone there may want to look at a build here. >sometimes i've been in the situation of having to code >around some weird (read unmaintainable) building >practices and then i've found it better to try and >change the practices. after all, the "big picture" >objective is to improve the quality of the product and >process. of course, this probably isn't an option for >most situations. Amen! I hope that MidWatch will be able to prevent bad release practices by not supporting them. Over the past three years of "prototyping" MidWatch, I have had to resist many feature requests because I felt that I was being pushed toward entropy rather than a process or system. I still fight this battle as I must balance my gut feel of what is best for MidWatch against local customization needs of the company I work for. Sorry I didn't respond sooner, I was out sick for a couple of days. -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |
From: Rehan K. <reh...@ya...> - 2000-12-12 23:58:29
|
some thoughts and suggestions for y'all. hope they're helpful in some way. > I agree, and I don't think it is much worth the > effort at this point. > If I were to solve this weakness of 0.1.xx I think I > would instead build a > stronger UI so that Access 97 would not need to be > loaded by the user. All > data stored in the tables should be validated by > MidWatch anyway, so in a > sense it is a feature not a bug that it is difficult > to bypass the MidWatch > UI and access the data directly. > i like the idea that all components should implement their own user interface. and of course i've said before that i don't like the idea of tying people into any one method of storing the configuration data, simply because people have different needs. > Are you using Fuel currently? only to build itself :) it was mainly written for fun. > > What I would have wanted to see from midwatch was > a > > much more modular structure so that it would have > been > > easier to add stuff myself. And less dependencies > > (like the MS Office thing that we talked about). > > Having separate builders would go a long way to this > end. > there are (at least) 2 ways to approach these dependency problems. first you can take the "link statically" approach which would be, for example, building database functionality into the UI. i think that this would introduce too much tight coupling into your design, which makes it difficult to alter later. alternatively (this is my preferred solution and what i did) you can make everything optional by allowing the user to decide which builder, configuration method, whatever to use. they can then choose the one appropriate to their situation and, if none exist, relatively easily implement their own. the binary component architecture helps a lot here, as does the dynamic discovery of these components at runtime. > Ah, because of the "overkill" thought, I think no > one has developed a good > general build solution. The current MidWatch is > handling 1.2 million lines > of code in 2-4 parallel branches. I envision it > being much more responsible > than that, and more of an enterprise thingy. > i went a little way down this road of thinking and started to design a flowcharting system and it almost immediately generalized into something that's nothing to do with builds. that's why i say overkill. it can quickly get to the point where you're basically implementing a turing-complete language. now _that's_ what i mean by overkill :)) at that point i would say that you should simply release some scriptable COM components and let people write their own VB/Javascript/VBScript code. > I see having GUI-less MidWatch servers on multiple > build machines in a > company's intra-net. I see MidWatchs handling > distributed builds and sharing > builds with other MidWatches. I see build engineers > on multiple remote > workstations connecting to any MidWatch on the > intra-net to correct build > errors remotely. i had thought before of parallelizing the build onto multiple pcs using DCOM but that was only for speed reasons. it was taking about 3 or 4 hours to build, which was causing problems near release time. however, i personally think that the systems in place should allow developers to build these things and get to the code via normal drive mappings or whatever and therefore midwatch should be able to go the same route. i.e. i think that the "remote" aspect of things should be dealt with at a lower level. sometimes i've been in the situation of having to code around some weird (read unmaintainable) building practices and then i've found it better to try and change the practices. after all, the "big picture" objective is to improve the quality of the product and process. of course, this probably isn't an option for most situations. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
From: Woolhiser, E. <Eri...@bm...> - 2000-12-07 20:50:15
|
not entirely complete. This morning I brought in "The Bluejacket's Manual" to see if there were terms that would replace the rejected "grunk" and "polygrunk". The replacement phrase for "project list" and therefore for "product" is leaning towards "battle bill" which is a close, but not an entirely perfect metaphor. The idea of the project list is that it is simply a list of .dsp file paths and associated attributes that MidWatch simply builds in a linear fashion. However, since this "recordset" as it is currently implemented would be expanded to build other things besides .dsp files (as Rehan Khwaja does in Fuel <https://sourceforge.net/projects/fuel> ) calling this a project list no longer fits. I've picked up "Writing Effective Use Cases" by Alistair Cockburn today. On the drive to and from SoftPro, it occurred to Lisa and I that part of this problem should be looked at like a Just In Time manufacturing process. You start at the demand and work backwards to the supply. What the customer wants is a setup.exe to install. Which means we have to produce a kit, which means we have to produce the files to install. This requires that we compile and link certain things and this requires that we find the stuff in one or more SCM's. The first use cases therefore should work from the end of the process and work backwards. Pull rather than push. I'll be out of the office tomorrow, so you'll have less to read :) -- Eric Woolhiser BMC Software Inc NT Build Meister 880 Winter St. Bldg 4 rm. 2.227 781-663-4646 (or x34646 internally) Waltham, Ma 02254 http://midwatch.org http://www.bmc.com http://www.tuxedo.org/~esr/ecsl |