| |
HeeHeee!
I have great faith in Tim that one day LDraw will become an
open project, but I don't think it has ever been one in the
past! :)
As soon as the parts library is opened up, I promise
I'll check it all into Sourceforge.org, so one can use industry-
standard tools like CVS to update parts and see what is new,
check in bug fixes (if permissions allow), record versioning
information, etc.
-gyug
In lugnet.cad.dev, Fredrik Glöckner writes:
> ">It seems to me that LDraw has become a project of secrecy and inside
> work. When did it stop being an "open" project? When did discussions
> concerning LDraw cease to be done in the open? I think I missed this.
>
|
|
| |
"Paul Gyugyi" <paul@gyugyi.com> writes:
> I have great faith in Tim that one day LDraw will become an open
> project, but I don't think it has ever been one in the past! :)
This sounds almost like communistic ideology: For the project to
ultimately become open, it must first become more closed for a while!
;-)
> As soon as the parts library is opened up, I promise I'll check it
> all into Sourceforge.org, so one can use industry- standard tools
> like CVS to update parts and see what is new, check in bug fixes
> (if permissions allow), record versioning information, etc.
That's undoubtedly an interesting idea.
Fredrik
|
|
| |
In lugnet.cad.dev, Paul Gyugyi wrote:
> As soon as the parts library is opened up, I promise
> I'll check it all into Sourceforge.org, so one can use industry-
> standard tools like CVS to update parts and see what is new,
> check in bug fixes (if permissions allow), record versioning
> information, etc.
Paul,
I don't know if you saw earlier messages about the Part Tracker, but there
was some discussion about whether or not we could use CVS as a backend to
an automated system. What do you think?
There are a number of features we need that (I think) CVS does not offer
'out of the box'. These are:
1. Unofficial/Official flag. When files are submitted, they are
unofficial. Once they're released, they're official. Or turn this around,
and once files are official (ie, certified), they're released.
2. Certification process. After files are submitted, they need to be
peer-reviewed. After they're peer-reviewed and OK'ed, they can be
auto-included in the next update cycle.
3. File-checking. When files are submitted, they should be auto-checked
for syntactic problems.
A couple of issues with using CVS in development with the Parts Tracker
are: (remember, I've got no experience with CVS; some of these could be
ignorance)
1. NIH. Discount this one if you want. Or call it 'unfamiliarity with CVS
causes project to be more complicated rather than less'.
2. CVS gives us functionality that is nice to have, but not required for
the PT.
STeve
|
|
| |
In lugnet.cad.dev, Steve Bliss writes:
> I don't know if you saw earlier messages about the Part Tracker, but there
> was some discussion about whether or not we could use CVS as a backend to
> an automated system. What do you think?
I'll go look up the discussion. I'm just getting back into the
swing of things. I think CVS would be a great way of distributing
the parts. There's clearly some managment tools needed to help
with organizing the submissions and reviews of new parts. Some
of this could be helped with CVS, but you would probably need
a front-end program. If you go to www.sourceforge.com and
search for "wincvs", you'll find the "The CvsGui project" with
MFC C++ sourcecode for calling CVS and other things that will
help tie CVS into a front-end. A popular front end, WinCVS,
should be at http://www.wincvs.org, but that site seems down today.
> There are a number of features we need that (I think) CVS does not offer
> 'out of the box'. These are:
>
> 1. Unofficial/Official flag. When files are submitted, they are
> unofficial. Once they're released, they're official. Or turn this around,
> and once files are official (ie, certified), they're released.
This could be managed with CVS branches. One branch, the unofficial,
can be updated by anyone. The other, the official, is read-only.
The LDRAW Overlord Government is responsible for approving parts,
and moves them from one branch to the other. When you get files
with CVS, it can insert comments in the files that say which
branch the files came from.
> 2. Certification process. After files are submitted, they need to be
> peer-reviewed. After they're peer-reviewed and OK'ed, they can be
> auto-included in the next update cycle.
CVS lets you find out "what is new" in a repository. For instance,
the command "cvs diff -rFEB2001_RELEASE *.dat" would show me all files
that are different since the febuary 2001 release (I assuming I tagged
the files with the FEB2001_RELEASE label at the time of the release).
I'm afraid CVS doesn't give you any additional help in organizing
peer-review, although I'll see if source-forge's bug tracking
abilities can be of use.
> 3. File-checking. When files are submitted, they should be auto-checked
> for syntactic problems.
You'll need a front-end for this.
> A couple of issues with using CVS in development with the Parts Tracker
> are: (remember, I've got no experience with CVS; some of these could be
> ignorance)
>
> 1. NIH. Discount this one if you want. Or call it 'unfamiliarity with CVS
> causes project to be more complicated rather than less'.
I've been using CVS for a few years now. It is complicated, but only
because the tasks involved are complicated. The big advantage is
being able to find out what is new and what has changed
(and who changed it).
> 2. CVS gives us functionality that is nice to have, but not required for
> the PT.
>
> STeve
|
|
| |
In lugnet.cad.dev, Paul Gyugyi writes:
> In lugnet.cad.dev, Steve Bliss writes:
> > I don't know if you saw earlier messages about the Part Tracker, but there
> > was some discussion about whether or not we could use CVS as a backend to
> > an automated system. What do you think?
>
> I'll go look up the discussion. I'm just getting back into the
> swing of things. I think CVS would be a great way of distributing
> the parts. There's clearly some managment tools needed to help
> with organizing the submissions and reviews of new parts. Some
> of this could be helped with CVS, but you would probably need
> a front-end program. If you go to www.sourceforge.com and
> search for "wincvs", you'll find the "The CvsGui project" with
> MFC C++ sourcecode for calling CVS and other things that will
> help tie CVS into a front-end. A popular front end, WinCVS,
> should be at http://www.wincvs.org, but that site seems down today.
>
> > There are a number of features we need that (I think) CVS does not offer
> > 'out of the box'. These are:
> >
> > 1. Unofficial/Official flag. When files are submitted, they are
> > unofficial. Once they're released, they're official. Or turn this around,
> > and once files are official (ie, certified), they're released.
>
>
> This could be managed with CVS branches. One branch, the unofficial,
> can be updated by anyone. The other, the official, is read-only.
> The LDRAW Overlord Government is responsible for approving parts,
> and moves them from one branch to the other. When you get files
> with CVS, it can insert comments in the files that say which
> branch the files came from.
>
> > 2. Certification process. After files are submitted, they need to be
> > peer-reviewed. After they're peer-reviewed and OK'ed, they can be
> > auto-included in the next update cycle.
>
>
> CVS lets you find out "what is new" in a repository. For instance,
> the command "cvs diff -rFEB2001_RELEASE *.dat" would show me all files
> that are different since the febuary 2001 release (I assuming I tagged
> the files with the FEB2001_RELEASE label at the time of the release).
> I'm afraid CVS doesn't give you any additional help in organizing
> peer-review, although I'll see if source-forge's bug tracking
> abilities can be of use.
>
>
> > 3. File-checking. When files are submitted, they should be auto-checked
> > for syntactic problems.
>
> You'll need a front-end for this.
I think a small script running "l3p -check" called from within the CVS
commitinfo file would work great for this.
>
> > A couple of issues with using CVS in development with the Parts Tracker
> > are: (remember, I've got no experience with CVS; some of these could be
> > ignorance)
> >
> > 1. NIH. Discount this one if you want. Or call it 'unfamiliarity with CVS
> > causes project to be more complicated rather than less'.
>
> I've been using CVS for a few years now. It is complicated, but only
> because the tasks involved are complicated. The big advantage is
> being able to find out what is new and what has changed
> (and who changed it).
>
>
> > 2. CVS gives us functionality that is nice to have, but not required for
> > the PT.
> >
> > STeve
|
|
|
