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.
Agenda:
- Community
- 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
Attendance:
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.
