Joe Schaefer wrote:
Let's stop discussing this issue in the abstract then and take
a look at the current set of reports. Of the ones with signatures
of mentors, I see very little to gripe about- the topics and subjects
are mostly relevant to the podling's progress towards graduation.
Now lets look at the remainder- several projects with no report whatsoever,
and Tashi, which has been incubating since 2008, writes exclusively about
technical issues and really says zilch about their progress towards
graduation. IMO that project clearly is in dire need of guidance.
What should we do, just pass that unsigned report along to the board
and continue to ignore the podling?
I'll respond for Tashi here. The quarterly report requirements state:-
Your report should contain the following:
* Your project name
* A brief description of your project, which assumes no knowledge of the
project
or necessarily of its field
* A list of the three most important issues to address in the move towards
graduation.
* Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
* How has the community developed since the last report
* How has the project developed since the last report.
Most of the activity in Tashi is development of the code base, so I
think it is a fair expectation that the majority of the report fits in
the "How the project has developed since the last report" section. The
issues holding us back from graduation are much less volatile, such that
one item was removed from the "list of three most important issues to
address" section between our October report and now, but the other two
remain.
The most serious issue for us is dead code of indeterminate mass in the
code base. 1) There is code that we wrote for experiments and proof of
concepts at some time, and code that supports certain hardware, but we
have not been able to maintain to the degree as the core parts of the
system. 2) We migrated from one RPC layer (Thrift) to another (RPyC)
early in the project, and while I believe none of Thrift code is still
used, I have been reluctant to blow it away because of people possibly
using code from issue 1).
We have a stable branch of the code that I think is conditionally usable
as an Incubator release version, but I was planning to ask our mentors
about how to handle our release issues once a new branch with major new
functionality was approaching a merge back into the trunk. I see that
happening in the next few days.
Greetings,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
