Subject: [TOOLS-DEVELOPMENT] Instructions for IETF Software Development Contractors

From: Russ Housley <[email-masked]>
Date: Thu, 16 Jun 2016 11:16:10 -0400

Dear Team:

Please review the following web page:
https://trac.tools.ietf.org/tools/ietfdb/wiki/ContractorInstructions

Past SoWs have not been clear about the way that we want the final deliverable packaged.  So, we have expanded these instructions for python-based projects.  Please review to make sure we got it right.

We need to come up with something very similar for non-python-based projects before we release the RFP for the RFC format tools.  Since AMS will have to do the install and maintenance of that software, I am wondering if someone from AMS can take the first pass, and then bring it to this list for review.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 Jun 2016 10:24:32 -0500

I just reviewed the packaging text in context.

I think we will convey what we want more effectively if we switch the 
order of the two paragraphs that are there now. (That is, talk first 
about the single/small number use case, and then about the end-user use 
case).

RjS

On 6/16/16 10:16 AM, Russ Housley wrote:
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Glen <[email-masked]>
Date: Thu, 16 Jun 2016 08:41:49 -0700

"Someone at AMS" (which means me) will be delighted to do this - but
will need a little time to find cycles so to do.

Thanks,
Glen

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Jun 2016 18:40:40 +0200

> about the single/small number use case, and then about the end-user use 

Done!

	Henrik

---

From: Glen <[email-masked]>
Date: Thu, 16 Jun 2016 13:22:50 -0700

> Past SoWs have not been clear about the way that we want the final deliverable packaged.  So, we have expanded these instructions for python-based projects.  Please review to make sure we got it ri…

I have reviewed the web page.  I like the information.

My question:  most of these things sounds like options, "suggestions",
if you like...  you "should" include a file... etc.

Do you want the wording to be more strong, to stress that these are
requirements, not options?

> We need to come up with something very similar for non-python-based projects before we release the RFP for the RFC format tools.  Since AMS will have to do the install and maintenance of that softw…

Ultimately, "someone from AMS" is likely to be me, but I feel rather
inadequate to this task.  Where to begin?  Take the above page and
copy it and change it?  I would be grateful for any pointers or tips
on how to get this started...

Glen