[impdev] ImpDev meeting moved to the mailing list.

[David Seikel]

No one turned up for the meeting, so we can discuss things here.  I
hope people turn up at tomorrows meeting.  lol


The WindLight refactor.
-----------------------

There was some comments in the source that WindLight (WL) could do with
a refactor, I agree that it needs it, so started that.  Several issues
in the issue tracker are WL issues, this refactor should make it a lot
easier to solve them.  Plus, I had already started this work on my
meta-impy fork.

I've created a branch for the WL refactor on the github repo.  Done
about half of the refactor, but I think the other half can wait until
later. Those parts that deal with the sharing of WL are the main focus
of this half of the refactor.  The other half of the refactor is to
combine water and sky, lots of duplication there.

Should now be easier to start working on the WL issues.  That's my
planned next step.

There is still no support for LL estate shared WL, Phoenix parcel
WL, or whatever parcel WL LL is coming up with.  Also, I think RLV
WL controls should be part of the refactor to, they are still separate
at the moment.  This refactor should make implementing those things
easier, as the infrastructure is all in place, just need to decode the
new stuff as needed.

I think the Aurora WL UI stuff is similar to the LL UI for doing the
same thing.  Would be useful in the future to generalise that, then
just have one "send to server" bit of code that figures out which sort
of "send to server" method works on the current grid.  It might even be
possible to have a "create LightShare script" similar to how WL
notecards are created now.  Even going as far as creating a prim to put
it into.  So long as we don't make the same mistake Emerald / Phoenix
made with their LSL bridge that does not work on OpenSim, and just
clutters up sims with almost impossible to deal with prims.  (I'm
expert at dealing with them now.  lol)

Kokua might be able to use the results of this refactor for those
varieties of WL sharing that are not already in the LL code base.
Then it can support OpenSim LightShare, Aurora WL, Pheonix parcel WL,
and RLV WL scripting.


Proper copyright for the Aurora WL sharing stuff.
-------------------------------------------------

I mentioned this in a previous email.  I'll leave that discussion to
that, though no one has piped up about it yet anyway.

Part of the refactor included the Aurora code in question.  The part
rewritten ended up mostly a combination of what Jacek had written
before the Aurora code had been committed, and my own additions.  I
feel reasonably confident that the bit of Aurora code in question was a
cut and paste of Jaceks original code, so my refactor has left that
part of the code in the lightshare.cpp file, under the original Jacek
copyright, and with the addition of my own copyright.  Anyone who has
any information to go against my conclusion should speak up, so we can
get that sorted out.  I don't think any part of things Revolution
Smythe added ended up in the rewrite, but he does not claim copyright
on the version he committed, which is what the other email was about.

Please discuss that in reply to that other email.


Bump some beta 3 issues to beta 4, and aim to get beta 3 out quickly.
---------------------------------------------------------------------

Beta 3 was really just so that we can sort out the new Impy team, and
get up to speed on dev stuff.  Right now the Impy team is mostly me,
with help from McCabe and Armin every now and then.  I think I have
settled in nicely now, so the need for beta 3 has sort of passed.

I propose to get beta 3 out soon, by bumping a bunch of issues tagged
for beta 3 to a new beta 4.  Beta 4 will get lots of issue fixing love,
until we think it's ready enough for pushing out, with RC1 following
shortly after if no major problems crop up.

Beta 3 will be left with the WL refactor, a bunch of issues related to
that, and some minor things I think I can do quickly.  Then we can
release it soon, so that those people that have been patiently waiting
have something to use, and those that offered to test (the bulk of the
support that has been offered so far) have something to test.

The stuff I want to bump to beta 4 is the Mac issues (I had already
committed the Mac building patches, should in theory mac a Mac
version easier to compile), sound stuff, new features, and other
miscellaneous patches.  The list is at
http://wiki.kokuaviewer.org/wiki/ImpDev_monthly_in_world_meetup_agenda


Commit my long jump fix, though it's not complete.
--------------------------------------------------

That's one of the issues I had tagged before for beta 3.  I know that
the original patch I had based mine on had been looked at and rejected
as not being a complete fix.  Mine takes the original Hippo workaround
from years ago, and takes it deeper into the code, getting a lot closer
to the real problem, and not applying the workaround to unrelated bits
of code.  I feel that taking that process further might actually get us
to the real bug.

An actual user of Hippo with that original workaround has demonstrated
that they get a similar effect, but more prims are not rendered.  So
my version is an improvement.

Yes, it's not a complete fix, but it's a good workaround.  It's the
difference between "Everything is blue, you need to relog now, nothing
else fixes this." and "Some prims are missing from your view, but most
of the sim is visible and you can probably make do, relog if needed.".
I think it should go in, as it's far better than nothing.  Myself and
other users of my meta-impy fork (a large percentage of the users of my
hobby grid) have been using that patch for a long time.

It should go into beta 3 in my opinion.  It could even go into Kokua
now, assuming the bug still exists there.


Releasing experimentals and such.
---------------------------------

ZATZAi has suggested that we start doing experimental releases again.
I have what I think is a better idea, post commit releases.  After a
series of commits that we think ended up with a kinda stable git HEAD,
that at least has passed the tests the developer thought of at the
time, an automated build system should be triggered to compile Linux
32/64 bit, and perhaps Windows 32 bit releases.  These should have
"experimental_YYYY-MM-DD" added to the name, and hosted either on our
usual download page, or on our github project downloads space.

If there is a whole bunch of things going in over a given short time,
like a day or three, then don't start the package release process until
they are all in and the developer/s concerned is happy.  Right now, I
doubt if there are enough of us committing to worry about stepping on
each others toes for this.  Starting the automated build is a manual
process, so the developer concerned makes the decision about when it's
ready to roll.

As an example, I would release the current git HEAD of the next branch
right now as an experimental, but not the WL refactor branch.  That's
why I made the WL refactor a branch.  It's a lengthy task, and other
things could go into the next branch until WL is done.

Windows builds might have to be done manually, as I don't know of any
completely automated method.  My Linux build scripts can be completely
automated, I've done that before.  I've not tried the github downloads
system yet, but it looks like I have enough access to use it.  Not sure
if it can be automated.  I don't know if I have access to the Impy
download thingy, that's on the wiki?  If I really have to, I can
automate sending the files to my own web server.  It has plenty of
space and bandwidth.

This sort of process gets new stuff tested quickly by those that have
offered help with testing.  I think this could be a good QA setup, and
may even replace the problematic QA that has been blogged about in the
past.  Testers don't have to deal with compiling, and good testing gets
done pretty much ASAP.  Hopefully.

Once we get that Mac Mini that was discussed before, it can be used to
do similar automated builds for Mac.

This system could work for Kokua to.


Do we REALLY need 2MB of Easter eggs?
-------------------------------------

There is 2 MB worth of Easter egg images.  Being PNG files, they don't
compress really well, as the point of PNG is to apply image specific
compression, which in theory is more efficient than the general purpose
compressions usually applied to the download packages.  Once compressed
by PNG, the general purpose compressors can't do any better.  I've not
looked at current download sizes, but from memory they are between 30
and 40 MB.  So 2 MB is a considerable percentage, just for Easter eggs.

Sure I have heard stories that Microsoft had an entire flight simulator
as an Easter egg in some version of Office or something like that.  I
don't think they are good role models for efficient use of resources.

Can we get rid of them?  Or at least use much smaller images?  ASCII
art?  Have the viewer download the images from the web if ever anyone
stumbles across them?  Not like it's a crucial feature, or that any
single person will try it more than once.  lol

Those 2MBs add up fast, so I'd go with the "download from the web when
needed" idea.  After all, they will rarely be needed, and can be cached
for those that try it a second time.  Reducing our 'net traffic.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.imprudenceviewer.org/pipermail/impdev-imprudenceviewer.org/attachments/20120415/e0e541c2/attachment.pgp>