"Simonsen, Larry" wrote:
>
> I think one of the first questions in determining the version to port is how
> beta is the 8.12.beta 7

On the one hand, I would expect the quality of a 7th beta to be pretty good.
On the other hand, why has it taken 7 tries so far to get it right?

> when will this be the latest release?

I'm not currently in tune with the sendmail developer's forums, so I have no
sense of average time from beta to GR.

The way I approach all of my ports goes something like this:

1) Port any dependent subsystems first.  Sendmail does have some dependencies,
most of which are already (or soon to be) current on MPE, but some which are
not.

2) Port the latest GR release of the main application.  I don't like to start
by porting betas, because it's hard to tell if you encounter problems whether
they are an MPE porting issue or an OS independent buggy beta issue.

3) If a new GR release has appeared by the time you finished with the first
one, do a quick test of carrying your diffs forward to that new GR release, and
if successful with a minimum amount of effort (as in a day or two), make that
the version you release to users.

4) You must submit your MPE changes back to the official developers, and that
usually requires that you download the latest bleeding edge alpha or beta,
apply your diffs to that, build, test, and if successful, generate new diffs to
submit to the official developers.

So if I were doing sendmail this time around, I would start with 8.11.3, but it
might actually turn out to be 8.12.0 by the time I'm finished, assuming the
8.12.0 beta 7 goes GR by then.

> how much work will be involved with changes as it is released in the future?

The amount of technical porting work required is generally proportional to how
long you wait to port each new release to MPE.  If you try to build EVERY
release of an open-source product on MPE, the work required to move from
release N to release N+1 is usually very small or even zero.  But if you last
ported release N, and don't try again until release N+5, then you may have
quite a bit more effort depending on how much new functionality has been added.

Note that my definition of "work" in the context of Larry's question is
strictly building & testing the app on MPE.  It does not include HP
productization overhead of support training and manufacturing.  This overhead
will most likely always exceed the pure porting work of the N->N+1 case.

> what can be done to port the next release fast?

1) Make sure the MPE changes from the first round of porting get submitted back
to the official developers.

2) Fully supported releases consume way more time than unsupported freeware
releases.  Should everything we release (say arbitrarily once per year) be
fully supported, or is it acceptable to do interim releases of use at your own
risk unsupported freeware?

3) Having more than one person with knowledge about a port makes it easier to
solve problems with future ports.  I think it's a really good idea that Jeff is
doing sendmail this time around.  I do not claim exclusive ownership of any
bixby.org stuff, and CSY I&I does not claim exclusive ownership of any
productized open-source stuff.  Anybody interested in seeing new releases of
open-source stuff on MPE is certainly welcome to begin porting at any time.
But please announce your intentions on HP3000-L like Jeff has just done in
order to prevent any duplication of effort.

- Mark B.

>
> -----Original Message-----
> From: VANCE,JEFF (HP-Cupertino,ex1) [mailto:[log in to unmask]]
> Sent: Monday, May 14, 2001 5:05 PM
> To: [log in to unmask]
> Subject: sendmail port
>
> Hi all,
>
> I am trying something new today.  In fact, I am trying two new things:
>
> 1) I am charged with porting sendmail to MPE, and, eventually getting
> sendmail supported by HP.  This was one of the top 10 requested Interex
> SIB items.
>
> 2) If it is ok with the list, I am planning on making my port of sendmail
> completely public.  I will ask many "stupid" questions to the list, apply
> the answers, ask more and eventually get it ported and running.  My
> motivation
> is to make a case study of this port so that others will be more willing to
> try ports of their own.
>
> Now, you might ask, why doesn't Mark Bixby just do this port, since he did
> the first port and he can probably do it pretty quickly. Yes, he can, but he
>
> is also doing other important projects, like the public access system (see
> http://jazz.external.hp.com/pads/).  Also, I have been involved with POSIX
> on
> MPE for many years, yet I have never done a single port, and I think I
> should.
> Plus, for this case study, Mark might gloss over something that stumps me,
> and
> I will get to ask the "embarrassing" questions.  I know there is no such
> thing
> as a dumb question,  and I will rely on the help from many on this list, so
> thanks in advance!
>
> As homework I have read Mark's Porting Guide at:
> http://www.bixby.org/mark/porting.html
>
> And, I have read his original sendmail page at:
> http://www.bixby.org/mark/sendmailix.html
>
> And, I have read some of the notes at the host sendmail site at:
> http://www.sendmail.org/
>
> I see that sendmail 8.12 Beta 7 is the latest and greatest version at
> sendmail.org.
> Sendmail 8.11.3 is the "current"/"main" version there.  Both of these
> versions are
> newer than Mark's version 8.9.1, and contain some security and performance
> enhancements.
>
> Now, my first question: which version of sendmail should be ported with the
> expectation that it will also be supported by HP. I know it is important to
> be on a current version and at the same time, CSY won't want to support too
> many versions of sendmail.  So there may be a trade-off of current vs.
> supported by HP.
>
> Thanks,
>  Jeff Vance, CSY
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *