On Tue, Jan 10, 2012 at 9:42 PM, Michael Stroucken <m...@cmu.edu> wrote: > 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).
Michael, Neither the foundation nor the incubator has requirements for live or dead code or anything like it. So long as IP clearance is OK, you can release any valid release, and validity is all about source that builds and appropriate notices. You should not be waiting for *any* technical achievement to graduate -- you should release what you have, and you should graduate when you've shown that you can make releases, incorporate new people, etc. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
