Historic: ProjectStatus_2011_08_19

TOC(ProjectList,ProjectStatus*,titleindex)

#!rst
--------------------------------------------------------------------------------
Status for the Alternate Streams Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------


Summary
=======

States and annotation tags revised to the last draft version.


What's done
===========

Revise states and annotation tags. 
http://trac.tools.ietf.org/tools/ietfdb/ticket/704

What's next
===========

All work done, the last thing is change the text of an email.

Time plan
=========

We can begin acceptance cause modify the email is just a case of 
string replacement.


Problems and Possibilities
==========================

On http://tools.ietf.org/html/rfc6322 the section "7. IESG Mail Sent 
for the IRTF and Independent Stream" requires that an email needs to be 
clarified.

I suppose that the referenced email is the one in 
`templates/idrfc/approval_mail_rfc_editor.txt` but I don't know in which 
way it must be clarified.


--------------------------------------------------------------------------------
Status for the ID Tracking Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------

Summary
=======

Finished ID list management. Working on notifications.

What's done
===========

ID list management http://trac.tools.ietf.org/tools/ietfdb/ticket/701


What's next
===========

Finish notifications.

Set up a beta server.

Time plan
=========

We had planned to end development in the next week but I think it's 
better to delay one week the end date in order to ensure that everything 
is tested.

So the proposed end date for the project is September 2.


Problems and Possibilities
==========================

From September 3 to September 11 I'll be on vacations. At this date 
the project must be finished and the acceptance could begin, but I 
prefer to be available when the tool is tested so I can fix bugs or 
answer questions fast.


--------------------------------------------------------------------------------
Status for the DB Conversion Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------


Summary
=======

In the midst of porting somewhat complicated liaison form code; mostly
done with the module.

What's done
===========

Finished liaison model, finished importer, proxied most of the views,
thought up a tactic for handling the edit forms and related
utililities through a combination of proxying and most of the way
through executing said tactic.

I've also written the first automated test for the module. The first
one is always the most cumbersome.

And run an import test with the latest data and fixed some issues.

What's next
===========

Write some more automated tests for liaison to make it easier to port
the intricate forms code, then port it, and wrap up the project. Oh,
and read and think about the document state suggestion.

Time plan
=========

I think I can have forms ported and tested Monday next week, then wrap
it up Tuesday.


Problems and Possibilities
==========================

I was initially thinking I could port the liaison edit views directly
over, but it turns out there's a quite big JS file involved and
multiple interconnected forms with plenty of code. So I gave up on
that and have instead resorted to porting the forms and utilities,
proxying the rest.

Possibilities: possibly because of the intricacies of the old schema,
there's a great deal of abstractions defined in the liaison code,
compared to lines actually doing useful work. E.g. the entity
hierarchy in liaisons/utils.py is quite a bit of non-trivial code and
still it doesn't quite manage to abstract away who can do what. So
with the new schema, most of this can probably be simplified.

Also, it's odd that the submit form doesn't contain the help inline,
possibly with better named fields, instead of having a separate help
page. I guess this may be a left-over from an old tool.

Ole


--------------------------------------------------------------------------------
Status for the Rfc-ed/IANA Sync Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------

Summary
=======

Initial considerations only.

What's done
===========

I looked over your earlier proposal, and it looks like the way to do it.
We could use the strategy on both the datatracker and the
IANA/RFC-editor sites.

What's next
===========

I'll reread the RFC and prepare a more detailed suggestions next week.

Time plan
=========

I'm hoping for feedback from IANA and the RFC-editor the week after that.

Problems and Possibilities
==========================

None


--------------------------------------------------------------------------------
Status for the WG Charter Tool Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------

Summary
=======

All functionality per RFC done. Need to coordinate a few minor things
with Ole.

What's done
===========

Editing announcements, notices to secretariat for different state
changes, atom feed as requested in the RFC, setting initial review time.

Additionally, I made a view for submission of charter texts. It's quite
simple and sets the revision automatically.

What's next
===========

Ole has some changes (mostly stylistic and some more tests) to make the
code more maintainable that he would like added. I'll do so on monday.

Problems and Possibilities
==========================

I reverted to just having a single charter document object
"charter-ietf-wgacronym" since it ended up being easier than maintaining
histories for several charters. So the revision of a charter document is
"XX-YY" or "XX" for approved charters, exactly as in the RFC.

I did however run into some issues when testing changing the acronym of
a WG during chartering. Since the acronym is part of the name of the
charter Document object, and since the name is the primary key, you
essentially have to create a new Document object and move the history
from the old one. This is somewhat of a hack, and it would be better if
we could change the name of a Document object (and having something else
as the primary key). But I don't know how much that would potentially
break. Or are you ok with the hack for now?


--------------------------------------------------------------------------------
Status for the Xml2rfc V2 Project: 12 Aug 2011 - 19 Aug 2011
--------------------------------------------------------------------------------


Summary
=======

Josh has continued to make progress on both the command line tool modifications and the GUI tool updates. I just emailed a more thorough update of everything he did last week along with the new builds.


What's done
===========

Please see email today to the xml2rfc list for details on GUI and command line tool app.



What's next
===========

We'll plan to respond to latest thread to make sure all questions are answered and issues resolved.


Time plan
=========

Our estimate is over the next two weeks, we can wrap up any feedback for the command-line tool and deliver that along with the second invoice. At that point we will be focused on wrapping up, testing and building the installation packages cross platform. 


Problems and Possibilities
==========================

None at this point.