[kokua-dev] [impdev] Time and place for All-Hands meeting about the future of the Imprudence / Kokua Team, Project and Viewers

Borun (a.k.a. Boroondas Gupte) borun at kokuaviewer.org
Sun Jan 29 09:00:06 PST 2012


On 01/20/2012 10:53 AM, David Seikel wrote:
> 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 <zatzai at zatzai.com> wrote:
>
>> 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?
> I would say yes, keep working on viewers.
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.

> 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.
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.

We should probably rephrase the questions, but now the wiki's down. Meh.
>> 2. Firestorm, how closely do we want to work with them, or even for
>> them etc?
> Ewww, no not work for them.  You should work with all TPV developers,
> just as all of us have.
"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.

>> 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)?
> 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.
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).

>> 4. Any new client will use the Kokua name, should the project name 
>> change to Kokua as well or stay Imprudence?
> Imprudence has the brand recognition.
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.

>> 6. What focus should the project take, features or stability? Second 
>> Life first and foremost or OpenSim/Aurora?
> 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.
I think here, too, we need to distinguish between Imprudence and Kokua.
For Kokua, becoming usable for OpenSim is only possible *with* 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.)

>> 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?
> Opt in is good.  Also include if 64 bit users are using the 32 bit
> version.
Good idea. :-)

> One question I want to add - if you go ahead with Imprudence, is the
> feature freeze over already?
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.

> 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?
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.

Cheers,
Boroondas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kokuaviewer.org/pipermail/kokua-dev-kokuaviewer.org/attachments/20120129/7afce339/attachment-0002.htm>


More information about the kokua-dev mailing list