Hi Allen,
Allen Bierbaum wrote:
> Has anyone had time to look at this yet?
>
> Please help out, 30 minutes is really all it should take. :)
>
I had looked at it before, but most of my comments were 'agree
totally!', and that didn't seem to add anything, so I never saved them. ;)
Marcus Lindblom wrote:
> Ok.
>
> In general:
>
> Many, if not all, of the solutions listed seem nice. Why not convert
> them to trac-tickets and put assign them to a milestone?
>
Good idea. Anybody want to take a stab at it?
> All small issues that need fixing (experimental code etc) needs to be
> documented. A number of wiki pages exists for this now
> (PotentialContributions, ProjectIdeas, OngoingProjects,
> FeaturesToPortFrom1to2). Shouldn't all these be centralized to one and
> filled with content, so one can see what needs to be done? :)
>
They do serve different purposes, but I think not all of them are
necessary or easy to fill.
Potential Contributions is a bit of a misnomer, IMHO. I'd call it
Bazaar, Grabbag or PuzzlePieces, as it's a wild mix of little things
that could be useful but need to be integrated.
ProjectIdeas looks good and I would leave it as is. OngoingProjects is
empty and honestly I have no clue what kind of things should go on
there, I'd remove that.
FeaturesToPortFrom1to2 seems too big to be useful, honestly. There is a lot of
little changes that need to be ported, the best way to find them is to look at
the diff in CVS from HEAD to to_gv_merge_7 and see if the change is in 2. It
sounds nasty and it is, but I don't really see another way. :(
> OpenSG.org ought to have a big link to the trac site on the first page,
> even if it is under construction.
>
I was waiting for the site to mature a little, but I think you're right,
it's good enough now. Andreas, can you please put a link on it?
> Roadmap:
>
> I think the roadmap is quite important, esp if we want to attract new
> users who do not follow the mail-list. Trac has good help here, with
> milestone and ticket support. I think it would be quite easy just to
> summarize the big changes under each milestone, potentially with links
> to wiki pages describing it in detail (see the Trac site for this,
> they're pretty good). That way, each major task would have it's own
> wiki-page, with tickets linked etc etc. Each milestone info would link
> to the task-page so that one can see when a new feature is going to be
> introduced.
>
> Immediate fix: Update Changes1To2 with a list on what you core-dev-guys
> have in your head for that. (or put in the description of 2.0
> beta/release milsetones)
>
I would put the stuff that's been agreed on in the milestone and the
rest in the Wiki.
> Also, a milestone called OpenSG 3.0 (or something) for ideas that are in
> there, but will have to wait quite a while?
>
Nice idea, done.
> Development:
>
> Other dev priorities from my point of view:
> - Getting 1.8 out the door is good.
> - Focus on 2.0 build.
> - Getting everyone in on the 2.0 release game.
>
Easier said than done. Quick poll: what would we need to do to make you
(meaning everybody who reads this) move to 2?
> Marketing & promotion:
>
> Gallery has expanded greatly. Very nice. Part of problem solved.
> Dirk's writing on OpenSG features are impressive. :)
> Get that OpenGL-link going asap. Also, investigate other places where
> SG's are listed. Make sure we are visible everywhere!
>
I'd look at OSG's list, that seems to cover it nicely.
> (Ask OSG to put a link to us, if we link to them in return, to make sure
> new users get to what they want without confusion?)
>
Judging from his last mail I don't think Don would agree to that. We'll
have it anyway in some of the feature lists and comparisons.
> Building:
>
> Generating vcprojs from the local file structure that kick of scons
> should be pretty easy, if it's in the path.
>
Allen, had you gotten around to trying the Windows build again?
> We should also provide a .bat-file for windows users that does something
> like:
>
> call vcvars32.bat
> if not exist scons.bat / python.exe echo failure!!
> set INCLUDE / LIB / PATH = ... opensg/win32/supportlibs/ ...
> devenv /useenv
>
> So it becomes dead-easy to get going.
>
I like that.
> Examples:
>
> Screenshots / movies of each example on the website? Or in doxygen at
> least. (A separate doxygen run for examples & high-level documentation
> would probably make sense, to split that from API, which is more
> difficult to keep nicely formatted.)
>
Examples infrastructure needs to be added first. We still haven't quite
decided where to put them. One central directory or in the Source? I'd
still prefer the source and collecting them for install.
> (Is it possible to record from OpenSG? I don't think so, but there may
> be experimental code for it. Ought to be fixed and perhaps even
> automatically generated? .. start examples with a '--record' arg?)
>
We have a FileGrabForeground that can save every rendered frame to a new
file. We also have some contributed code from Mathias Gumz in Contrib
(VideoGrab) that uses ffmpeg to directly grab to video but I've never
gotten around seriously testing it.
> Documentation:
>
> I agree the proposed solutions. We just need to start getting people to
> document. Someone needs to go through the docs and see what needs to be
> done, then list this roughly on some 'documentation page', in some
> priority order perhaps. After that, people will hopefully volounteer to
> take charge over some part, documenting some and accepting
> patches/delegating work to others.
>
I'm still struggling a little bit with doxygen, but it sounds like a
good plan.
> Loaders:
>
> Need to list which loaders ppl want somewhere, prioritize, ticketize and
> assign to milestones.
>
Yes.
> Conclusion:
>
> So, I think we are pretty good in agreement in general, but it may be
> time to go down one step to details. We need to get some material in
> there. Should we split the FutureOfOpenSG into pages for each issue,
> detailing who is responsible, setting up tickets and linking to them
> from there, etc etc?
>
> Also, we ought to start putting stuff into the
> Ideas/Contributions/WhatToPort/Changes sites, so some we get some 'meat'
> on the skeleton. That way, we can see where we are going.
>
> I'm quite excited about this. :) I think that if we get a structure down
> on what should be done, others can pick up whatever threads they like.
> We just need to lay out those threads and try to reach critical mass.
>
Contributions welcome. I don't see myself working on this a lot this
weekend (too much other stuff to worry about :(), so if anybody wants to
take a stab at it I'd appreciate it.
Dirk
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
