Re: Overloading __index and __newindex

On 2/14/2012 8:19 AM, Ryan Pavlik wrote:
>
>
> On Mon, Feb 13, 2012 at 8:12 PM, Jason McKesson <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     On 2/13/2012 11:33 AM, Ryan Pavlik wrote:
>     > Personally, I am OK with the current status of the project and would
>     > not consider it abandonware - I work on it quite frequently. It
>     would
>     > be nice to get some communication going for perhaps an eventual
>     future
>     > release, but until then, unless you need a version number prettier
>     > than "git describe" can give you, I'd say just pick an updated fork
>     > and use it. Mine has been substantially cleaned up and improved
>     > (support for SFINAE/boost::enable_if for native converters, applied
>     > suggestions of include-what-you-use to decrease build time,
>     > cmake-based build system that includes the tests, etc.) and is being
>     > used in production currently.  I've even got the documentation
>     > automatically building and uploading.
>     >
>     > Ryan
>     It's not about whether you "need a version number." It's about
>     having an
>     actual project, rather than a bunch of disparate code running around.
>     You don't see SWIG or other projects operate like that, with no real
>     notion of version or functioning code. The reason why is because
>     someone
>     actually owns the project and makes regular releases of it.
>
>     Saying "pick an updated fork and use it" is basically saying, "Luabind
>     is abandoned." That's what an abandoned project looks like: it's just
>     forks, whatever some random people look at and poke at. If nobody's
>     willing to stand behind it by naming it, giving it a real version, and
>     making a distribution (and no: downloading a Git repo is not a
>     distribution), then it's a dead project.
>
>
>
> Well, except for the fact that the original authors occasionally still 
> update their branch, I'd say I'd probably have already tagged good 
> releases, and I'd be happy to do this going forward.  (I see this kind 
> of the same way GitX has evolved - original authors nearly 
> disappeared, a few forks emerged, and one became the effective new 
> upstream - laullon's fork aka GitX(L).  I've actually done the same 
> thing with the Wiiuse library after the original upstream completely 
> disappeared, and that has worked quite well - I've gotten pull 
> requests and when I have time I'm happy to merge and tag releases.)
>
> Ryan
> -- 
> Ryan Pavlik
> HCI Graduate Student
> Virtual Reality Applications Center
> Iowa State University
>
> [email protected] <mailto:[email protected]>
> http://academic.cleardefinition.com

Tagging a release is not the same as /making/ a release. Making a 
release involves removing unimportant things from the distro (tests and 
such), building the docs, packaging it in a zip file, and putting it up 
for others to download, usually with release notes about what has 
changed and what is new (and no, a series of changelists is /not/ a 
substitute for proper release notes).

No self-respecting project requires you to pull from a repo in order to 
get the actual code you're supposed to use. To get the trunk, yes. But 
not a particular release. That's the /whole point/ of having a release; 
that's why it's called a "release". Forcing people to pull from Git just 
to get an up-to-date version of the project is indicative of a project 
that barely exists, who's community is anemic and near-dead, and one 
that people would be il-advised to continue using.

Managing a repository is good. Having a repo that should be considered 
the official "trunk" is good, and having a maintainer of that repo be 
ready to take patches and such is good. These are all important for 
being able to develop code.

But these things are /not/ a substitute for proper releases to users. We 
still need to have actual releases and an actual website where the new 
documentation and info about releases, repos, etc can go. What we have 
now is simply not an acceptable state of affairs and something needs to 
be done about it if Luabind is going to continue to be a useable project.

You point to GitX, but that's not a good example. It has a website. It 
has actual releases packaged as zip-files. It's a real, living, 
breathing project. It may have changed /ownership/, but it's still alive.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

_______________________________________________
luabind-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luabind-user