nanogui: Thread: Re: [nanogui] Is Nano-X dead? - Move to SVN+Trac?

I'd like once again to push for a move to SVN (or better, Bazaar) and
using Trac for the website. Then many people could contribute easier
both on code but as well the documentation if held in the Wiki included
with Trac.

And it will probably make the project appear more active than it does
currently, which hopefully generates more users and contributors.

Regards
Daniel

On Mon, 2008-07-07 at 11:41 +0200, Fredrik Johansson wrote:
> James Johnston skrev:
> > I'm looking to use Nano-X in a new open-source project, but the last update
> > was in 2005.  Is the project basically dead?  From all appearances this
> > appears to be the case.
> >
> > Best regards,
> >
> > James Johnston
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> >
> >   
> Nah, it's not dead, it just hasn't had any release for some time now, 
> the cvs is still beeing updated.
> 
> Here's a snippet from the changelog:
> 
>     * fix .fnt.gz loader padding bug
> 6 January 2008 - neuros patches from Vladimir
>     * add generic window message send GrSendMsg, GR_EVENT_MSG, 
> GR_EVENT_MASK_MSG
>     * add alpha channel handling in GdDrawImage, alpha support in PNG loader
>     * fix bug in GdGetNextTimeout
>     * add GrDrawImagePartToFit - draw image from part of source image
>     * add MWMODE_SRCTRANSCOPY support in fblin16, applyOp{3,4} macros 
> for speed
>     * remove #include <asm/page.h> in clientfb.c, PAGE_SIZE now internal
>     * fix GsWpDrawBackgroundPixmap to work with pixmap window backgrounds
> 30 November 2007
>     * fix ftell in FNTGZ font subdriver
>     * port AGG AntiGrain Geometry, NXLIB and direct hw fb version
>     * add MWPF_HWPIXELVAL run-time pixel type to allow no-translation GrArea
>     * add back in low level psd->DrawArea for fast GdArea
>     * rewrite GdArcAngle to fix bug w/small angles, no fp required
>     * add font file parameter to fontdemo
> 9 September 2007 - ####@####.####
>     * fix EPRINTF for gcc 3.x (Petr)
>     * fix ft1 return on zero height/width characters (Alexander)
>     * fix GrNewBitmapFromData pad when byte swapped (Martin)
>     * break GrBitmap requests into MAXREQUESTSZ size packets (Martin)
>     * fixed freetype2 font rotation, baseline, compile w/cache off bugs
>     * added support for freetype2 2.3.5 (forces cache off for now)
> 22 June 2006 - ####@####.####
>     * added complete rop processing to fblin4.c 4bpp driver
> 21 April 2006 - ####@####.####
>     * obtained permission to convert stretchblit code from LGPL to MPL
> 20 December 2005 - ####@####.####
>     * added support for 16bpp 5/5/5 and 5/6/5 images to GdDrawImage (Greg)
>     * added support for 16bpp and 32bpp .bmp files
> 

I am fully agree with this. People move from Nano-X because they see
the last news on site were in 2005 - so they think it is dead.

2008/7/7, Daniel Nyström ####@####.####
> I'd like once again to push for a move to SVN (or better, Bazaar) and
>  using Trac for the website. Then many people could contribute easier
>  both on code but as well the documentation if held in the Wiki included
>  with Trac.
>
>  And it will probably make the project appear more active than it does
>  currently, which hopefully generates more users and contributors.
>
>  Regards
>  Daniel
>
>  On Mon, 2008-07-07 at 11:41 +0200, Fredrik Johansson wrote:
>  > James Johnston skrev:
>  > > I'm looking to use Nano-X in a new open-source project, but the last update
>  > > was in 2005.  Is the project basically dead?  From all appearances this
>  > > appears to be the case.
>  > >
>  > > Best regards,
>  > >
>  > > James Johnston
>  > >
>  > >
>  > > ---------------------------------------------------------------------
>  > > To unsubscribe, e-mail: ####@####.####
>  > > For additional commands, e-mail: ####@####.####
>  > >
>  > >
>  > Nah, it's not dead, it just hasn't had any release for some time now,
>  > the cvs is still beeing updated.
>  >
>  > Here's a snippet from the changelog:
>  >
>  >     * fix .fnt.gz loader padding bug
>  > 6 January 2008 - neuros patches from Vladimir
>  >     * add generic window message send GrSendMsg, GR_EVENT_MSG,
>  > GR_EVENT_MASK_MSG
>  >     * add alpha channel handling in GdDrawImage, alpha support in PNG loader
>  >     * fix bug in GdGetNextTimeout
>  >     * add GrDrawImagePartToFit - draw image from part of source image
>  >     * add MWMODE_SRCTRANSCOPY support in fblin16, applyOp{3,4} macros
>  > for speed
>  >     * remove #include <asm/page.h> in clientfb.c, PAGE_SIZE now internal
>  >     * fix GsWpDrawBackgroundPixmap to work with pixmap window backgrounds
>  > 30 November 2007
>  >     * fix ftell in FNTGZ font subdriver
>  >     * port AGG AntiGrain Geometry, NXLIB and direct hw fb version
>  >     * add MWPF_HWPIXELVAL run-time pixel type to allow no-translation GrArea
>  >     * add back in low level psd->DrawArea for fast GdArea
>  >     * rewrite GdArcAngle to fix bug w/small angles, no fp required
>  >     * add font file parameter to fontdemo
>  > 9 September 2007 - ####@####.####
>  >     * fix EPRINTF for gcc 3.x (Petr)
>  >     * fix ft1 return on zero height/width characters (Alexander)
>  >     * fix GrNewBitmapFromData pad when byte swapped (Martin)
>  >     * break GrBitmap requests into MAXREQUESTSZ size packets (Martin)
>  >     * fixed freetype2 font rotation, baseline, compile w/cache off bugs
>  >     * added support for freetype2 2.3.5 (forces cache off for now)
>  > 22 June 2006 - ####@####.####
>  >     * added complete rop processing to fblin4.c 4bpp driver
>  > 21 April 2006 - ####@####.####
>  >     * obtained permission to convert stretchblit code from LGPL to MPL
>  > 20 December 2005 - ####@####.####
>  >     * added support for 16bpp 5/5/5 and 5/6/5 images to GdDrawImage (Greg)
>  >     * added support for 16bpp and 32bpp .bmp files
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: ####@####.####
>  For additional commands, e-mail: ####@####.####
>
>

: I'd like once again to push for a move to SVN (or better, Bazaar) and
: using Trac for the website. Then many people could contribute easier
: both on code but as well the documentation if held in the Wiki included
: with Trac.
: 
: And it will probably make the project appear more active than it does
: currently, which hopefully generates more users and contributors.

I completely agree that the website makes the project appear
completely out-of-date.  And we need a better source code
control system.

The original problem is that I've never been into keeping
up web pages (obviously).  I put together a plan a couple
of months ago for a complete updating, which was to 
include:

o automated blog-style website with wiki
o release of CVS as 0.92 as is, with 0.93 after some work/testing
o posting of updated API documentation
o move to git or other modern, distributed SCCS

Certainly nano-X should have a website that would allow
user-posting of FAQs, documentation of setup and configuration
issues, how to use fonts, images, transparency, etc.  This
could all go in an open wiki.  I would like a section that
would allow blogging (by me and some others) seperately
from the wiki.  All the current docs could be re-formatted
fairly easily I think.

With regards to SCCS, I've always been nervous with allowing
write capability, because most contributers aren't testing on
enough platforms (and more importantly framebuffer modes.  
However, this was done in the past for
the eCos and RTEMS platforms.  I think moving to a git-style
SCCS would allow users to easily house and handle contributions
if not to the whole, then to each other.  Lately few (in spite of
the way-outdated site) have volunteered many contributions.
And of course I have been behind with some contributions.
(I would like to have a full discussion on issues related
to back-contributions seperately).

Please comment.

Regards,

Greg

I would really like to promote Bazaar as the distributed version control 
system: http://bazaar-vcs.org . It takes the power from Git but makes it 
alot easier to start with. It has, since Februari, become a part of GNU 
and it's the favored tool for Ubuntu development. Please take a look: 
http://bazaar-vcs.org/BzrVsGit

For blogging, the Trac has a blog plugin: 
http://trac-hacks.org/wiki/FullBlogPlugin
Trac has alot of plugins, just take a look at: http://trac-hacks.org

There's just one catch; the Bzr plugin for Trac is still under 
development. Although it works, it can show some strange behavior in 
some particular functions. Nothing critical, but it's still under heavy 
development: https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk

I think this will fit your requests pretty good.

Anyone else like to comment?

Regards
Daniel


Greg Haerr wrote:
> : I'd like once again to push for a move to SVN (or better, Bazaar) and
> : using Trac for the website. Then many people could contribute easier
> : both on code but as well the documentation if held in the Wiki included
> : with Trac.
> : 
> : And it will probably make the project appear more active than it does
> : currently, which hopefully generates more users and contributors.
>
> I completely agree that the website makes the project appear
> completely out-of-date.  And we need a better source code
> control system.
>
> The original problem is that I've never been into keeping
> up web pages (obviously).  I put together a plan a couple
> of months ago for a complete updating, which was to 
> include:
>
> o automated blog-style website with wiki
> o release of CVS as 0.92 as is, with 0.93 after some work/testing
> o posting of updated API documentation
> o move to git or other modern, distributed SCCS
>
> Certainly nano-X should have a website that would allow
> user-posting of FAQs, documentation of setup and configuration
> issues, how to use fonts, images, transparency, etc.  This
> could all go in an open wiki.  I would like a section that
> would allow blogging (by me and some others) seperately
> from the wiki.  All the current docs could be re-formatted
> fairly easily I think.
>
> With regards to SCCS, I've always been nervous with allowing
> write capability, because most contributers aren't testing on
> enough platforms (and more importantly framebuffer modes.  
> However, this was done in the past for
> the eCos and RTEMS platforms.  I think moving to a git-style
> SCCS would allow users to easily house and handle contributions
> if not to the whole, then to each other.  Lately few (in spite of
> the way-outdated site) have volunteered many contributions.
> And of course I have been behind with some contributions.
> (I would like to have a full discussion on issues related
> to back-contributions seperately).
>
> Please comment.
>
> Regards,
>
> Greg
>
>
>
>   

On Mon, Jul 07, 2008 at 12:05:57PM -0700, Greg Haerr wrote:
> With regards to SCCS, I've always been nervous with allowing write
> capability, because most contributers aren't testing on enough
> platforms (and more importantly framebuffer modes.  However, this was
> done in the past for the eCos and RTEMS platforms.  I think moving to
> a git-style SCCS would allow users to easily house and handle
> contributions if not to the whole, then to each other.

provided that there's some way to import from CVS, I don't imagine the
choice of SCCS being terribly important, but I would hate to start from
ground zero in my continual merge process.  I'm having to do enough hand
work as is.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

 provided that there's some way to import from CVS, I don't imagine the
: choice of SCCS being terribly important, but I would hate to start from
: ground zero in my continual merge process. 

Do you mean import TO CVS?  I know git for instance
allows importing from CVS projects, but I'm not sure about
its ability to export to CVS...  something to consider for sure.

:  I'm having to do enough hand work as is.

My last perusal of systems like git (and hopefully bazaar)
have mechanisms that allow for much smoother importation
of fixes and submissions.  Linus swears by how much time
git saves him; there's also ways to import directly from an
email, for instance.

Regards,

Greg
 

On Tue, Jul 08, 2008 at 03:57:38PM -0700, Greg Haerr wrote:
> > provided that there's some way to import from CVS, I don't imagine
> > the choice of SCCS being terribly important, but I would hate to
> > start from ground zero in my continual merge process. 
> 
> Do you mean import TO CVS?  I know git for instance allows importing
> from CVS projects, but I'm not sure about its ability to export to
> CVS...  something to consider for sure.

I'm more concerned about going from CVS to the new SCCS.  it would be
nice to retain the ability to merge from some point in the past.  here
at Frye we are still running a fork of 0.89, and I'd desparately like to
get as much as I can back into the tree, but it doesn't make a lot of
sense until I'm merged with a more recent version of HEAD.

I'm not too worried about going forward, as I assume whatever is chosen
will continue to have source code for unix (Linux and NetBSD) clients
available.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

> -----Original Message-----
> From: ####@####.####
> Sent: Tue, 8 Jul 2008 15:57:38 -0700
> To: ####@####.#### ####@####.####
> Subject: Re: [nanogui] Re: Is Nano-X dead? - Move to SVN+Trac?
> 
>  provided that there's some way to import from CVS, I don't imagine the
> : choice of SCCS being terribly important, but I would hate to start from
> : ground zero in my continual merge process.
> 
> Do you mean import TO CVS?  I know git for instance
> allows importing from CVS projects, but I'm not sure about
> its ability to export to CVS...  something to consider for sure.
> 
> :  I'm having to do enough hand work as is.
> 
> My last perusal of systems like git (and hopefully bazaar)
> have mechanisms that allow for much smoother importation
> of fixes and submissions.  Linus swears by how much time
> git saves him; there's also ways to import directly from an
> email, for instance.


I've heard good things about git but haven't really understand it all. I've only used it to pull and update sources, everything else I still do by patches. I think it would be a good idea to move to a better system but I just never had the time to fully implement one. I would think git is a better candidate because of its wide usage but I would say move to one that would make contribution easier and less work.

Jr.

____________________________________________________________
GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!

My two cents:

Do you think it better to move nano-x source to some source code
repository site like sourceforge.net, gna.org, etc?
It should be easier for maintaining.

-Yi


On Wed, Jul 9, 2008 at 9:51 PM, Junior ####@####.#### wrote:
>> -----Original Message-----
>> From: ####@####.####
>> Sent: Tue, 8 Jul 2008 15:57:38 -0700
>> To: ####@####.#### ####@####.####
>> Subject: Re: [nanogui] Re: Is Nano-X dead? - Move to SVN+Trac?
>>
>>  provided that there's some way to import from CVS, I don't imagine the
>> : choice of SCCS being terribly important, but I would hate to start from
>> : ground zero in my continual merge process.
>>
>> Do you mean import TO CVS?  I know git for instance
>> allows importing from CVS projects, but I'm not sure about
>> its ability to export to CVS...  something to consider for sure.
>>
>> :  I'm having to do enough hand work as is.
>>
>> My last perusal of systems like git (and hopefully bazaar)
>> have mechanisms that allow for much smoother importation
>> of fixes and submissions.  Linus swears by how much time
>> git saves him; there's also ways to import directly from an
>> email, for instance.
>
>
> I've heard good things about git but haven't really understand it all. I've only used it to pull and update sources, everything else I still do by patches. I think it would be a good idea to move to a better system but I just never had the time to fully implement one. I would think git is a better candidate because of its wide usage but I would say move to one that would make contribution easier and less work.
>
> Jr.
>
> ____________________________________________________________
> GET FREE 5GB EMAIL - Check out spam free email with many cool features!
> Visit http://www.inbox.com/email to find out more!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>