<div dir="ltr">=) I have no illusions and don't stop a discussion on my account. I'm just saying I won't be part of it, and I'm guessing nor anyone else from OTP, until after 17.0. I'm just hoping someone is taking notes.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-18 20:24 GMT+01:00 Tuncer Ayaz <span dir="ltr"><<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, Feb 18, 2014 at 7:02 PM, Björn-Egil Dahlberg wrote:<br>
> On 2014-02-18 18:46, Michael Truog wrote:<br>
>><br>
>> On 02/18/2014 09:30 AM, Björn-Egil Dahlberg wrote:<br>
>>><br>
>>> If/when we split the OTP repository, and this split should be on<br>
>>> the level where we have specific versions i.e. on application<br>
>>> level. It has solve the issue of easy delivery of new patches and<br>
>>> release on these specific applications. Some have voiced a concern<br>
>>> that it will simply be to many repos and we should instead group<br>
>>> them, i.e. Orber + cos* etc. I say fine, if so then those<br>
>>> applications should have one version (and be a single<br>
>>> application). One versioned entity per repository thank you.<br>
>><br>
>> My main concern is: if the OTP repository is split, we still need<br>
>> the concept of a "version set", so a set of versions for all of OTP<br>
>> that are known to work together, just to help people avoid any<br>
>> potential for instability. With that concept in place, it shouldn't<br>
>> be a problem either way, and you are probably aware of the issue,<br>
>> but I wanted to mention it due to the added complexity that not<br>
>> having a "version set" concept can cause. If you don't have that<br>
>> concept, of versions grouped into a release, basically, then you<br>
>> run into a combinatorial problem during testing, which makes<br>
>> testing take longer (i.e., for all end-users).<br>
>><br>
>><br>
><br>
> I'm aware. The "set" you talk about would ideally be controlled by<br>
> the application dependencies.<br>
><br>
> But OTP releases would be the set you talk about though and a top<br>
> repo, i.e. otp would control the set. I imagine that we would still<br>
> have releases just like today with a set of applications that we<br>
> have tested together.<br>
><br>
> As for patches, those are tested with the dependencies specified,<br>
> typically with those applications in the previous release. It would<br>
> have the same stability as before.<br>
><br>
> It is unfortunate that this debate got started now. I have actually<br>
> zero time to spend on it .. i'll can do is watch it spin into<br>
> another dimension.<br>
<br>
</div></div>Sorry, Bjoern-Egil, and it's totally fine to postpone the discussion<br>
until after R17 is released. Let's just just pause and start a new<br>
discussion when R17 is out.<br>
<br>
BTW, your arguments for splitting up the repo sound reasonable.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>