View mode: basic / threaded / horizontal-split · Log in · Help
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
> On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
>> Can we drop the LTS name ? It reminds me of ubuntu, and I 
>> clearly hope that people promoting that idea don't plan to 
>> reproduce ubuntu's scheme :
>> - it is not suitable for a programming language (as stated 3 
>> time now, so just read before why I won't repeat it).
>
> You don't need to repeat your self, you need to expand on your 
> points. Joseph has already requested that you give specifics of 
> your objection, you have explained why the situation is 
> different but not what needs to be different.
>

This is completely backward, but I'll do it anyway. But first, 
let me explain why it is backward.

You are using distro's versionning system as a base of reflexion. 
But such system is made to achieve different goal than a 
programming language. I shouldn't be here explaining why this is 
wrong, you should be here explaining me why it can be applied 
anyway.

Otherwise, anyone can come with any point, whatever how stupid it 
is, and each time we have to prove that person wrong. When you 
come with something, you have to explain why it make sens, not 
the other way around.

Back to the point, and it will be the last time. A distro is a 
set of programs. The goal of the distro is to provide a set of 
programs, as up to date as possible, that integrate nicely with 
each other, and with as few bugs as possible. Some of these goals 
are in conflict, so we see different pattern emerge, with 
different tradeoff, as ubuntu and debians's processes.

From one version to another, distro don't need backward 
compatibility. Easy migration is important, but not 
compatibility. This is why debian can switch to multiarch in its 
next version (which break a hell lot of things). You don't need 
revision of the distro because software are updated on a per 
software basis when problems are detected (package in fact, but 
it don't really matter).

This is very different from a programming language where :
- no package update is possible. The concept of package don't 
even exist in our world.
- backward compatibility is a very important point, when it isn't 
for distros.

The only goal that is coming is trying to reach some level of 
stability. Everything else is completely different.

> Your points were specific to Debian's model, which is not 
> Ubuntu's.
>
>> - ubuntu is notoriously unstable.
>
> I don't know anyone who uses the LTS releases. That isn't to 
> say no one is, but Ubuntu is doing a lot of experimenting in 
> their 6 month releases.

I used to work with ubuntu. I've done a ton of things with that 
distro. It IS unstable. In fact, it is based on debian unstable, 
so it isn't really a surprise.
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 03:59:33 UTC, Rob T wrote:
> On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
>>
>> Per my answer to Rob:
>> D2 *is* the major version.
>> releases should be minor versions and largely backwards 
>> compatible - some evolution is allowed given some reasonable 
>> restrictions like a proper migration path over several 
>> releases.
>> Critical bug-fixes can go directly on stable releases but 
>> nothing else.
>>
>
> I just realized that we are mixing together the version numbers 
> for two entirely different things.
>
> As you have correctly pointed out, one of the version numbers 
> is for the D language specification, which is version 
> 2.something, the other version is for the compiler releases, 
> which has the major language specification version assigned to 
> identify it as supporting version 2.something of the D 
> language. The remaining numbers indicate incremental releases 
> which may also roughly correspond to the minor evolutionary 
> changes to the language specification, i.e., does DMD 2.061 
> also mean D specification 2.061?
>

Yes it does. If new features are introduced, then this is by 
definition a change in the specs.

> I think it makes good sense that the "2" is used to indicate 
> that the compiler supports D major version 2 of the 
> specification, but we should all be clear that is all that it 
> represents. Therefore DMD 3.x will never appear unless there's 
> a D language ver 3 specification for it to support.
>

A version 3 would means introducing change in the specification 
that may break a lot of code. This is type of stuff you shouldn't 
do often.

> A completely separate issue that should be dealt with, is that 
> the language specification's version number is not indicated 
> anywhere that I could see. We just assume it's version 
> 2.something and we have no idea where the "something" part is 
> currently at or what has changed since ver 2.0. This is no good 
> because it means that we cannot indicate in the compiler 
> release change log what minor version of the 2.x specification 
> the compiler is actually supporting.
>

The compiler source code is probably what we have that look like 
the most as a spec right now.
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
>
> The only goal that is coming is trying to reach some level of 
> stability. Everything else is completely different.
>

There are still some clear similarities between what Debian is 
doing and what I presume most people do in software development.

For the software I develop we have what is called a "live" 
branch, which is the code that is in active use by our customers. 
This branch corresponds to the stable branch we're trying to 
achieve, and it only gets critical bug fixes until the next major 
update which includes new features and/or major adjustments as 
well as non-critical bug fixes. We also have a testing branch, 
which includes the latest pre-release code for the next major 
update. This code is running on a VM and is tested by our 
customers (and the developers), under conditions similar to 
"live". There's also a common "dev" branch for the code which is 
in development but not yet ready for testing. This branch 
corresponds to the Dev (Master) Branch, The master branch gets 
updated from individual forks owned by each developer. 
Coordination among developers is essential to prevent 
duplications and major conflicts.

So in essence we're following a similar model to the Debian model 
of (Master Dev) which is "unstable " => Pre-release Testing => 
Stable.

It works great, and I see no way to remove any of the branches 
without seriously compromising the end result.

For example, we can't go directly from Dev to Stable, that would 
be like committing suicide. We can't use testing for dev updates, 
it's too destabilizing and we'd never get a properly tested 
stable release out unless all development updates were halted for 
a long period of time, but then the individual forks would pile 
up with major changes that would be very difficult to sort out 
when merged all back together.

We need 3 common branches, and I just don't see a way out of that.

BTW, I'm using Mercurial which has many similarities to Git. 
Unfortunately I don't know my way around Git very well at this 
time.

--rt
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 08:30:04 UTC, Rob T wrote:
> On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
>>
>> The only goal that is coming is trying to reach some level of 
>> stability. Everything else is completely different.
>>
>
> There are still some clear similarities between what Debian is 
> doing and what I presume most people do in software development.
>
> For the software I develop we have what is called a "live" 
> branch, which is the code that is in active use by our 
> customers. This branch corresponds to the stable branch we're 
> trying to achieve, and it only gets critical bug fixes until 
> the next major update which includes new features and/or major 
> adjustments as well as non-critical bug fixes. We also have a 
> testing branch, which includes the latest pre-release code for 
> the next major update. This code is running on a VM and is 
> tested by our customers (and the developers), under conditions 
> similar to "live". There's also a common "dev" branch for the 
> code which is in development but not yet ready for testing. 
> This branch corresponds to the Dev (Master) Branch, The master 
> branch gets updated from individual forks owned by each 
> developer. Coordination among developers is essential to 
> prevent duplications and major conflicts.
>
> So in essence we're following a similar model to the Debian 
> model of (Master Dev) which is "unstable " => Pre-release 
> Testing => Stable.
>
> It works great, and I see no way to remove any of the branches 
> without seriously compromising the end result.
>
> For example, we can't go directly from Dev to Stable, that 
> would be like committing suicide. We can't use testing for dev 
> updates, it's too destabilizing and we'd never get a properly 
> tested stable release out unless all development updates were 
> halted for a long period of time, but then the individual forks 
> would pile up with major changes that would be very difficult 
> to sort out when merged all back together.
>
> We need 3 common branches, and I just don't see a way out of 
> that.
>
> BTW, I'm using Mercurial which has many similarities to Git. 
> Unfortunately I don't know my way around Git very well at this 
> time.
>

So distro's versioning system is good for a programming language 
because you use it successfully in your software which isn't a 
programming language (and we also don't know according to which 
goal it is successful) ?

By the way, debian testing is not what you think it is : 
http://www.debian.org/devel/testing.en.html
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 07:39:09 UTC, deadalnix wrote:
> The compiler source code is probably what we have that look 
> like the most as a spec right now.

Unfortunately that is likely the case. I hope we can all agree 
that the specification should be managed better, but it's a much 
lesser problem at the moment than what we're trying to solve in 
here.

I think once we can establish a process for development testing 
and release, the other problem areas will stand out a lot more 
clearly for elimination.

--rt
December 16, 2012
Re: Next focus: PROCESS
On Sunday, 16 December 2012 at 08:52:24 UTC, deadalnix wrote:
>
> So distro's versioning system is good for a programming 
> language because you use it successfully in your software which 
> isn't a programming language (and we also don't know according 
> to which goal it is successful) ?

Let's not get different things mixed together.

There is a compiler, which is software. There is a language, but 
it is not software, it's the specification that the compiler 
implements.

It does not matter how branches are versioned, what matters is 
how they move from a highly unstable state towards an 
increasingly stable state until it is released in stable form for 
the end-user to use.

I will agree with you that there are unique challenges for a 
compiler, however we're not really talking about a compiler 
specifically at this stage, we're talking about establishing a 
way of moving source code from an unstable form into a stable 
form. What the compiler needs to achieve is a totally different 
concept, which is unfortunately not well documented. There is the 
current language specification, which is improperly managed as I 
pointed out in a previous post, and there needs to be certain 
guidelines set for the compiler to follow that are not a part of 
the language specification, but we're straying way off course at 
this point - those problem areas will have to be dealt with 
later, otherwise absolutely nothing at all will get done. There's 
just too many things to fix up around here, so we have to pick 
and chose very carefully what to deal with first before moving on 
to the next problem.

> By the way, debian testing is not what you think it is : 
> http://www.debian.org/devel/testing.en.html

I think that I do know what Debian testing is. I do understand 
that the Debian distro is made up out of individual packages, but 
these packages can be generalized to what goes on when software 
is developed. For example, new features = new packages, code 
modifications = updated packages. When you distill things down to 
a process level, the payload managed by the process no longer 
matters so much.

--rt
December 16, 2012
Re: Next focus: PROCESS
On 12/16/2012 08:35 AM, deadalnix wrote:
> On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
>> You don't need to repeat your self, you need to expand on your points. Joseph
>> has already requested that you give specifics of your objection, you have
>> explained why the situation is different but not what needs to be different.
>
> This is completely backward, but I'll do it anyway. But first, let me explain
> why it is backward.
>
> You are using distro's versionning system as a base of reflexion. But such
> system is made to achieve different goal than a programming language. I
> shouldn't be here explaining why this is wrong, you should be here explaining me
> why it can be applied anyway.

And once again, you're failing to address the specifics of my proposal, simply 
saying "A distro and a programming language have different requirements."

Because while some of my proposals were inspired by some of the ways in which 
Ubuntu manages its releases, and share some of the same terminology, _they are 
not the same_.  In fact the only thing that it really shares with Ubuntu is the 
idea that the support and maintenance periods for long-term "stable" versions 
should overlap so that users who require that stable base have adequate time to 
upgrade.

That's useful for _any_ software no matter what the purpose.

So once again I'd ask you to engage with the specifics of my proposal -- because 
from what I've read so far, it seems like the _only_ source of your objections 
is the use of the words "Ubuntu" and "Long-Term Support", and that if I'd 
written the same proposal without those words, you'd have given a different 
response.
December 16, 2012
Re: Next focus: PROCESS
On 12/15/2012 09:39 PM, deadalnix wrote:
> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that
> people promoting that idea don't plan to reproduce ubuntu's scheme :
>   - it is not suitable for a programming language (as stated 3 time now, so just
> read before why I won't repeat it).
>   - ubuntu is notoriously unstable.

Call them "stable release cycles" if you like, which is what they are intended 
to be.  It's just that "long-term support" actually conveys quite well what 
_users_ can expect using these versions.

By the way, no one has proposed "using Ubuntu's scheme".  I made a proposal that 
drew on a number of ideas inspired by Ubuntu's release model, including 
terminology, but the actual detail was quite different and was tailored to my 
perceived requirements of D, not an operating system.

So, once again, I'd appreciate your response to those details, rather than your 
perception that I'm proposing "using Ubuntu's scheme".
December 16, 2012
Re: Next focus: PROCESS
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
> On 12/15/2012 09:39 PM, deadalnix wrote:
>> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope
>> that
>> people promoting that idea don't plan to reproduce ubuntu's scheme :
>> - it is not suitable for a programming language (as stated 3 time now,
>> so just
>> read before why I won't repeat it).
>> - ubuntu is notoriously unstable.
>
> Call them "stable release cycles" if you like, which is what they are
> intended to be.

Just one tidbit of information: I talked to Walter and we want to build 
into the process the ability to modify any particular release. (One 
possibility is to do so as part of paid support for large corporate 
users.) That means there needs to be one branch per release.

Andrei
December 16, 2012
Re: Next focus: PROCESS
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
> Just one tidbit of information: I talked to Walter and we want to build into the
> process the ability to modify any particular release. (One possibility is to do
> so as part of paid support for large corporate users.) That means there needs to
> be one branch per release.

Can you expand on the requirements/goals there a bit?  Would be useful to have a 
good sense of what kind of modifications you have in mind.

I don't think anything in what I've proposed (elsewhere in this thread, I'm 
afraid I haven't written it up on the wiki yet...) is incompatible with the 
notion of one branch per release.
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home