Worrying developments in Producer land
Robert Osfield
Since Don's pulling out of supporting the OSG he's got the bit between his teeth and is refactoring Producer. Which after a number of years a stagnation perhaps is no bad thing, but the way Don is going about it is worrying.
First up, he introduced a circular dependency between Producer and OSG. His attitude is the OSG should be refactored to accomodate these changes.
Next up he's now ported across to using DWMake without warning the OSG community about it.
Finally rather than engage the OSG community, and warn us, he's expecting users to subscribe to a new mailing list. Having just browsed through the emails so far its clear that he's priorities are entirely within Producer now, and if anything going towards anti-OSG and anti osgProducer.
Him dumping support of the OSG server/website etc is worrying enough, but this current rapid flux of Producer and non engangement of the OSG community is got my hackles up, what next? How do I keep the OSG and osgProducer building?
My currently feeling is AARFHGHGHGHH!!!!
What to do? How do wel limit the damage that this is causing? Branch Producer before things diverge too much?
I really really could do with these extra hassles and stress, if this is part of Don's plans then hey its working.
Thanks in advance for you wisdom and hopefully calming influence.
Robert.
Gordon Tomlinson
While I use Producer for some things, at Work work we don't use producer, although I miss some of the data it makes available over a straight sceneview
So for me its not too much of a problem.
But I suppose for backward compatibility and for folks that do use Producer a branch or snap shot of the last working set would be good.
G.
Email : gor...@gordon-tomlinson.com
YIM/AIM : Gordon3dBrit
MSN IM : Gordon...@3dscenegraph.com
Website : www.3dscenegraph.com
__________________________________________________________
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
- Master Tambo Tetsura
Robert Osfield
Time for a few beers and an odd dram or 2...
Absolutely. Once this transition period is over I will be able to relax and really enjoy a beer, and odd or even number of drams :)
While I use Producer for some things, at Work work we don't use producer, although I miss some of the data it makes available over a straight sceneview
So for me its not too much of a problem.
But I suppose for backward compatibility and for folks that do use Producer a branch or snap shot of the last working set would be good.
Its possible to get the CVS Producer with the OSG working but its adding lots of hoops that weren't there before. Even once we are through the current flux this will still be the case.
Trying to keep CVS working solidily is something I strive for with the OSG - my philosophy is that if you keep CVS working most of the time then more people will use it, then the more people will catch problems when they are checked in, and the higher quality of software you end up with.
Using OSG, OP, OT CVS has suddenly become a mine field.
Robert.
Paul Martz
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On Behalf Of Robert Osfield
Sent: Wednesday, November 15, 2006 8:32 AM
To: osg-crew
Subject: [osg-crew] Worrying developments in Producer land
Jan Ciger
Hash: SHA1
Paul Martz wrote:
> The easiest short-term option is to tag Producer at a known-good date and
> time and loudly advertise this to osg-users and the wiki. Once us CVS users
> check out sticky to that tag, nothing else need be done.
>
> However, given that you don't need Producer to use OSG (we used OSG without
> Producer at my previous employer), then the right thing to do long-term is
> to move osgProducer and osgProducer-based examples out of the core OSG
> distribution. Robert, at the Highlands Gathering, I do recall you mentioned
> wanting to move osgProducer into a "deprecated" distribution, so this
> doesn't seem very different from what you had already planned?
>
> I view OSG's dependency on Producer as incorrect and unnecessary (especially
> in light of the recent birth of osgViewer, which will eventually eliminate
> the need for Producer). Long-term, this dependency needs to be removed.
> -Paul
>
I agree with Paul here - when I wrote my reply yesterday regarding this,
I thought that the discussion/issue is just an engineering disagreement.
Seeing Robert's and Don's mails, the problem is clearly elsewhere. I am
not going to speculate what the issue is but when somebody takes his
toys home and OSG has to move, it has most likely little to do with
engineering :(
In this context I would say that for the sake of short-term
usability/compilability of OSG make a snapshot of a known-good version
of Producer, put it on the web site (who knows what happens to the CVS).
The long term solution will be to replace Producer by other code or drop
the parts dependent on it.
It is a pity and also a major issue for me because our applications are
usually building on top of the osgProducer-based viewer. Now I will have
to redo them because maintaining a forked version of Producer is not a
long-term sustainable solution for me. I am not a happy camper here and
I am probably not the only one - the viewer was something taken for
granted.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFW1z7n11XseNj94gRAod9AJwMxF69ZpXyCeUBGwaok3hxZGuhJwCeIxtJ
TaVE7US6l2t5xh6rgHc8VIo=
=n4BW
-----END PGP SIGNATURE-----
Robert Osfield
The easiest short-term option is to tag Producer at a known-good date and time and loudly advertise this to osg-users and the wiki. Once us CVS users check out sticky to that tag, nothing else need be done.
The last Producer tag was for the 1.1 release. I'll notify osg-users.
However, given that you don't need Producer to use OSG (we used OSG without Producer at my previous employer), then the right thing to do long-term is to move osgProducer and osgProducer-based examples out of the core OSG distribution. Robert, at the Highlands Gathering, I do recall you mentioned wanting to move osgProducer into a "deprecated" distribution, so this doesn't seem very different from what you had already planned?
Well osgProducer "was" along way from being deprecated, I had no immediate plans for moving it out of the core OSG, only mid to long term plans. It was a possibility for the 1.3, but there wasn't a strong reason for it to happen. Reasons not to were helping the community by keeping making a slow migration towards osgViewer, not by deprecating osgProducer right away.
As far as Don is concerned he has now deprecated osgProducer.
I view OSG's dependency on Producer as incorrect and unnecessary (especially in light of the recent birth of osgViewer, which will eventually eliminate the need for Producer). Long-term, this dependency needs to be removed.
Well Producer should have been part of the core OSG right from the begining. Its always been an artificial thing that Don has maintained for his own personal reasons rather than good software engineering reasons. The OSG would have been better served by an internal osgProducer librray with Producer integrated into it. While not elegant this external dependency hasn't been a liability until now.
Long term osgViewer is will cover all that Producer can do today, plus it can solve all the types of task that hasn't been well served right now. However, right now it only does the later, covering the gaps which Producer leaves in terms of viewer coverage, right now is complimentary in the problem domain i.e. they solve different problems for different types of users.
I was really hoping for a graceful move to osgViewer, with users who've already adopted osgProducer/Producer remaining well supported and not forced to move over to any new osgViewer or Producer versions.
Ack blown up in my face this one ;-|
Robert.
Robert Osfield
I agree with Paul here - when I wrote my reply yesterday regarding this,
I thought that the discussion/issue is just an engineering disagreement.
Seeing Robert's and Don's mails, the problem is clearly elsewhere. I am
not going to speculate what the issue is but when somebody takes his
toys home and OSG has to move, it has most likely little to do with
engineering :(
This issue goes along way back. Basically my vision the OSG has diverged from what Don wants, and Don isn't able to dictate to me to follow his path for where he thinks scene graphs and viewers should be. Over the years there have been a number of instances where Don has resisted choices I've made for the future direction OSG but I've sat back considered his opinion but still plowed ahead.
While this hasn't been great on Don's ego, the project has succeded, so my guess is that by design choices have been generally ok. Few decisions have back fired on me, until now - but as you point out has *nothing* to do with engineering.
In this context I would say that for the sake of short-term
usability/compilability of OSG make a snapshot of a known-good version
of Producer, put it on the web site (who knows what happens to the CVS).
The long term solution will be to replace Producer by other code or drop
the parts dependent on it.
Sadly I've already done a cvs update so my version is already shot.
The 1.1 release should be ok, and will probably compile just fine the CVS version of the OSG.
It is a pity and also a major issue for me because our applications are
usually building on top of the osgProducer-based viewer. Now I will have
to redo them because maintaining a forked version of Producer is not a
long-term sustainable solution for me. I am not a happy camper here and
I am probably not the only one - the viewer was something taken for
granted.
I feel for you. Its a *nightmare*.
I feel a great responsibility to those who have OSG adopted. Its no small thing to use external products, integrate in your applications make you daily lives dependent upon it.
Umm... this is exactly what I did when I was adopting Producer for the OSG viewer code. I feel very exposed right now. No doubt lots of osg users are feeling it right now ;-|
Robert.
Jan Ciger
Hash: SHA1
Hi,
Robert Osfield wrote:
> Sadly I've already done a cvs update so my version is already shot.
>
> The 1.1 release should be ok, and will probably compile just fine the CVS
> version of the OSG.
I have a working snapshot from 9th October if it helps.
> I feel for you. Its a *nightmare*.
>
> I feel a great responsibility to those who have OSG adopted. Its no small
> thing to use external products, integrate in your applications make you
> daily lives dependent upon it.
Thanks.
> Umm... this is exactly what I did when I was adopting Producer for the OSG
> viewer code. I feel very exposed right now. No doubt lots of osg users
> are feeling it right now ;-|
>
> Robert.
Well, sometimes such upset is needed to speed-up things, however I
wonder what good will this one do. Fortunately, our applications are not
heavily Producer-dependent, it shouldn't be too difficult to change
them, however it is still an issue of time and resources, particularly
at a university where we are bogged down with other things than coding.
On a brighter note - I have got this from one of my acquaintances:
> Equalizer 0.1 Released
>
> We are pleased to announce the first release of Equalizer, a framework for
> the development and deployment of scalable multipipe OpenGL applications.
> Equalizer 0.1 is the first official release. It is intended as a
> preview and evaluation snapshot for application developers and early
> adopters. This release supports the following features:
>
> * Support for parallel rendering on distributed and shared memory systems
> * Support for active and passive stereo rendering
> * Support for scalable passive stereo rendering
> * Support for head tracking
> * Software-based swapbarrier support for synchronization of multipipe
> display systems
>
> More information about this release can be found at:
> http://www.equalizergraphics.com
>
> The full release notes are available on:
> http://www.equalizergraphics.com/documents/RelNotes/RelNotes_0.1.0.html
The guy developing this is a former SGI engineer who worked on
Performer. I have tested it, it seems to work fine and could be easily
used with OSG, IMHO.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFW2jwn11XseNj94gRAhGqAJkBKInSXzIcPmrNawKAtF3Ozss/bgCfYn3M
HDghDnADrdmz0nHHk/9CG0c=
=fq2J
-----END PGP SIGNATURE-----
Robert Osfield
I have a working snapshot from 9th October if it helps.
It does, its gold dust!!! Don't touch it other than to zip it up and post it to me ;)
Its a shame we don't have a tag on it, but alas that window of opportunity has passed.
Jose has set up some space on hist dreamhost account, perhaps we could try an experiment of importing it.
Well, sometimes such upset is needed to speed-up things, however I
wonder what good will this one do.
Short term its a case of damage limitation.
As long as we get through these present problems mostly intact the project should be stronger. The community will be more involved in day to day running. A the project direction won't be so contended, and I won't be so exhusted from battles with Don.
Right now though, I'm physically and emotionally knacked. I have been working full out for a number of months and several more months of the work left to get out the door, this is my life I can keep high work rates for long period, but don't have too much left in reserve. But then this mess happens.
Fortunately, our applications are not
heavily Producer-dependent, it shouldn't be too difficult to change
them, however it is still an issue of time and resources, particularly
at a university where we are bogged down with other things than coding.
I don't think there should be any short term need to change. My hope would be to entice you over to osgViewer by lots of new powerful and elegant ways of solving tasks rather than needing to change because of circumstances.
On a brighter note - I have got this from one of my acquaintances:
> Equalizer 0.1 Released
>
I had spotted the notice on OpenGL.org.
Robert.
Paul Martz
Sent: Wednesday, November 15, 2006 12:57 PM
To: osg-...@googlegroups.com
Subject: [osg-crew] Re: Worrying developments in Producer land
Robert Osfield
Can't you simply check out sticky to that date and then apply a tag?
I haven't tried playing with stick dates before. Care to try and pot me a recipe?
I have tried Producer-1.1 from the OSG-1.2 release, and the current OSG CVS compiles fine, so push comes to a shove we could simple use that.
Robert.
Eric Sokolowsky
Robert Osfield wrote:
> HI Jan,
>
> On 11/15/06, Jan Ciger <jan....@gmail.com> wrote:
> >
> > I have a working snapshot from 9th October if it helps.
>
>
> It does, its gold dust!!! Don't touch it other than to zip it up and post it
> to me ;)
>
> Its a shame we don't have a tag on it, but alas that window of opportunity
> has passed.
With a bit of work, I think we can re-tag the last known good version.
CVS has an option similar to the -r option for specifying a particular
tag: -D for date. Just identify a date/time combination that works,
enclosed in quotations, such as "2006-10-09 15:00", check out a version
with that date/time, and then use the cvs tag option to tag it. I
haven't tried it but it will probably work.
If this tag trick doesn't work those who use Producer's CVS version can
check out the last known good snapshot for themselves in their own
repository, once we identify the exact time of the snapshot that works.
Robert Osfield
On 11/15/06, Eric Sokolowsky <eric.so...@gsfc.nasa.gov> wrote:
> With a bit of work, I think we can re-tag the last known good version.
> CVS has an option similar to the -r option for specifying a particular
> tag: -D for date. Just identify a date/time combination that works,
> enclosed in quotations, such as "2006-10-09 15:00", check out a version
> with that date/time, and then use the cvs tag option to tag it. I
> haven't tried it but it will probably work.
Ok I got a sticky date checked out with the above.
It has the OsgViewer example in it, but not the rest of the new
ProducerOSG and related stuff.
I can tag this. Thoughts?
Robert.
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
> Hi Paul,
>
> On 11/15/06, Paul Martz <pma...@skew-matrix.com> wrote:
>> Can't you simply check out sticky to that date and then apply a tag?
>>
>
> I haven't tried playing with stick dates before. Care to try and pot me a
> recipe?
I think that what he wants is to check out an older revision to that
date and then tag/branch it.
That is done like this:
cvs get -D <date> project
and then tag it.
Alternatively, you can use also an rtag command:
cvs rtag -D <date> <tag>
If you want to branch/fork it instead, use the -b switch to the tag/rtag
command:
cvs tag -D <date> -b <tag>
The whole thing is documented here:
http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs.html
BTW: CVS->SVN HOWTO:
http://sam.zoy.org/writings/programming/svn2cvs.html
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFW5ENn11XseNj94gRAu3SAJ9DDAtiZNAcJbXLvbV5MBdOzFN3igCbBl69
l7BcXF4azKjZG3CsWDag8GY=
=EERR
-----END PGP SIGNATURE-----
Robert Osfield
On 11/15/06, Jan Ciger <jan....@gmail.com> wrote:
> I think that what he wants is to check out an older revision to that
> date and then tag/branch it.
>
> That is done like this:
>
> cvs get -D <date> project
> and then tag it.
>
> Alternatively, you can use also an rtag command:
> cvs rtag -D <date> <tag>
Ahh, a bit more less keystrokes than what I ended up with, but I got
there in the end.
I have back dated Producer to 2006-10-09 and set the tag to
Producer_OpenSceneGraph_BranchPoint. I have also tagged the current
main trunk in
OpenThreads and OpenSceneGraph for posterity.
> If you want to branch/fork it instead, use the -b switch to the tag/rtag
> command:
>
> cvs tag -D <date> -b <tag>
I haven't branched yet.
The question is what to do next. The immediate build issues are got
around with these tagging, so critical nature of the issue is isolated
for the time being so I can at least sleep easy.
Thanks for your help out on this guys, saved me much time and anguish
pointing out what was really obvious if I only I had my head screwed
on problem :-)
Note to crew, feel free to point on the bl**ding obvious if I'm being
too dumb to spot it!
My plan is to sleep on what to do next about the Producer dependency.
Whatever happens supporting existing OSG users is my top priority, and
keeping the OSG_OP_OT tripleset coherent and usable. Once we have a
stable base then we can start looking at longer term plans.
Robert.
Robert Osfield
Slept better later night, but still awoke early with mind racing. Boy
I'm be happy camper once things are all settled down.
Having slept on it I feel that it would be worth branching Producer,
and maintain the branch ourselves, primarily for the purpose of
maintaining compatibility and ease the build complexities that have
evolved over the past few years, and particularly over the past week.
My suggestion for a name of the project is CoProducer, or Cooperative
Producer. I am prepared to personally manage this branch for the
purposes of the OpenSceneGraph project. Having done the past 3
releases of Producer with Don's assistance, the effective workload
will actually be little different to what it has already been over the
past year.
I don't have any grand plans for CoProducer, just that it would
integrate well the OSG's way of building and distributing, it would
remain a close member of the family.
Now in an ideal world Don and I would be getting along fine and all
this wouldn't be required, but we are not getting along fine. Trying
to get another TripleSet (or what it would up being a QuinSet) would
be next to impossible.
Don is going his own route with Producer, which is perfectly fine, but
the way he's headed simply doesn't serve the purpose the OSG has
previously relied upon Producer for. OSG doesn't need grand Producer,
it just needs a humble library to set up windows, and manage camera
and associated threads, and a library that fits well into the wider
scheme of the OSG distribution.
Thoughts?
Robert.
Mathieu MARACHE
2006/11/16, Robert Osfield <robert....@gmail.com>:
As and end user I was trying not to get involved in these discussions.
But I understand that we are at a crossroad (as end users) and must
choose the right path.
My personnal view on this is that we need a compromise.
My understanding is that OSG needs a simpleViewer scheme but others
(like me) need the 'grand Producer'.
My proposition would be to remove OSG's dependency on Producer and
develop the simpleViewer, but keeping it simple. Then have Producer
depend on OSG and take responsibility of the osgProducer (or
ProducerOSG as it seems). It's not an easy step as it would break code
compatibility but it is a far more clear situtation than forking an
active project.
These were my 0.02€
Best regards,
--
Mathieu
Robert Osfield
On 11/16/06, Mathieu MARACHE <mathieu...@gmail.com> wrote:
> As and end user I was trying not to get involved in these discussions.
> But I understand that we are at a crossroad (as end users) and must
> choose the right path.
>
> My personnal view on this is that we need a compromise.
While compromise is all very good in theory, lets all be friends, big hug!!!!
The fact is that Don has dumped his support the OpenSceneGraph
project. Don's ambitions for Producer don't reflect the needs of the
OpenSceneGraph project.
What the OpenSceneGraph project needs is stability, and easing of the
burden of build complexities. The OpenSceneGraph project also need to
know it can depend on the project leads of its main dependencies and
to be locked in step with them, otherwise we end up build hell.
Things are hard enough as it is without making things even more
complicated on the build front.
> My understanding is that OSG needs a simpleViewer scheme but others
> (like me) need the 'grand Producer'.
What you need is not "grand Producer" but a viewer library that suits
your needs and is easy to use. You need to spell out what these needs
are. These may or may not coincide with what Don wants for Producer.
> My proposition would be to remove OSG's dependency on Producer and
> develop the simpleViewer, but keeping it simple. Then have Producer
> depend on OSG and take responsibility of the osgProducer (or
> ProducerOSG as it seems). It's not an easy step as it would break code
> compatibility but it is a far more clear situtation than forking an
> active project.
But then you need to maintain osgProducer with it trying to track
Producer and OSG, it's versioning is going to be hard work trying to
track all the different moves in each library. Its a fine engineering
solution to pluck out of the air, but much less practical actually
doing it.
Also please note down just how many project dependencies and build
systems osgProducer would require. Who will want to jump through all
these hoops? Who will want to lead such a difficult project? I have
been way too burnt by Don to want to go near being dependent on him
any further. So are you volunteering to lead split osgProducer out
and then lead the project? If not you who else?
Personally I think moving osgProducer out and then trying to maintian
it as a seperate project dependent on Don's Producer and the
OpenSceneGraph is too impratical, and would be the death sentence for
the project. People currently rely upon osgProducer, we owe to them
to make sure that it at least stays stable.
For those who wish to use osgViewer and the new style Producer then
fine, there are much less dependency issues with either of these
routes. But branching Producer is about saving osgProducer, I am
certainly not about to dump osgProducer support you simply can't piss
users around this much.
We need to stop hoping for the best, hoping that things can be mended
- I've tried this over the last two years and look where it got me.
Things can't be soothed over, its delusional to think they can, we
need to get accept the new situation, and work out to how go forward.
Robert.
Robert Osfield
To help osgProducer from external changes, and to keep it in sync with
the next OSG release, and consistent with OSG's build system (whatever
that might be), for the next OSG release we could either:
1) Make CoProducer a clone of Producer, but keep it consistent with
OSG build style etc.
Keep osgProducer in core OSG, leaving the status quo pretty well as it was.
Release a OSG_CP_OT triple set.
2) Make CoProducer a clone of Producer, but keep it consistent with
OSG build style etc.
Move osgProducer out of core OSG, this changes release structure
Release a OSG_OT double set.
Release a CP_osgProducer double set.
3) Make CoProducer/osgProducer which contains both CoProducer and osgProducer,
keep it consistent with the OSG build style etc. Moving
osgProducer out of core OSG.
Release a OSG_OT double set.
Release a CoProducer/osgProducer release.
4) Move osgProducer out of core OSG, keep it dependent on Don' Producer
Release a OSG_OT double set.
Release a osgProducer release. But which version of the Producer
to you sync it
with?
Now I will expect most people will get all positive about route #4,
but one has to wake up to the fact that I'm not going to burn my life
away trying to work with collaboratively with Don, its soul
destroying. I will not personally do go anywhere near #4. So if you
really think #4 is goer than you need to volunteer yourself to do the
work.
#1 is a pretty easy option, its basically the status quo we've had for
the past year. I'm happy to merge bug fixes etc to CoProducer, and
happy to maintain osgProducer alongside it and keep them in sync for
joint release with OSG-1.3.
#2 this is a less easy option, as it effectively bumps the number of
projects I have to maintain and keep iin sync for a release up to 4.
#3 short term this is more work than 1, but when it comes to making
releases at least
there are just still just 3 projects to coordinate and release. This
is manageable.
In terms of cleaness, and long term manageability I believe #3 to be
the right way forward. It is however, a lot more work in the short
term than just going with #1. Perhaps go for #1, then migrate across
to #3 when the time is right, be this before or after OSG-1.3.
Thoughts?
Robert.
Shue, John
amount of work, but I agree that in the long term #3 is the better
solution, but it might be more managable for a later release like 1.4.
I do like the OSG_OT double set. I think it is better for those of us
who don't have projects that depend on Producer.
-john
-----Original Message-----
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On
Behalf Of Robert Osfield
Sent: Thursday, November 16, 2006 8:52 AM
To: osg-...@googlegroups.com
Subject: [osg-crew] Re: Worrying developments in Producer land
Thoughts?
Robert.
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you.
Robert Osfield
>
> Option #1 is probably the best for a 1.3 release as it reduces the
> amount of work, but I agree that in the long term #3 is the better
> solution, but it might be more managable for a later release like 1.4.
>
> I do like the OSG_OT double set. I think it is better for those of us
> who don't have projects that depend on Producer.
Ideally I'd actually like the OSG to be releasable as is without OT as
part of double set. I just want one single download, build and
install, save for the standard dependencies that is, but these really
should be binaries, so OT would be part of this dependency set rather
than part of the OSG release package.
The only problem with this is the OSG drivers OT development and
releases, it would be nice though it is were a more lively and self
managing project in its own right. This is another topic for another
month though
Robert.
Douglas Campos
>
> On 11/16/06, Shue, John <John...@mantech-ist.com> wrote:
> >
> > Option #1 is probably the best for a 1.3 release as it reduces the
> > amount of work, but I agree that in the long term #3 is the better
> > solution, but it might be more managable for a later release like 1.4.
just my .02 Cents
Robert Osfield
the CoProducer/osgProducer direction right now?
I'm inclined to wait a day. Let my own and others thoughts settle.
However, I'm concerned about user worrying about a vacuum in direction
and support for the API's they rely upon. Reassurance might be
required.
Robert.
Joe Sullivan
Those familiar with the project know that problems don't tend to
fester - they're handled quickly and efficiently.
More casual users will not likely notice.
Time to let the dust settle a bit is a good thing.
On 11/16/06, Robert Osfield <robert....@gmail.com> wrote:
>
Paul Martz
> Producer_OpenSceneGraph_BranchPoint. I have also tagged the
> current main trunk in OpenThreads and OpenSceneGraph for posterity.
This should not be necessary. I just checked out current CVS of OT/P/OSG and
built all successfully, in that order, on Windows. Don had introduced a
couple issues with the Windows build, and the fix was delayed due to a crash
on his Windows system (thank you Microsoft) but the issues are now resolved.
-Paul
Paul Martz
> Producer, and maintain the branch ourselves, primarily for
> the purpose of maintaining compatibility and ease the build
> complexities that have evolved over the past few years, and
> particularly over the past week.
I don't think there will be any compatibility issues. Don has stated that he
has paying customers who depend on Producer and OSG working together. In
that case, Don is not likely to do anything that will break this
compatibility. The build problems we've experienced over the past few days
were easily solved using the tried-and-true "two email" system:
Email #1: "Don, I just checked out current Producer CVS and it doesn't
build."
Email #2: "Thanks, I just checked in a fix for that."
:-)
I don't see any Producer-induced build complexities, either; in my recent
email, current CVS now builds in this order: OT, P, OSG, just as it always
has. (However, that doesn't change my opinion that the OSG distribution
would be better off if Producer were removed as a dependency by putting
osgProducer and osgProducer-based examples in a separate distribution,
replacing the examples as you've already started to do with non-osgProducer
examples).
I do think that a CoProducer might have the slightly negative effect of
introducing more confusion. I think confusion regarding viewers is a
significant problem in OSG, and is largely because of the vast number of
options that users have. Creating more options doesn't reduce the confusion,
it adds to it.
-Paul
Paul Martz
> Personally I think moving osgProducer out and then trying to
> maintian it as a seperate project dependent on Don's Producer
> and the OpenSceneGraph is too impratical, and would be the
> death sentence for the project. People currently rely upon
> osgProducer, we owe to them to make sure that it at least
> stays stable.
osgProducer does appear to have ended up in an orphaned state; neither you
nor Don are interested in it. But I believe you both have paying customers
who are using it? If so, then perhaps the two of you can attempt to not do
anything incompatible with it. For example, Don's recent changes did not
turn out to break osgProducer in any way.)
Also, if osgProducer truly has a significant user base, then it's possible
that a new user community could crop up to own it.
-Paul
Paul Martz
I'd encourage you to wait on this, Robert.
In the past, you and/or Don have both, on occasion, checked in something
that broke a build unintentionally. In the past, it was always resolved
easily be exchanging a couple emails. And that's all that has happened here
these past few days. Don had a paying customer that required him to make
some changes to Producer; those changes caused some problems that have now
been resolved.
The path of least resistance here is to accept that we just had some rough
water, and then carry on as usual. Introducing a new CoProducer on the spur
of the moment risks indicating to the OSG community that we are prone to
knee jerk design decisions with little long-term planning. This is
potentially much more damaging than any perceived vacuum of direction or
support.
The best way to assure people of support at this point is to advertise
loudly that current CVS is fine, which it is (at least on Windows).
I think it would also help if you make a public statement committing to the
long-term viability of osgProducer. I know Don has similarly stated in a
public email that he has paying customers and it is not his intention to
break the OSG build. An email like that from you would really help build the
community's confidence.
-Paul
Jan Ciger
Hash: SHA1
Hello,
Robert Osfield wrote:
> Hi Guys,
>
> Slept better later night, but still awoke early with mind racing. Boy
> I'm be happy camper once things are all settled down.
>
> Having slept on it I feel that it would be worth branching Producer,
> and maintain the branch ourselves, primarily for the purpose of
> maintaining compatibility and ease the build complexities that have
> evolved over the past few years, and particularly over the past week.
>
> My suggestion for a name of the project is CoProducer, or Cooperative
> Producer. I am prepared to personally manage this branch for the
<...>
I do not have a lot of time now (having to get up at 5AM in the morning,
ouch!) but there is one thing I wanted you to be aware of.
I had a discussion with Don by e-mail yesterday and one thing he is not
happy about is this discussion here. Regardless of whether he has a
point or not, one thing is a fact - these discussions about making a
branch or whatever should be done on osg-users, in the open, and not
here. Otherwise osg-crew is going to be (and probably is already)
perceived as a self-appointed secret cabal with an agenda trying to
usurp the project. I certainly do not want that to happen and it
wouldn't help at all.
Some issues are probably better cooked in private and brought out when
ripe, I agree with that. However, that could be handled by private mail
as well and should be avoided if we strive for transparency.
Let's keep osg-crew to the migration issues.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFXTZ/n11XseNj94gRApMvAJ40LBYTDDA+cfVVMi7xsF+R1ryMrQCgrPML
/5eShrYzfRInjsXAti/ODeY=
=QxGJ
-----END PGP SIGNATURE-----
Robert Osfield
On 11/17/06, Jan Ciger <jan....@gmail.com> wrote:
> I had a discussion with Don by e-mail yesterday and one thing he is not
> happy about is this discussion here.
I don't think anyone is happy about what Don has done in pulling out
in the way he has done, and then straight away refactoring Producer
and breaking the build. These discussions are all a direct result of
Don's actions.
My concern is not how Don feels, but how we make sure the OSG project
has a stable base.
> Regardless of whether he has a
> point or not, one thing is a fact - these discussions about making a
> branch or whatever should be done on osg-users, in the open, and not
> here. Otherwise osg-crew is going to be (and probably is already)
> perceived as a self-appointed secret cabal with an agenda trying to
> usurp the project. I certainly do not want that to happen and it
> wouldn't help at all.
I do have concerns about people percieving osg-crew as some kind of
opaque committee that decides things without any regard for others.
However, osg-crew is fully public, anyone can review the archives, and
anyone can join and contribute.
Long term I expect osg-crew discussions is be largely coordinating
daily chores that need to get done, especially in preps for releases.
Design discussions need to be kept in public and this is my plan.
osg-users is for users and contributors to the source code.
The different roles of osg-users and osg-crew is basically what we
came to a consensus on at the Highland Gathering. We did talk lots
about the pros and cons.
Right now we have to deal with a crisis though, and those who are the
sharp end of trying to manage the project are best placed to thrash
out an action plan. osg-crew isn't a talking shop, its a doing shop
where we put all hands on deck and solve the problems before us.
Discussing this on osg-users is inappropriate, its a friendly support
and dev list, we need to keep it that way.
Once the current issues are over osg-crew can take more of project
maintenance role.
Robert.
Robert Osfield
Its good to hear the problems have finally been fixed.
Think of Producer_OpenSceneGraph_BranchPoint as an insurance policy
that I took out to insulate the OSG from potential damage.
Robert.
Robert Osfield
On 11/17/06, Paul Martz <pma...@skew-matrix.com> wrote:
> I don't think there will be any compatibility issues.
There are always compatibility issues, its part of life when
developing with multiple packages that are so closely dependent.
Making the OSG_OP_OT tripleset for the 1.0, 1.1 and 1.2 was a serious
challenge for all those who got stuck in to get the releases out.
Bystanders probably don't realise how much effort is required to keep
things work smoothly together. Those suggesting everything is fine
are generally people haven't got stuck in.
> Don has stated that he
> has paying customers who depend on Producer and OSG working together. In
> that case, Don is not likely to do anything that will break this
> compatibility. The build problems we've experienced over the past few days
> were easily solved using the tried-and-true "two email" system:
>
> Email #1: "Don, I just checked out current Producer CVS and it doesn't
> build."
>
> Email #2: "Thanks, I just checked in a fix for that."
>
> :-)
I'm sorry Paul, I repeatedly pointed the problem out to Don, others
also pointed the problem out, and Don repeatedly said it was a non
issue.
Eventually Don grasped the problem and worked to sort it out, but its
still only a partial solution.
> I don't see any Producer-induced build complexities, either; in my recent
> email, current CVS now builds in this order: OT, P, OSG, just as it always
> has.
Under Unix there is now the extra external dependency on DWMake, if
you don't have this the build is broken. I expect the Xcode projects
will be totally of of sync, so again the build will be broken.
> (However, that doesn't change my opinion that the OSG distribution
> would be better off if Producer were removed as a dependency by putting
> osgProducer and osgProducer-based examples in a separate distribution,
> replacing the examples as you've already started to do with non-osgProducer
> examples).
Longer term I agree with moving osgProducer out. However, knowing how
difficult it is to get a triple set safely out, its not hard to see
that making 5 or 6 separate components kept in sync for a release of
an osgProducer would be nightmare.
The triple set itself has become much more of challenge to pull of due
to Don removing me from the Producer write permission (he did this
after I did the tag), and Don no longer being part of the OSG team.
Previously at least I could merge build and runtime fixes to Producer,
and at least I could make the releases to keep them in sycn with OSG
release. Now that is not possible.
Note, Don didn't make any effort for past three Producer releases, it
was the community and myself putting in all the effort. Perhaps Don
will be turn over a new leaf and start support Producer better, but
previous form over the last year has not been good.
> I do think that a CoProducer might have the slightly negative effect of
> introducing more confusion. I think confusion regarding viewers is a
> significant problem in OSG, and is largely because of the vast number of
> options that users have. Creating more options doesn't reduce the confusion,
> it adds to it.
I understand that. CoProducer shouldn't need to exist at all,
Producer as a separate library should never have existed. Confusion
is already there and CoProducer will only compound it. However,
CoProducer is the only sure way for us to be able to get a OSG-1.3
tripleset out the door. So we are between a rock and hard place.
The triple set requires a huge amount of coordination and cooperation.
Ask yourself is coordination and cooperation now easier or more
difficult? To pretend its easier, or just the same level of
difficulty is a "tad" bit optimistic. Take a task which is already
very difficult and make it more difficult and easily end up with a
deal breaker.
For the health of the project we need to make things easier for us to
manage, make it easier to get releases out more often and with less
effort to all those concerned.
For long term management of the core OSG it is better to just separate
osgProducer into a separate distribution. This would leave just the
OSG_OT to worry about.
However, where this leaves osgProducer as the problem. I can't
personally manage lots of separate projects, my working life is
complicated enough as it is. Having osgProducer seperate from "a"
Producer is real problem, otherwise you'll easily end with 5 or 6
pakage nightmare. For the long term health and ease of use of
osgProducer it best belongs inside Producer or CoProducer.
Short term though I don't have time to separate out osgProducer from
the core OSG. Now we have the tag the pressure is off from the risks
involved in having a somewhat wayward external dependency. I also
think putting up a CoProducer on the new server will further take the
pressure off. This gives us options that we didn't have otherwise.
We don't have to exercise those options unless we have to.
The fact we have these options is a good thing, its a fundamental
feature of open source/free software, the right to branch the code.
This right also puts onus on Don to keep things compatible. In this
respect making the tag was a clear signal that we have this right and
are willing to exercise it.
Now is there any chance of Don taking on osgProducer as part of
Producer? If only to maintain it for backward compatibility, this
would remove the need to go the CoProducer route.
If not then CoProducer is the route we have to take if we want to
ensure the health of osgProducer.
Robert.
Robert.
Eric Sokolowsky
>
>> Having slept on it I feel that it would be worth branching
>> Producer, and maintain the branch ourselves, primarily for
>> the purpose of maintaining compatibility and ease the build
>> complexities that have evolved over the past few years, and
>> particularly over the past week.
>
> I don't think there will be any compatibility issues. Don has stated
> that he has paying customers who depend on Producer and OSG working
> together. In that case, Don is not likely to do anything that will
> break this compatibility. The build problems we've experienced over
> the past few days were easily solved using the tried-and-true "two
> email" system:
>
> Email #1: "Don, I just checked out current Producer CVS and it
> doesn't build."
>
> Email #2: "Thanks, I just checked in a fix for that."
>
> :-)
What he said. :) Don is not out to get OpenSceneGraph or alienate its
users or developers. Reading his posts on the Producer-users mailing
list makes this clear.
>
> I don't see any Producer-induced build complexities, either; in my
> recent email, current CVS now builds in this order: OT, P, OSG, just
> as it always has. (However, that doesn't change my opinion that the
> OSG distribution would be better off if Producer were removed as a
> dependency by putting osgProducer and osgProducer-based examples in a
> separate distribution, replacing the examples as you've already
> started to do with non-osgProducer examples).
I have been following this discussion with great interest. I intend
to continue to create and provide OSG packages for Fedora, so how the
different projects relate to each other is of great importance to me.
The more I think about it, the more I like the idea of not having
OpenSceneGraph depend on Producer, but rather have osgProducer and
Producer sit on top of (and depend on) OpenSceneGraph. osgProducer
is the only piece of the main osg distribution that depends on Producer.
As I write these comments, I am keeping three classes of users in mind:
1. Complete beginners to OSG that are trying to evaluate it and
determine if it's suitable for their needs. These people typically would
not want to worry about development environments but would want to
easily run lots of example programs, including examples of integrating
OSG with various widget libraries.
2. Developers. These people generally do not need to run the example
programs often, but need to have include files installed properly.
There are two sub-classes of developers, those who (a) want to use
Producer in their applications and (b) those who do not. I am not here
considering "bleeding-edge developers" who use the CVS version of OSG,
because they are not using packages to get OSG.
3. Users. These people are not necessarily interested in or even aware
of the internal organization of OSG/OT/P, nor do they even care much
about running example programs. I am talking here about users of
applications that use OSG, which are distributed by Developers.
The current build system produces a number of packages, and their
intended users from the list above:
OpenSceneGraph 1,2,3
OpenSceneGraph-devel 2
OpenSceneGraph-examples 1
OpenThreads 1,2,3
OpenThreads-devel 2
Producer 1,2a,3
Producer-devel 2a
OpenSceneGraph-src 2
However, recent developments have potentially increased the complexity
of the build system. I haven't updated from CVS for a while (I'm
waiting for the dust to settle a bit) but there are new simple viewer
examples that depend on various packages like fltk, qt, etc. I do not
want to make the main OpenSceneGraph package depend on any particular
widget library, because then it would have to be dependent on all of
them. So there are a couple of options:
1. I make binary packages for the examples that need an external widget
library, such as OpenSceneGraph-fltk, OpenSceneGraph-qt, etc.
2. I do not make binary packages of programs that use external widgets,
with the understanding that anyone who needs those programs would have
to set up the corresponding development environment anyway.
If we go with either of these options, then it is natural to treat
osgProducer/Producer as just another external dependency that is not
needed for the main OpenSceneGraph package. The OpenSceneGraph-examples
package would depend on a new OpenSceneGraph-Producer package (which
contains the current osgProducer library and not much else), and
OpenSceneGraph-Producer depends on Producer and OpenSceneGraph.
I believe that this dependency change can be made without changing the
existing structure of any of the projects. Producer is still required
to build the examples, but if we provide pre-compiled binaries for
several different platforms (which we already seem to do) new users
won't have to really deal with the dependency chain much. Developers
experienced with OSG probably need to run the examples very rarely.
At any rate, those who use OSG without Producer would also be happy with
inverting the dependency relationship. Producer would only be needed to
run the examples.
Now, this relationship has implications for other platforms. Do we
want/need to have a separate examples binaries package for each
platform? How should the distribution be organized on other platforms?
>
> I do think that a CoProducer might have the slightly negative effect
> of introducing more confusion. I think confusion regarding viewers is
> a significant problem in OSG, and is largely because of the vast
> number of options that users have. Creating more options doesn't
> reduce the confusion, it adds to it.
I agree with this too. Thank you, Paul, for helping clear up the
confusion on recent build problems with Producer.
Robert Osfield
On 11/17/06, Eric Sokolowsky <eric.so...@gsfc.nasa.gov> wrote:
> What he said. :) Don is not out to get OpenSceneGraph or alienate its
> users or developers. Reading his posts on the Producer-users mailing
> list makes this clear.
Its me he's against. But since I'm the project lead, what causes me
problems causes the rest of project problems. OpenSceneGraph users
and developers are just collateral damage. This isn't just an
immediate problem but an ongoing problem, its been very serious
problem for the past two years, and just got much worse.
Public statements are one thing, actions and conduct over a long
period are what really matters. After the last two years I am
certainly am not game for more punishment, and have no interest in
attempting to collaborate.
> I have been following this discussion with great interest. I intend
> to continue to create and provide OSG packages for Fedora, so how the
> different projects relate to each other is of great importance to me.
> The more I think about it, the more I like the idea of not having
> OpenSceneGraph depend on Producer, but rather have osgProducer and
> Producer sit on top of (and depend on) OpenSceneGraph. osgProducer
> is the only piece of the main osg distribution that depends on Producer.
osgProducer and Producer based examples are the touch points.
> OpenSceneGraph 1,2,3
> OpenSceneGraph-devel 2
> OpenSceneGraph-examples 1
> OpenThreads 1,2,3
> OpenThreads-devel 2
> Producer 1,2a,3
> Producer-devel 2a
> OpenSceneGraph-src 2
>
> However, recent developments have potentially increased the complexity
> of the build system.
What are you thinking of in terms of structure for Producer now its
has ProducerOSG in? I presume you'd have to break it into two
packages, or just make OSG a dependency of the whole Producer.
> 1. I make binary packages for the examples that need an external widget
> library, such as OpenSceneGraph-fltk, OpenSceneGraph-qt, etc.
>
> 2. I do not make binary packages of programs that use external widgets,
> with the understanding that anyone who needs those programs would have
> to set up the corresponding development environment anyway.
I'd be inclined to keep the widget examples out of the package.
Examples are really just code examples, they aren't meant to be run
outwith the context of the code.
The exception to this is the idea of having plugins that implement
osgViewer::GraphicsWindow for the main native window libraries, so
Win32 under Windows, X11 under unices, and Coca/AGL/CGL under OSX.
> If we go with either of these options, then it is natural to treat
> osgProducer/Producer as just another external dependency that is not
> needed for the main OpenSceneGraph package. The OpenSceneGraph-examples
> package would depend on a new OpenSceneGraph-Producer package (which
> contains the current osgProducer library and not much else), and
> OpenSceneGraph-Producer depends on Producer and OpenSceneGraph.
osgProducer and ProducerOSG sit side by side in terms of dependency.
In fact ProducerOSG is nothing more than a OsgSceneHandler right now
so could just drop into osgProducer. Actually Don probably just use
the existing osgProducer::OsgSceneHandler in his new wave of OSG
examples just fine... If Don was interested in maintaining backward
compatibilty this is the route he could have taken.
> I believe that this dependency change can be made without changing the
> existing structure of any of the projects. Producer is still required
> to build the examples, but if we provide pre-compiled binaries for
> several different platforms (which we already seem to do) new users
> won't have to really deal with the dependency chain much.
What about ProducerOSG, where does that fit in?
> Developers
> experienced with OSG probably need to run the examples very rarely.
> At any rate, those who use OSG without Producer would also be happy with
> inverting the dependency relationship. Producer would only be needed to
> run the examples.
My current inclination is to bite the bullet and sort out the circular
dependencies for the 1.3 release, and move osgProducer + examples out
into Producer or CoProducer. This would keep the package count down
and resolve the logical confusion over which library depends on which.
> Now, this relationship has implications for other platforms. Do we
> want/need to have a separate examples binaries package for each
> platform? How should the distribution be organized on other platforms?
Do we actually need example binaries at all?
There are the standard OSG applications as well, these are possibly
more useful as part of binary package.
Another thing to throw in the mix is migration to using Lua/Python for
examples. This would avoid the compile/binary issue completely.
Robert.
Ellery Chan
Robert wrote:
> Do we actually need example binaries at all?
I think binary distributions are valuable. It means someone looking for
tools can get an initial impression of what is possible in a few minutes and
with very little effort instead of potentially hours, and someone building
simple but useful OSG apps might be very happy to have just includes and
DLLs (once the source code != documentation). Whether the core team builds
and maintains all the different binary versions or relies on the
community-at-large is a decision point.
-ellery-
Robert Osfield
On 11/17/06, Ellery Chan <ell...@precisionlightworks.com> wrote:
> Robert wrote:
> > Do we actually need example binaries at all?
>
> I think binary distributions are valuable.
Perhaps you misunderstand me. I'm not implying that binary
distributions are required, but questioning whether we need the
examples to be released as binary packages.
> It means someone looking for
> tools can get an initial impression of what is possible in a few minutes and
> with very little effort instead of potentially hours, and someone building
> simple but useful OSG apps might be very happy to have just includes and
> DLLs (once the source code != documentation).
I think that the dev package version + main applications would
suffice. Especially now that we have lua integration on the near
horizon. One could write lots of lua examples that do lots of cool
things and distribute them easily once you have the base libs in
place. Actually you don't even need the headers once you
introspection and a scripting language tied to it ;-)
> Whether the core team builds
> and maintains all the different binary versions or relies on the
> community-at-large is a decision point.
What the package maintainer do is largely up to them, its their time
they are investing. We could possible provide a template for what are
the minimum things to release as packages, then leave any extras to
the maintainers to decide upon.
At the Highland Gathering Mike Wieblen put his perspective on package
mantainers this way - he considers himself like a Red Hat, putting
together various different tools to create an overall package, while
he considers me a Linus Tovalds maintaining the definitive source code
base.
Another perspective came from Colin Dunlop's experiences with how
trolltech do things with Qt - they provide basic binaries for the main
platforms and don't even try to cover all the smaller segments - users
have the source code so they can build it themselves if they need it.
The main platforms would be things like win 32 bit, but not both with
win 64bit etc.
For new users we have to make it easy for them to get up and running
quickly, and once they are bought in actually developing apps then
they will be more open to jumping through the hoops required to get
things to compile.
There is lots of stuff to talk about in terms of packaging, however,
I'd rather not get too involved too much on this right now. There are
too many pressing issues to move on with. I am pretty close to
overload, and need to trim discussions down to stuff that effects the
discussions we make and actions we take in the near term.
Once we get a new server up and start getting back on the horse of
working toward 1.3 then taking about packaging issues, etc is
certainly something to discuss in depth. Something that could then
move onto osg-users too.
The immediate heat on osgProducer has now been taken off a bit, one by
the tag I made, and second by Don resolving some of the build issues
that he'd introduced. Problems still exist but they aren't project
breaking at present.
Once we get nearer to 1.3 we need to resolve what we do though - I
think we need to clean the circular dependencies up for 1.3, and move
osgProducer out, but to do this I think
we'd need to either:
CoProducer including osgProducer, I and/or others take the project on.
Producer including osgProducer, Don takes the project on.
I don't believe a separate osgProducer project is practical to maintain.
Would it be worth approach Don to see if he'd want to take on and
maintain osgProducer?
Robert.
Eric Sokolowsky
> What are you thinking of in terms of structure for Producer now its
> has ProducerOSG in? I presume you'd have to break it into two
> packages, or just make OSG a dependency of the whole Producer.
Well, if OSG does not depend on Producer, but rather only some glue code
depends on both, then osgProducer and ProducerOSG would become the same
thing. I admit that my understanding of ProducerOSG is very limited
because I have not looked at it or even tried to compile Producer
recently.
>> 1. I make binary packages for the examples that need an external widget
>> library, such as OpenSceneGraph-fltk, OpenSceneGraph-qt, etc.
>>
>> 2. I do not make binary packages of programs that use external widgets,
>> with the understanding that anyone who needs those programs would have
>> to set up the corresponding development environment anyway.
>
> I'd be inclined to keep the widget examples out of the package.
> Examples are really just code examples, they aren't meant to be run
> outwith the context of the code.
I presume that you meant keeping the widget examples out of the binary
package. The source code would still exist in the source package. From
your statement, I understand that we wouldn't really need to distribute
binaries of example programs at all, but just distribute the source code
to the examples with the source code of the rest of OSG. I have no
problem with that.
> The exception to this is the idea of having plugins that implement
> osgViewer::GraphicsWindow for the main native window libraries, so
> Win32 under Windows, X11 under unices, and Coca/AGL/CGL under OSX.
This sounds reasonable.
>
>> If we go with either of these options, then it is natural to treat
>> osgProducer/Producer as just another external dependency that is not
>> needed for the main OpenSceneGraph package. The OpenSceneGraph-examples
>> package would depend on a new OpenSceneGraph-Producer package (which
>> contains the current osgProducer library and not much else), and
>> OpenSceneGraph-Producer depends on Producer and OpenSceneGraph.
Another thought: perhaps the OpenSceneGraph-examples package should
merely contain the applications such as osgconv and osgviewer and be
called OpenSceneGraph-apps, if we don't want to distribute the example
binaries.
> osgProducer and ProducerOSG sit side by side in terms of dependency.
> In fact ProducerOSG is nothing more than a OsgSceneHandler right now
> so could just drop into osgProducer.
Yes, this is what I was thinking. Glue between Producer and OSG should
sit on top of both so that neither depends on the other. Generic viewer
functionality should be located elsewhere; perhaps this is what
osgViewer will fill. I admit that I am not familiar with the recent
development efforts in this area.
>> Developers
>> experienced with OSG probably need to run the examples very rarely.
>> At any rate, those who use OSG without Producer would also be happy with
>> inverting the dependency relationship. Producer would only be needed to
>> run the examples.
>
> My current inclination is to bite the bullet and sort out the circular
> dependencies for the 1.3 release, and move osgProducer + examples out
> into Producer or CoProducer. This would keep the package count down
> and resolve the logical confusion over which library depends on which.
Another solution is to develop a very simple generic viewer that doesn't
depend on osgProducer or Producer. Perhaps this is already done with
osgSimpleViewer. If this course is pursued, it should be easy to use
Producer instead of the simple viewer if the developer wishes, for both
the examples and for custom applications. I use Producer in my
application but I know that there are many developers who do not.
> Do we actually need example binaries at all?
I do not care either way. It's easy to turn them on or turn them off
when I build Fedora packages. This is a good question for the regular
osg-users list.
> There are the standard OSG applications as well, these are possibly
> more useful as part of binary package.
Yes, I agree. Distribution of OSG would be much simpler without a binary
package but it is clear that having one is useful. Including the example
programs within the binary package is still negotiable, but not very
important.
> Another thing to throw in the mix is migration to using Lua/Python for
> examples. This would avoid the compile/binary issue completely.
I think that there will always be a need for examples in C++ regardless
of other bindings that may be in use or developed in the future. I
personally have no intention of using any of these scripting languages
for my application development. But certainly they make distribution of
binary examples irrelevant, since there are no binaries for these
scripting languages. The user will just have to install the scripting
languages themselves.
Robert Osfield
I don't have much specific things to add, other than osgViewer is
designed to provide viewer functionality without outside package
dependencies, its pure C++ and OSG.
There is a little twist in the that include directory may have
specific widget support, but the lib itself won't compile it these
headers, so the lib won't be dependent upon them.
Robert.
On 11/17/06, Eric Sokolowsky <eric.so...@gsfc.nasa.gov> wrote:
>
Ellery Chan
Robert wrote:
> On 11/17/06, Ellery Chan <ell...@precisionlightworks.com> wrote:
> > Robert wrote:
> > > Do we actually need example binaries at all?
> >
> > I think binary distributions are valuable.
>
> Perhaps you misunderstand me. I'm not implying that binary
> distributions are required, but questioning whether we need the
> examples to be released as binary packages.
Just putting in a vote on the value of the examples and their availability.
I think they do a nice job of illustrating many of the OSG features.
I think it's appropriate to rely on the grace of others to make the binaries
available. All combinations of OSG + package X + platform Y is probably a
large number.
Sounds like you have all thought this through already and I am just catching
on. I'll try to keep up. :-)
-ellery-
Paul Martz
> DWMake, if you don't have this the build is broken. I expect
> the Xcode projects will be totally of of sync, so again the
> build will be broken.
Hi Robert -- I just spoke with Don on the phone about these issues. He says
he is committed to not interrupting the 1.3 OSG release, and not
interrupting the production of the Quick Start Guide. To that end, he
pledges to resolve all these issues (remove the DWMake dependency, and fix
any Xcode project file issues). As usual, he'll need input from the
community for testing, etc., to ensure that everything is fixed. (After all,
that's the value of open source.)
So, I encourage you to give him some time to resolve these issues before
deciding that CoProducer is the only solution. I think creating CoProducer
would be disruptive and confusing to users, while allowing Don to restore
Producer's build to a "status quo" state would be much less disruptive.
-Paul
Robert Osfield
On 11/17/06, Paul Martz <pma...@skew-matrix.com> wrote:
> Hi Robert -- I just spoke with Don on the phone about these issues. He says
> he is committed to not interrupting the 1.3 OSG release, and not
> interrupting the production of the Quick Start Guide. To that end, he
> pledges to resolve all these issues (remove the DWMake dependency, and fix
> any Xcode project file issues). As usual, he'll need input from the
> community for testing, etc., to ensure that everything is fixed. (After all,
> that's the value of open source.)
>
> So, I encourage you to give him some time to resolve these issues before
> deciding that CoProducer is the only solution. I think creating CoProducer
> would be disruptive and confusing to users, while allowing Don to restore
> Producer's build to a "status quo" state would be much less disruptive.
Thanks for the update. Looks like Don's softened his stance, which
certainly helps us. I kinda feel frustrated for though, I know where
he's coming from when he want to do things the way he feels is the
right way - keeping compatibility and keeping users with you does
restrain the glee at which you can undertake it.
For the next 1.3 releaset to work well without going the CoProducer
route we'll need a stable Producer well before we go for release. Or
for us to move osgProducer out of the core, and then let Don dictate
the timing of Producer/osgProducer release/releases.
Another alternative is to just release 1.3 with against the Producer
1.1 (the release I made coupled with 1.2).
If Don doesn't want to pick up on maintaining osgProducer after its
moved out of the core, and the community wants it to track Producer
rather than make a CoProducer then we'll need to search for a new lead
for it.
My current inclination is to move osgProducer out for 1.3, while this
does make for more work for me short term, it would make the actual
release easier due to having less project variables in the mix.
I'll leave things over the weekend then early next week put the
options to the community for discussion. This might stir someone to
pick up and run with osgProducer, or perhaps Don will step forward.
Robert.
Jan Ciger
Hash: SHA1
Hello,
Robert Osfield wrote:
> I do have concerns about people percieving osg-crew as some kind of
> opaque committee that decides things without any regard for others.
> However, osg-crew is fully public, anyone can review the archives, and
> anyone can join and contribute.
Then the argument could go also why to have two lists to discuss these
issues?
I wanted to point this issue to you because I think that Don had a point
there. I trust you to make a good decision on it.
> Discussing this on osg-users is inappropriate, its a friendly support
> and dev list, we need to keep it that way.
I both agree and disagree here. It is a tough call to make but the
perception of a cabal would make the situation even worse. At least some
results should be made "public" on the other list. However, I agree with
Paul Martz that we should let the dust settle a bit.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFXl/xn11XseNj94gRAvLTAJ44ezxOuoebDcfrkXru6xKxJcsKjACfWSQP
kgikZlbskU1+l5xb3UOARmo=
=kWkW
-----END PGP SIGNATURE-----
Robert Osfield
On 11/18/06, Jan Ciger <jan....@gmail.com> wrote:
> > I do have concerns about people percieving osg-crew as some kind of
> > opaque committee that decides things without any regard for others.
> > However, osg-crew is fully public, anyone can review the archives, and
> > anyone can join and contribute.
>
> Then the argument could go also why to have two lists to discuss these
> issues?
Well osg-crew has a distinct role, its for those helping maintain the
wider OpenSceneGraph project, its the crew of ship that help keeps it
running smoothly. Over time I expect it to become clear.
> I wanted to point this issue to you because I think that Don had a point
> there. I trust you to make a good decision on it.
The fact is osg-crew replaces the opaque clique that Don and I had in
running the project. Now we have a transparent and open group of
people doing a similar task.
Now Don doesn't have a role any longer, of his own choice I might add,
so I expect he'll feel a bit more sensitive to the lack of control,
and may well percieve osg-crew as an exclusive club. The fact is its
only exclusive of Don, and because he wanted it that way. osg-crew
isn't exclusive, anyone can join.
> > Discussing this on osg-users is inappropriate, its a friendly support
> > and dev list, we need to keep it that way.
>
> I both agree and disagree here. It is a tough call to make but the
> perception of a cabal would make the situation even worse. At least some
> results should be made "public" on the other list. However, I agree with
> Paul Martz that we should let the dust settle a bit.
The crucial thing is what get through the transition and get a stable
base, have lots of discussions that reflect the instability right now
isn't healthy for the project, it also promotes a lot of people
chipping their two cents in that have no experience or obligation in
following things through. Its much easier to make suggestions that
sound great, much harder to follow them through, we have to settle of
routes that we can follow through.
Once have a stable place, and that osg-crew hasn't become some kind of
clique that ignores the needs of the community but serves them, then I
expect any perception of a clique to diminish. Its our responsibility
that we don't become a clique, I have no interest in forming a clique,
it'd be damaging to the project - just as Don and my clique ended up
counter productive.
I think as a group we need to be mindful of what we thrash out here
and what is discussed on the osg-users mailing list. However, as long
as we do things respectfully and transparently I expect the community
to grow to understand the evolving role osg-crew, and that its a good
thing that its here and providing backup and support of the project.
Robert.