[higgins-dev] Notes from the October 25th Weekly Higgins Developers Call

["Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx>]

With apologies for the delay

 

Attendees

  Alex Amies - IBM

  Paula Austel - IBM

* Anthony Bussani - IBM

* Jeff Broberg CA

  Andy Hodgkinson - Novell

* Duane Buss - Novell

  Greg Byrd - NCSU/IBM

* Brian Carrol - Serena

* Tom Doman - Novell

* Jeesmon Jacob - Parity

* Valery Kokhan - Parity Ukraine

  David Kuehr-Mclaren - IBM

* Mike McIntosh - IBM

 Tony Nadalin - IBM

  Nataraj Nagaratnam - IBM

  Dale Olds - Novell

* Markus Sabadello - Parity

  Uppili Srinivasan - Oracle

* Drummond Reed - Cordance

  Bruce Rich - IBM

* Mary Ruddy - Parity/SocialPhysics

* Markus Sabedello - Parity

* Jim Sermersheim - Novell

  George Stanchev - Serena

  Daniel Sanders - Novell

* Paul Trevithick - Parity/SocialPhysics

  Igor Tsinman - Parity

  Lex Sheehan

* Brian Walker - Parity

--

* Present

  

Agenda

======

1) Status of 1.0M9 Build

2) Build Enhancements (see [1])

3) Mary: Deployment naming/marketing

4) Mary: 1.0 Bugzilla item status

5) Mary: Intellectual Property Reviews (IPR) - status update

[1] http://wiki.eclipse.org/Higgins_Wiki#Build.2FDeploy_Related

 

 

1)Discussion of the 1.0M9 builds

Jim: We need a way to easily known the the status of the builds

Paul:  That is one of the enhancements on the wiki.

Tom:  I don't know the all overall status, but we did get the JNDI jar to build. As far as I know, in general the builds are working.

Paul: I don't have any more info on the last build, and Valery is not on the line. Maybe we should just move into discussing build enhancements.

Paul:  (Talked people through pulling up the above link)

Mike:  Please place the link in IRC.

Paul:  We have at the top, 2 urgent items.  We were not setting the permissions right.  We also need to automatically ... This tagging isn't done yet.. Brian and his team are going to be working on this.

Valery:  (Joined the call) He is hoping that by tomorrow morning we will have something we can tag as a stable build.

Paul:  At the bottom of the list is: add led's to show build status.  The build script should search for each of the anchors and update the image url to point to a red or green led picture.  Maybe we should raise the priority on that.

Brian: Yes, raise the priority.  Can we get a tutorial on how to do this?

Paul:  Jim did this with templates. 

Jim:  Just send me an email..

Paul:  Hit refresh on the wiki.  This item has been moved to the urgent category.

Valery:  I think that this can be done, but we need more prioritization on the build scripts.

Brian:  There may need to be some modifications to the build scripts to support this.

Paul: So Brian you are going to work on prioritizing the sub parts of these three priority items.

Paul: Jim we could take a minute to look through your wiki page.  The page is called deployment requirements and I'm pasting it into the IRC.

Jim: Here I'm just trying to catch ideas.  What will people expect to see and what will make their lives easier.  Most of this is on the dev list.  We had a notion of different audiences for the deployment.  Someone who wants just a WAR or Jar file and wants to minimize steps. May or may not have Eclipse installed... We want to make it the easiest experience possible.  So I put out different profiles or environments that need to be covered and identified expected behaviors or user experience for a deployment that fits that profile.  Developers break into two categories. (Maybe should have more than two categories). One person wants to play with the code, another wants to provide extra functionality for plug points.  The first group are developers who want to pull it down and go through the manual steps of building to see how the components fit together, but the don't want to write code. Once they understand it they switch to deployers.  I want to capture all our thoughts then turn them into requirements that drive our deployment pages, and drive the capabilities of our build system.  It should be that we can give the same functionality to people who are pulling down code as we do in the nightly build - like auto fetching third party dependencies.  This needs to be requirements driven, not cool factor driven.

Paul:  I really appreciate this. I think it is a good start.  I think we need to split the requirements at the top level into Eclipse IDE and non Eclipse IDE developers.  I think this is really good and encourage people to jump right in and provide input.

Jim:  That was my goal.

Paul:  We should look at this page first, before adding things to the build enhancements page and vice versa.  Do we want to go through your questions on this wiki page on the call?  Are there any key question.  I think we should definitely split it.  There is a question should we do the recursive build and automatically pull down all the dependent projects.  Valery do you agree with that approach?

Tom:  Hey Paul I have a question.  Should we pull down and update the Eclipse or Third party dependences?

Jim:  I've been thinking about both. I know they are separable... I'm thinking about the guy who comes along and wants to build a deployment with a number of dependencies.  I don't want to have to treat deployments different than component projects.  I and Valery have some ideas for how to implement this. I don't care what method  is used as long as it doesn't involve a lot of extra steps. Mike has suggested...

Mike:  Right now we are undergoing the situation now, we have the same info in lots of places and it it hard to keep them synchronized. It would be much easier if the build process auto generated what we can auto generate.

Valery:  Mike...   lines go dead.

Valery:  During the actual build we need to be sure that all our requests are correctly ordered.

Paul:  Can we get Valery to take the suggestions and update the wiki page? The question is how much work is it to auto generate the scripts.  We need to create a common understanding of what needs to be done.

Mike: To paraphrase this, the Higgins to Ant needs to run inside an Eclipse workspace that contains all the related projects.  We don't necessarily, on the build machine, have an actual Eclipse workspace so we can't generate the build xml easily...

Jim:  Any given component project has listed in it all its direct dependencies (Higgins and third party)   Need to differentiate between jars needed at build and jars needed at runtime.  But there is an issue of ability to specify version numbers. Need to make use of build.properties to maintain instructions for jars used at build vs.. run time... General Manifest.mf from had edited xml files...

Paul:  Could require Eclipse to run the build scripts. 

Jim: Then developers need to remember what scripts they need to regenerate.  This has been an historical problem.

Paul: My instinct is it that maybe this is what we need to tightened up.

Jim:  A couple of days ago got a suggestion to have one of us capture all these pains so see if any other Eclipse projects have had similar ideas.. Open it up to a wider community.

Paul: Have done some outreach, but not very specific.

Paul  We should park this infinite topic and more on to other topics in today's agenda.

3) Mary: Deployment naming/marketing

Mary: The next topic is naming deployments.  This is a continuation of last week's discussion 

Paul:  Last week in preparation for Barcelona, we changed the name of the Identity Agent deployments to Identity  Selector.  I know Mike that you said you didn't like this as we are trying to differentiate the Higgins offerings. But most people don't fully understand this new paradigm yet.  We first need to roughly position what we are doing.

Mike: Not sure the name is appropriate for all the functionality we are providing... The input and i-card manager... etc.. It seems like we are taking a small subset and using a name that may not be the right name.

Paul:  The scope issue was the main reason we wanted to use the other word.

Mary:  People are just barely ready to understand that there is a new concept called Identity Selector.  Once we have them oriented, we can talk about the benefits of varying approaches.

Paul: I sympathize.  People don't even understand what an Identity Selector is.  So in the end, (now) we went with the term Microsoft uses.  We are so close to this we don't realize that people aren't even understanding the basics.  Over all response to the new terminology has been positive.  So why should someone use the Higgins selector vs. Microsoft's...  All people remember the word selector.  In the long run it will be contracted from Identity Selector to Selector.  Just as Web Browser contracted to just Browser over time.

Jeff:  Can I say something else about the Interpol event in Barcelona? I noted that the Higgins Idp column in the interlope  wiki is light.  It isn't obvious where the dip is..

Paul: I will take a look.  That link was a mistake...

Markus:  This was also the case for the identity selector page.  That link was wrong, it has been fixed now.

??:  Couldn't find the Eclipse based selector.Mike: It hasn't been contributed yet.  Still working on getting it into shape to be contributed.

Mike: Hoping in the next couple weeks.  Need to talk to Tony.  Is was built based on a June snapshot.  It needs to be brought into the M.9 code base.

Jeff:  Should we take this off the the list as it not available?

Mike: It was exercised but didn't get detailed feedback put into the wiki. Tony was at the event, but he isn't on the call. If you have a question, send it to the list. 

Jeff:  I would like to know why it failed.

Paul:  Next time, we should go through the interlope matrix line by line and get feedback.

Markus:  We may have more input in the matrix by next week.

4) Mary: 1.0 Bugzilla item status

Mary:  The next item on the agenda is the Bugzilla items for 1.0

Paul:  There are 78 items.  Assigned to people from various companies

Brian:  On the Parity side, we are working from the top down and are checking on the status of each item.

Paul:  Items have status of P1,,P2,, P3

Brian: We have been focusing on the P1 items.  We will review and update the status.

Paul:  Maybe from here forward we should list the number of open items.  Get the list on the components page that is linked to the bugzilla report.

Mike:  Is anyone planning to work on these in the immediate future?  Is now the time to do an .9 branch?

Paul:  I was going to to the branch when the stable build is done.  Does anyone object to doing this now?  This would mean need to change the build script.

Mike: The only reason to do this now is if someone's hands are tied.

Paul:  Lets wait another day or two. 

Paul:  Valery has done the merge for the other outstanding item for M0.9 

Mike:  The last non building component should be able to build

5) Mary: Intellectual Property Reviews (IPR) - status update

Mary: We continue to work with Eclipse legal and the committers to proceed with the remaining IPR reviews as quickly as possible. It is very important that we don't introduce any new third party dependency changes at this point.

Paul and Greg: Will work on having Greg use/test the new build processes. All Committers: Review your components dependency pages to ensure that they are accurate and complete and don’t contain any obsolete items.