Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-pmc] RE: Agenda for Tuesday, April 4th telecon

Two additional items:


(1)     A reminder to track bug approvals for 1.0.2 via the dev mailing list, and

(2)     Please see David’s update on the releng coordination issue for our discussion this morning; copy below for your reference.


End of long story: The EMO (via Bjorn) doesn't consider this any differently (currently) than any other committer for any other component. Meaning, we would have to go through the whole WTP "nomination/vote" cycle for these folks, to give them access to WTP ... and, technically, that should be for their history and contributions to WTP, not just because we are incubating them as a project. I can see some merit to this view, though, obviously, arguments could be made for different rules for incubating projects ... but .. so far, there are no different rules.

So, there's two options I can think of. I have a preference for the second one, but am open to any solution.

1. Continue status quo: they provide patches to our build files and map files and Naci continues to coach them on "how to do it", as he has been. This would continue until they graduate from incubation, and become components or sub-projects of WTP.

2. Someone (Naci? Jeffrey?) apply some effort to improve the "portability" of our build process and those projects build their own code using identical methodology *AND* that same person improve our "cascading build" methodology, so once WTP build is done, JSF, et. al. would automatically "pick up" the latest build and build their stuff. And, of course, this would still require the mentoring and "how to" coaching that needs to take place in either case.

Part of the reason I recommend the second option is that we ourselves need to improve our "cascading build" ability, so that, for example, we can easily and automatically get the latest build of our pre-reqs to build against. So, us doing it for "downstream" projects would not be totally "extra" effort, and might improve the overall process. Jeffrey has done some of this for testing, but I personally have not looked to see how he's doing it, or how much work would be involved in transposing it to cascaded builds (instead of cascaded tests).

Can anyone think of other options?

Perhaps we could discuss/decide at next PMC meeting?

From: Tim Wagner
Sent: Tuesday, April 04, 2006 6:31 AM
To: 'WTP PMC communications (including coordination, announcements, and Group discussions)'
Cc: 'Craig Becker'; NEIL.HAUGE@xxxxxxxxxx; 'Shaun Smith'
Subject: Agenda for Tuesday, April 4th telecon


Call Info: 866-214-3176 or 404-827-9098. Access code 8870689.



  • Community
    • Weekly report
  • Hot bug process (held over)
    • Please review the proposal
    • My notes below
  • Build coordination
  • 1.0.2 Status
  • 1.5 / Callisto
    • M6 / build progress
    • Callisto testing  
  • Requirements (Jochen)
  • Architecture (David)
  • JSF (Raghu)
  • ATF (Craig)
  • Dali (Shaun/Neil)
  • Additional topics



Craig Becker has been invited to the WTP PMC call to represent ATF.

Dali leadership (Shaun/Neil) has a standing invite through incubation exit to join the calls.


Hot Bug Process Comments (twagner):

  • Re: “justify…”line – “provide rationale, with indication of impact” might be preferable wording.
  • If the bug is taken off the hot list, then we also need to remove the proxy.
  • Clarify the final point – the set of bugs reviewed by the PMC is the set of [hot_bug_request]’s for which no [hot_bug] proxy has been created, and the PMC can review this list at any time (i.e., waiting until the cutoff date is not a requirement).
  • Minor: “targetted” spelling.


Back to the top