<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/20/2012 10:53 AM, David Seikel wrote:
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<pre wrap="">I'm not a member of the team, but I do hope ZATZAi got my messages that
I want to be a team member.
On Fri, 20 Jan 2012 00:56:31 -0800 ZATZAi <a class="moz-txt-link-rfc2396E" href="mailto:zatzai@zatzai.com"><zatzai@zatzai.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">1. Irregardless of anything else do we as a team want to continue
work and are there enough of us with enough time available to work on
a viewer?
1a. If the answer is no, do we want to work on something
else, such as a TPV code respository like Boroondas suggested?
1b. Assuming the the is yes, do we want to start fresh or
continue on the old code base?
</pre>
</blockquote>
<pre wrap="">
I would say yes, keep working on viewers.</pre>
</blockquote>
I think the question here should not so much be whether to continue
working on viewers or not, but whether we want to produce a full TPV
with binary downloads for Mac, Linux and Windows (note that we are
lacking a Mac dev) or a modified version of LL's codebase, with —
say — Linux-64bit-compatible code (without breaking the other
platforms) and OpenSim compatibility (while keeping compatibility to
SL grids), so that other TPVs can use that as their upstream instead
of directly basing upon LL code. This would make these features
available in all TPVs that do this.<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<pre wrap="">Personally I see little value in chasing LL's tail lights, but that's
just me. All the people that keep saying you can't add V3 features to
V1 viewers are just plain wrong, as it's being done already. I even
had a working proof of concept mesh implementation in 2010.
The Imprudence team already has a great code base that has been in use
for some time, and people love it. The next release is almost ready.
Starting fresh means much time spent playing catchup, and not so much
time innovating.
Starting fresh means pissing off a loyal user base that have been
hanging out for way too long for the next release.</pre>
</blockquote>
1b is really about Kokua, not Imprudence, I think. So the code we
have there hasn't really been in use (we haven't officially released
anything Kokua, yet, just made some test builds available). Also,
the Second Life Viewer version we were basing this code on had a
much worse user interface than today's Second Life Viewer. So
re-basing on today's LL code will make it both easer to keep up and
easier to get a rewarding result from when improving it further.<br>
<br>
We should probably rephrase the questions, but now the wiki's down.
Meh.<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">2. Firestorm, how closely do we want to work with them, or even for
them etc?
</pre>
</blockquote>
<pre wrap="">
Ewww, no not work for them. You should work with all TPV developers,
just as all of us have.</pre>
</blockquote>
"for" is probably the wrong word here. In the scenario considered
here, we'd either join them to become equal members in their team,
or we'd stay a team of our own that'd dedicate itself to improving a
particular part of their viewer as contributors. We'd certainly not
want to become a sub-unit they can command around, nor do I think
they'd want us to become that.<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">3. Git or Hg, let's pick one and stick with it, so which shall it be
(Git is familiar to many, but Hg is used by LL and it's easier to
import LL patches to Hg)?
</pre>
</blockquote>
<pre wrap="">
What about patches from non LL sources?
The github network tool has been invaluable for me to track what
Imprudence has been doing, and what the other forks of Imprudence have
been doing. On the other hand, if Imprudence is dropped, then I'll
just keep working on my fork, so that wont matter so much to me. I have
zero interest in chasing LL's tail lights.</pre>
</blockquote>
For imprudence it certainly makes sense to stick with git. For Kokua
though, the biggest amount of code we won't write ourself but want
to integrate can reasonably be expected to come from Firestorm, LL's
viewer or contributions to them, thus be available in hg
repositories. Theoretically, there are tools to convert forth and
back between hg and git. Practially, though, we had to discover
these tools are slow, don't provide lossless roundtrips they claim
to provide (converting forth and back again changes commit/changeset
IDs) and have limitations (e.g. can't handle commits without
well-formed committer email address).<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">4. Any new client will use the Kokua name, should the project name
change to Kokua as well or stay Imprudence?
</pre>
</blockquote>
<pre wrap="">
Imprudence has the brand recognition.</pre>
</blockquote>
Actually, I had the impression we already had changed names. After
all, all *.imprudenceviewer.org/*-pages except for the ImpDev
mailing-list specific ones redirect to the corresponding
*.kokuaviewer.org/*-pages. Though, I must say I'm not really sure
whether Kokua and Imprudence are one project producing two viewers
or two projects of the same team, each producing one viewer.<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">6. What focus should the project take, features or stability? Second
Life first and foremost or OpenSim/Aurora?
</pre>
</blockquote>
<pre wrap="">
Stability first, features second. Phoenix / Firestorm is already doing
SL first and to hell with OS. OS needs a popular viewer that caters
for them.</pre>
</blockquote>
I think here, too, we need to distinguish between Imprudence and
Kokua. For Kokua, becoming usable for OpenSim is only possible <b>with</b>
new (or forward-ported from 1.x-Viewers) features. (E.g. Non-web
profiles, or web profiles with gird-specific urls rather than LL's
hardcoded ones.)<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">9. User statistics, are there any we can get from LL? If not can we
create an opt-in within the client for sending hardware stats such as
CPU, RAM, OS etc? Would this help us in better developing the client
for our audience?
</pre>
</blockquote>
<pre wrap="">
Opt in is good. Also include if 64 bit users are using the 32 bit
version.</pre>
</blockquote>
Good idea. :-)<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">
One question I want to add - if you go ahead with Imprudence, is
the
feature freeze over already?</blockquote>
Well, our unscheduled phase of general inactivity probably kinda
turned the release schedule up-side-down, so I don't know whether
Imprudence is currently feature-frozen or not.<br>
<br>
<blockquote cite="mid:20120120195302.1bba2937.onefang@gmail.com"
type="cite">I ask coz we missed out on getting OTR
into Impy due to missing the deadline for the feature freeze. OTR
was
not ready at the time. But I have noticed that new features made
it
into Impy later anyway. So, is it over, can I send an OTR patch?</blockquote>
Well, it probably fell through the cracks somehow. However, let's
discuss on how to continue with that contribution after we've
decided how to proceed (or not) with Imprudence in general.<br>
<br>
Cheers,<br>
Boroondas<br>
</body>
</html>