How about a quality release with a small subset of the final functionality? <br><br><br>Sergej<br><br><div class="gmail_quote">On Sun, Feb 15, 2009 at 12:56 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is my take on the matter.<br>
<br>
To start with I don't think one distribution scheme or library will<br>
ever work - the work<br>
making it consistent is colossal.<br>
<br>
I rather like what's happened in the javascript world.<br>
<br>
Here there is a core-language, and alternative sets of rather-good libraries.<br>
<br>
To me a good library has<br>
<br>
     - a book (or books) -<br>
     - community who contribute to the library<br>
     - a unifying principle<br>
     - a set of applications that use the library<br>
<br>
The javascript jquery and protoype libraries live up these criteria.<br>
<br>
After I finished the erlang book I started writing a library and a number of<br>
applications based on the library. My plan is:<br>
<br>
     a) write a base library and applications<br>
     b) open source it and invite community participial<br>
     c) improve quality of library through participation<br>
     d) write a book describing the library<br>
<br>
I'm in the middle of a) - I now have a dilemma, should I release now or later.<br>
<br>
advantages: early feedback<br>
disadvantages: quality problems - it's in a bit of a mess, so it gets<br>
a bad reputation.<br>
<br>
Or wait a year or so:<br>
<br>
advantages: higher quality of release<br>
disadvantage: loose user feedback<br>
<br>
Do you want software "early and buggy, badly documented" or<br>
"late and better documented, higher quality"<br>
<br>
I would welcome some feedback here<br>
<br>
/Joe Armstrong<br>
<br>
<br>
<br>
2009/2/15 Edwin Fine <<a href="mailto:erlang-questions_efine@usa.net">erlang-questions_efine@usa.net</a>>:<br>
<div><div></div><div class="Wj3C7c">><br>
><br>
> On Sat, Feb 14, 2009 at 9:29 PM, Tim Watson <<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>><br>
> wrote:<br>
>><br>
>> ><br>
>> > I am using sinan/faxien exclusively, and have installed and maintained<br>
>> > four<br>
>> > Erlang production systems with them. There were some teething issues,<br>
>> > some<br>
>><br>
>> This is interesting - I also started out with good feelings about<br>
>> sinan/faxien, but they appear to redistribute the core OTP libraries<br>
>> which is anathema where I work.<br>
><br>
> Martin & Eric can speak for themselves, but my point of view is that, well,<br>
> they don't really redistribute them as such. They are forced to build them<br>
> using their own tools and put them in their WebDAV repository because (a)<br>
> The OTP team doesn't support such a repository, and (b) they have to make<br>
> minor tweaks to the add their metadata, which is necessary for the<br>
> distribution mechanism. The metadata doesn't exist - or, in the case of .app<br>
> files, sometimes doesn't quite fit in - in the OTP distribution. I am pretty<br>
> (99%) sure there is no fiddling with the source code at all, it's just an<br>
> alternative way to build it, no more suspicious than building OTP from the<br>
> tarball. If there was a way to build OTP with their (Erlware) tools in a<br>
> 100% automated way, then anyone could do it, but they are not quite there<br>
> yet (as far as I know). So that is indeed a sticking point, I can see.<br>
><br>
>> We're simply not allowed (by law) to<br>
>> run code on "some version" of kernel/stdlib/etc that didn't come from<br>
>> a verified (official) sources, even if it did in reality (if you see<br>
>> what I mean). This is an issue of regulatory compliance, so we're<br>
>> stuck and can't use the tools, which are (I agree) very nice bar some<br>
>> minor usability issues. I suspect this puts a lot of people off - it's<br>
>> not as maven downloads and installs the JDK for you is it, and for<br>
>> good reason - I'd be surprised if that many people actually wanted<br>
>> this.<br>
>><br>
>> Clearly there are mixed opinions about whether a repository for<br>
>> publishing applications and a distributed build system that can<br>
>> consume code from public/private repos, is a good approach. That's to<br>
>> be expected, but this idea of redistributing "Erlang itself" is<br>
>> another thing altogether. It seems like trying to force too many new<br>
>> ideas at once, and I suspect this is a big part of the problem.<br>
><br>
><br>
> Again, I believe they don't WANT to redistribute Erlang. It's a huge pain in<br>
> the butt to have to tweak new Erlang releases to build with their toolset,<br>
> and it's not really the fault of their toolset, it's just minor<br>
> inconsistencies here and there that cause issues. If they could get it right<br>
> that anyone could build Erlang itself using Sinan, and then put it in their<br>
> own private Erlware repo with Faxien, these objections would largely go<br>
> away.<br>
><br>
> If you look at what Ruby has managed to achieve with Gems, and (I think)<br>
> Python with "eggs", it is quite reasonable to expect that we should be able<br>
> to distribute our own Erlang apps in a pre-built form in a way that makes it<br>
> really easy to update. I use this mechanism to update production servers in<br>
> a number of different countries, and the previous way I did it was just<br>
> horrible. It's so much easier for me just to log into the remote server,<br>
> type in "faxien upgrade-release myapp", maybe tweak the sys.config, and then<br>
> restart the application (I don't need hot code update yet). The sad thing is<br>
> that Erlware is *so* close to being really great, and is held back mostly<br>
> because the authors are so busy actually earning a living that they don't<br>
> have enough time to devote to ironing out the wrinkles.<br>
><br>
> My great hope is that the Erlang/OTP team will see enough merit in this<br>
> approach to make this a standard distribution mechanism, but I don't hold<br>
> out much hope (not because the team is unreasonable or anything, but because<br>
> of the overhead of supporting builds across many hardware platforms and<br>
> version within the platforms.) An easier and even better thing would be if<br>
> they actually used Erlware to build the Erlang source code; then we could<br>
> all build it with Erlware and the main objection would be solved. Also, they<br>
> could put some resources on it to help with the wrinkles.<br>
><br>
> Just dreaming ;)<br>
><br>
><br>
</div></div><div><div></div><div class="Wj3C7c">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>