Thanks Ryan for explaining all that is involved. Indeed it looks like it's not just a problem of compiling Hugin on your own computer...
On Wed, Nov 18, 2009 at 10:32 AM, Ryan Sleevi <ryan+hu...@sleevi.com<ryan%2bhu...@sleevi.com> > wrote: > > well I'd be thrilled to contribute and I do use windows. actually I've > > been going off it lately but I imagine it's cyclical. > > What I would require is a crude explanation what is and how works C > > and what is C ++ how is the same name for program language different > > in windows and unix. I would need to know what these differences are > > before I dived in and tried to figure stuff out > > mick > > Not to discourage anyone from contributing, because it's always welcome, > but > it's important to understand that the lack of Windows binaries is not > solely > related to 'the lack of someone to compile them,' which I think is what Yuv > was getting at originally before the flame war erupted. > > What is needed is someone to do for the Windows side what Yuval > (previously) > did for the general releases: Someone who can shepherd the platform, > maintain it, and support it. For example, what happens if someone has a > crash that is only on Windows? Who will be responsible for tracking it > down, > getting diagnostic information, etc? Who will maintain the installer, > ensuring everything gets put in its proper place? And let's not forget > dependencies - and all their myriad configurations. When development > progresses, will the person building binaries have the necessary knowledge > and skill to keep their environment up to date - and to ensure that when > it's prepared for end-users, it's kept as simple and clean as possible? > > There has definitely been a lot of interest in getting Windows compiled - > which is great, as it's a good beginners step into this. However, judging > by > the questions on the list so far, it doesn't seem like (and I hope I'm not > offending anyone when I say this) that no one who has stepped up really > understands what the challenges were and are, and that the same quality > concerns may persist once your first 'hugin.exe' is sitting in your output > directory. > > I've seen suggestions about possible installer scripts and the like - > except > there is already an installer script that, while valid for 0.7.0, > definitely > needs polish and attention. I've seen a lot of questions about dependencies > and compilation bugs (on all platforms, for that matter), when many of the > questions are already answered on the Wiki. While yes, I'm aware that > sounds > dangerously close to the anti-user "RTFM", it really cannot be understated > how important that step is. > > In terms of what has (historically) prevented a 0.8.0 release, consider the > following: > - No one has stepped up to own the installer. A huge amount of work is > already done, but there is still significant work to be done to put > together > an end-user-friendly, international-law-abiding installer. > - No one has stepped up for the 'cat herding' task of building a plan for > how a Windows release might go. Once the binaries are built (which, not to > insult anyone, really is the easiest part), how will they get tested on the > various platforms? How will feedback be collected? How will issues be > addressed - Windows specific issues, installer issues, platform issues? > - What about 32-bit and 64-bit binaries? They *are* different, they *do* > have different build steps and, while their dependencies are the same, > actually resolving those dependencies requires quite a few different steps. > For Linux and Mac this is much easier, but on a platform like Windows, with > a build system like CMake, a compiler like MSVC, and a (justifiable) policy > of static linking, this is a whole new set of challenges. > - How will the exes be 'audited'? Consider that in the case of Linux, > you're > often building from source or seeing it distributed by your distro vendor - > which is a nice clean audit trail of "no back doors". For Mac and Windows, > when shipping binary versions, there is a matter of trust - trust which > takes time to establish (as Harry has). Certainly that needs to be a > consideration, even as a community with no specific liability. > > For those who are realizing that this task is a lot larger than perhaps > they'd realized, or that it involves a set of skills that they may not > necessarily have, don't be disheartened - there are still ways to > contribute. Testing and feedback will always be a necessary part, just as > interface design and behaviour will be important as well. > > While I can understand how Yuval's message seems to have got lost or > misinterpreted, I would absolutely agree with the concerns he expressed on > his personal page regarding the significance of this task, and why it is > frustrating when people are frequently asking on list. It's not that there > is anything wrong for asking, it's just that it's not nearly as simple as > people may think it is, and it's misguided and potentially insulting to > insist that it is, as some have in the past. > > > -- > You received this message because you are subscribed to the Google Groups > "hugin and other free panoramic software" group. > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hugin-ptx@googlegroups.com > To unsubscribe from this group, send email to > hugin-ptx+unsubscr...@googlegroups.com<hugin-ptx%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/hugin-ptx > -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
