On March 26, 2011 01:35:56 PM kfj wrote: > I just wish there had been more > success solving issues on 'exotic' systems...
That's beyond your control, don't feel responsible. sometimes it is the
limitations of the 'exotic' system, sometimes it is lack of time, interest,
skill, or a combination of factors on the side of the users of the 'exotic'
system. You have done everything right, gone the extra mile to help, now
accept the situation as it is and enjoy wandering the alps.
> 30 minutes a day is just over 2% of your lifetime (and a larger
> percentage of your waking time, which is probably worth more than the
> sleep you get during the extended lifespan). So it'd better increase
> your lifespan by more than 1.6 years ;-)
ROTFL! I admit that I find jogging unexciting. But wandering through green
alpine pastures is fitness-equivalent and yields more benefits than just
health. I am missing the Alps. And this place we moved to last year is so
flat I have not had a chance to put skis under my feet this winter :(
> What I meant is that you could just lump together a suitable Linux
> plus all the tools and libraries, make a VM from it and offer it for
> download without having to pay anyone any licenses.
Yes, you can and similar things are done, but how practical / convenient are
these VMs in everyday' life?
> VirtualBox is free for all systems, so it'd be easy to let
> everyone have a VM like that and give them an easy start on coding for
> hugin without having to worry about platform-specific issues. Just an
> idea.
It's about the same has having branches in the repositories. They are there,
free and easy, and yet most users of the repo ignore them and go with
default.
> > really not your problem.
>
> It sort of is, though, because, really, I'm not so terribly interested
> in the interface itself but I want to use it. If it never makes it to
> mainstream status, all effort I put into using it is reduced to my
> personal pleasure, where I'd much rather share it with the bunch.
Don't worry, it will make it into mainstream / default. Right now we are only
lacking the bandwidth.
> > You are being very kind and trying to help them, but
> > it is ultimately their problem and you can stop conceptually at the
> > "reference platform".
>
> I don't think an attitude of 'it's their problem' is helpful here. If
> I've learned one thing during this involvement with the project, it's
> that a 'me and them' attitude is wrong and doesn't work.
I don't mean "their problem" in an attitude sense. I mean it in an ownership
sense. As things are set up currently, you can't own this problem. You could
if you had access to the platform where the problem occurs, but access to that
platform has a monetary cost and nobody can demand that you bear it.
> I did look at the code maturity criteria. Of course I made my best
> effort to satisfy a and c. And I had lots of help along the way -
> thanks to everyone! But then I tried to instigate having b finished as
> well, and it failed on the Mac OS front. So the code still technically
> qualifies as immature. I have no choice but to leave it at that, and
> at least I have hopes that this won't be a show-stopper. I've just
> stood back and done other stuff for the last few weeks.
I don't think that it will be a show stopper. It does not prevent building on
all supported platform and it does not obstruct any of the existing core and
non-core functionality on any platform.
The most likely scenario I see coming for the next months is that we integrate
your code into default and release 2011.2 and subsequent releases with python
scripting disabled for OSX until the necessary resources come along to enable
this functionality on OSX as well.
If anything, we should learn from this that the maturity criteria can be
refined in terms of core and non-core functionality.
The current maturity criteria assume that all functionality is core
functionality.
Introducing the category of non-core functionality, the maturity criteria for
it would be:
* a: the non-core functionality works on the developer's machine ("works for
me" condition)
* b: the non-core functionality is not essential to the basic operation of the
software and does not prevent build and operation of core functionality on the
major supported platforms ("does not hinder them" condition) verified by at
least one contributor for each: Windows, OSX, Linux
* c: it does not unintentionally break existing core or non-core functionality
("no regression" condition)
The definition of core vs. non-core is not set in stone and evolves as the
software evolves. HSI/PSI is non-core at the moment, but may become core
later on.
> http://groups.google.com/group/hugin-ptx/browse_thread/thread/a402da2fde3c0
> b8a#
>
> but so far, noone seems to have noticed the thread. Is there anyone
> out there who already has hsi/hpi up and running? Give it a spin and
> tell me what you think! I wasn't sure whether I should add it to the
> hugin_scripting branch, since it's quite large, so it's in my bazaar
> repo for now.
Please add it to the hugin_scripting branch. The more layers there are
between the default branch and the functionality, the less feedback you will
receive.
I personally don't have bandwidth for hsi/hpi at the moment. When 2011.0 is
out of the way and hsi/psi is integrated in default, I will have a little bit
of bandwidth for it. My sole use of Hugin in the last three months was
perspective correction for pictures that will go into an art exhibition
booklet. Not an hsi/psi application. Sorry.
Yuv
signature.asc
Description: This is a digitally signed message part.
