incubator-bluesky-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Kevin <lovesumm...@gmail.com>
Subject Re: what we are doing and proposed next step
Date Thu, 27 Aug 2009 09:28:13 GMT
hi, Bernd:
     i know that the first Release is a mid-term goal. Actually we are
aready developing the future version of RealClass. A prototype of P2P
version has been completed and tested under windows . And we are also
working on a web-based RealClass system. the current structure of RealClass
is C/S and seems like out of date. So i think that we just need to make the
first release with a stable C/S structured RealClass, then next version
would be p2p and the next web-based,…………。 i do hope that our system could
revolving with the development of new tech.
regards,
Kevin

2009/8/18 Bernd Fondermann <bernd.fondermann@googlemail.com>

> Doing a release is a good goal.
> However, before looking deeper into the exact requirements for doing a
> release, I'd like to see developers in action on the mailing list and
> working on the code in svn as an open source project. I'm seeing none
> of that currently. All this work would be directed towards a release,
> but actually doing the release for me is more of a mid-term goal.
>
> On a more general note - and I'm sorry to say that - I see the Bluesky
> project on the edge of failure.
> There are not enough active mentors on the project and no open
> development is taking place.
>
>  Bernd
>
> On Tue, Aug 18, 2009 at 09:46, Samuel Kevin<lovesummerf@gmail.com> wrote:
> > Hi, All:
> >    After we solve the problem of FFmpeg, i guess our next goal is to make
> > the first release. I've read through the whole page of guidlines of
> Release-
> > http://incubator.apache.org/guides/releasemanagement.html. Wow, it's
> quite
> > large and to some extent, for me, ambiguous. The following is my
> > understanding to Release.
> >
> >    Release involves two things most. First is the code. We should
> guarantee
> > both quality and the legitimacy under ASL. Personally, i suggest that we
> > should focus on clarifying the legitimacy of the source code.  Some codes
> > ,with free license , the initial developers used in our project are mixed
> > with the code they wrote. So we had to isolate the free licensed code and
> > clarify the license. For the sake of convinience, the initial developers
> put
> > some libs, whose licenses conflict with ASL, in the source code. Of
> course,
> > we should also clear them out.
> >   Second is the documentation. I checked the example the guideline shows-
> > http://httpd.apache.org/docs/2.2/ and i found that we only miss the API
> > document. I suppose we could use doxygen to help us complete the API. I
> > don't think comments our code follow the rules of doxygen, so i recommend
> > that we could mend that when clarifying the legitimacy of the source
> code.
> >
> >    Guys, here's my  thought about next step.
> >    1:Clarify the legitimacy of the source code, meanwhile label the
> comment
> > which apt to generate API document by doxygen;
> >    2: use doxygen to create API documents;
> >    3: finish the relevant work a Release needs and make the first
> Release;
> > guys, what do you think about that ?  Any suggestion?
> >
> > regards,
> > Kevin
> >
> > --
> > Bowen Ma a.k.a Samuel Kevin @ Bluesky Dev Team    XJTU
> > Shaanxi Province Key Lab. of Satellite and Terrestrial Network Tech
> > http://incubator.apache.org/bluesky/
> >
>



-- 
Bowen Ma a.k.a Samuel Kevin @ Bluesky Dev Team    XJTU
Shaanxi Province Key Lab. of Satellite and Terrestrial Network Tech
http://incubator.apache.org/bluesky/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message