Hi all,
sorry for coming late... just some thoughts, I don't claim to have all
the answers...
Chris 'Xenon' Hanson wrote:
Paul Martz wrote:
I am booked 100% with client work, and if my clients are content on the
current release, and there are no pending new features that the clients
need, then I have no funding or availability to support a new stable
release.
And that's totally reasonable.
I also don't have time to admin releases, but would gladly test a
trunk+patches tree and provide feedback if one existed and I could
easily get hold of it.
Ultimately, Chris, if you have a need for a stable release, or even a
need to get your changes into a branch that will eventually lead to a
stable release, then you have just volunteered. :-)
Actually, while I _am_ volunteering, it's not because I need a new release.
Anybody I'm
working with right now can build from source with patches I send. But, I
dislike seeing
the trunk get stale and fragmented, so I want to ensure that we hold together a
community
release protocol.
We are also running trunk with manual patches and I don't like it. If
many people do this, it also means we are duplicating a lot of work and
testing.
If I'm not mistaken, we can branch the trunk either right now, or just
prior to the start of Robert's GL ES2 work, and Chris could add his
changes to the branch, and that branch could eventually lead to a 2.10
stable release. Robert's trunk work could eventually lead to a 2.12
release. The downside of this is there might be a potentially nasty
merge in there somewhere.
Robert, Chris: Thoughts?
While I'm very opposed to the "nasty merge" part, I don't have any need to
force any
sort of branches or releases myself. I'm simply trying to look out for the
continued
maintenance of the entire trunk.
I see two approaches with releases:
1) branch trunk, add patches to branch, make release from branch
2) branch trunk, add patches to branch, merge changes to trunk, make
release from trunk.
I like 2 more, which means the trunk gets up to date when Robert has
time to merge patches from the branch (this is almost like the staging
or -mm trees in the linux kernel) and Robert knows what has been merged.
The only change from the current way of working is that users have some
way to test patches without applying it themselves. So instead of saying
"try the trunk version ..." one can say "try the staging version and
report if it fixes your problem". If feedback is received on patches
working, and this info is visible in some way [*], Robert could more
easily merge these back to trunk (we will need some way to "cherry pick"
patches).
[*] This relates to issue tracking in some way. Currently the only way
to know if a patch has been applied is to read osg-submissions or browse
code. I think Robert tracks patches (Robert, correct me if I'm wrong) by
just using his inbox, but this does not scale to more than one person
applying fixes.
regards
jp
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
