View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2012
Re: D Stable Proposal
On 11/30/2012 05:30 AM, 1100110 wrote:
> A few of the requests were:(in no specific order)
> Base Update and Upgrade paths on successful projects, such as Debian's
> Three branches.

To be honest, I don't think that what is needed is a detailed proposal for the 
branch structure etc.  There are only so many ways you can do it, after all, and 
the details don't matter so much as long as an effective stable version comes 
out of it.

What _is_ needed is to get people committed to actually doing the work to 
maintain a stable version.  Once you have the people, they can work out the 
details for themselves.


> I can also include specific versions of LDC and GDC (and any other compiler
> willing to target a release.)

I think that before bringing LDC/GDC into the equation, it would help if we got 
to the point where the frontend was genuinely portable, as discussed e.g. here:
http://forum.dlang.org/post/mailman.1565.1352137245.5162.d.gnu@puremagic.com
November 30, 2012
Re: D Stable Proposal
On 11/30/12 4:49 AM, 1100110 wrote:
> Andrei's support is also necessary, IIRC he is one of main person behind
> phobos. A stable version of D is not useful without a stable version of
> phobos and druntime to go with it.

I'm very supportive of a serious, meaningful initiative.

My perception is that we're having growing pains - our process is 
lagging behind the participation in the project and the attention it 
receives. If Walter and I do not acknowledge that in time and act 
swiftly on it, we're heading toward a crisis in the community much, much 
larger and dangerous than the D1/D2 schism.


Andrei
November 30, 2012
Re: D Stable Proposal
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
> In the thread: Breaking D2 Language/Spec, A lot of good points 
> were made regarding a Stable branch for D.
>
> A few of the requests were:(in no specific order)
> Base Update and Upgrade paths on successful projects, such as 
> Debian's
> Three branches.
>
> 1. Stable branch
> - Stable branch only receives bug fixes and is updated at 
> predetermined intervals.
> - Updates are clones of upstream.
> - Do not update too often, as that causes too much work. (6, 8, 
> 12 months)
> - Do not break code unless extremely necessary. (Not even then?)
> - Document all changes, Document every release
> - Make each transition as simple as possible.
> - Warn stable users about soon to be broken code.
> - Do not allow Stable and upstream to diverge too much. (See 
> Walters's comment regarding D1.)
>
> 2. Tools
> - Provide Tools to allow easier transition between releases.
>
> 3. Testing branch.
> - What should go here?  Need clear lines in the sand.
>
> There's more, but this is already way too much for one person 
> to handle.
> But with enough support, all of them are entirely possible.
>
> So here I have a few questions, both for the D maintainers and 
> the community.
>
> 1. What did I miss that is requested?
> 2. What should definitely be removed?
>
> The question was raised as to why I created a project instead 
> of a simple branch.
>
> If people want to volunteer, I can set permissions to allow 
> them access.
> A project and a branch are not mutually exclusive.
> Druntime and Phobos depend on specific versions on D, do they 
> not?
> So those projects would need to remain in sync as well.
>
> A project simplifies things to an extent.
> The dmd developers do not need to have any involvement at all, 
> or it can be as tightly integrated as they wish.
>
> I can also include specific versions of LDC and GDC (and any 
> other compiler willing to target a release.)
>
> I wanted room to expand.
> The worse that can happen is that this is completely ignored, 
> nobody uses it, and I eventually lose interest in something 
> that has no support from the community or the devs. (I'm not 
> stopping for any other condition. You're stuck with me.)
>
> The best that can happen is that D Stable receives support from 
> the D Developers and the community, allowing for many tools to 
> be created targeting a Stable specification of the Language.
>
>
> Let's define a specification for this thing, shall we?
> First things first!
>
> How long should support of the Stable branch last?
> 1. 6 months
> 2. 12 months
> 3. longer (specify and give reasons)
>
> Now how do we organize this?
> 1.
> The current git master will be considered Unstable, and will 
> freeze to define the next Stable.
> Are there better ideas than this?
>
> 2.
> Do we want to go with Stable, Testing, Unstable or another 
> system?
> I'd like to see some pros and cons before making any decisions.
> I'm leaning towards the 3 stage system.
>
> Yes, this is ambitious.  So is D.  And D appears to be thriving.
> Yes, I know that I cannot even accomplish half of this alone.
> That's the point.  There was a lot of discussion, so this 
> obviously interests many people.
> By myself, I can maintain a specific version of DMD with 
> non-breaking bugfixes.  That is about it.
>
> Let's do this thing.

For all this to actually be possible we need branch maintainers - 
it is not an easy job and not many people are capable of doing it 
on production level. It is easy to complain and whine about 
problems. I haven't seen people actually offer to help here...
November 30, 2012
Re: D Stable Proposal
On Friday, 30 November 2012 at 15:08:24 UTC, Andrei Alexandrescu 
wrote:
> On 11/30/12 4:49 AM, 1100110 wrote:
>> Andrei's support is also necessary, IIRC he is one of main 
>> person behind
>> phobos. A stable version of D is not useful without a stable 
>> version of
>> phobos and druntime to go with it.
>
> I'm very supportive of a serious, meaningful initiative.
>
> My perception is that we're having growing pains - our process 
> is lagging behind the participation in the project and the 
> attention it receives. If Walter and I do not acknowledge that 
> in time and act swiftly on it, we're heading toward a crisis in 
> the community much, much larger and dangerous than the D1/D2 
> schism.
>

The thing is that I don't see that succeed as an external project.

This is like we wanted both vegetarian and non vegetarian food, 
and reached that goal by cooking everything all together and then 
some people spent their time to separate the meat from the rest.

Most likely they'll get bored rapidly as it is a lot of boring 
work, that is useless if the process don't mix everything in the 
first place.
November 30, 2012
Re: D Stable Proposal
On Friday, 30 November 2012 at 18:14:58 UTC, deadalnix wrote:
>
> The thing is that I don't see that succeed as an external 
> project.
>

I agree that it cannot be an external project, and instead it has 
to become the official D process.

For example, as was discussed, and i think generally agreed on, 
we have to change the way the version numbering works to a 
major.minor.revision model  (unless someone has a better idea to 
propose, which I'd love to know about).

There's been mention that maintaining multiple branches will 
fail, and I see that someone has previously attempted to create a 
stable version of D that has in fact failed.

Rather than taking on a defeatist attitude, we need to look at 
those past failures and learn from them, so as not to repeat the 
same mistakes over again, and also to figure out a better 
solution that has a better chance for success.

There's been mention that branch maintenance will be a great deal 
of tedium for a maintainer, so I think that's an area that needs 
to be dealt with first. If it's too difficult to maintain, I 
agree it probably won't be maintained for very long.

We have to make it so that the path of least resistance for 
everyone is to follow whatever process is eventually worked out.

I also do expect to see some failures here and there, but that's 
normal and to be expected, we just have to be persistent until a 
workable solution is found.

The issue here, as stated by Andrei, which I fully agree with, is 
that D is fighting for its own life. We have no choice but to 
improve the process, otherwise D will never grow past the current 
point it is at and will eventually fade away into obscurity.

This is a do or die situation IMO.

--rt
November 30, 2012
Re: D Stable Proposal
On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote:
> The issue here, as stated by Andrei, which I fully agree with, 
> is that D is fighting for its own life. We have no choice but 
> to improve the process, otherwise D will never grow past the 
> current point it is at and will eventually fade away into 
> obscurity.
>
> This is a do or die situation IMO.
>
> --rt

Sorry, that came out in an overly bleak way. The really REALLY 
good news, is that D has grown to the point where we are being 
forced to adapt to the growth. What we're hoping to achieve is a 
way that removes the limiters that are holding D back from 
further growth.

The "do or die" scenario only happens if D cannot continue to 
grow, and other competing languages take over, like Rust and 
perhaps Go. That's the only dire part to pay attention to, the 
optimistic point being that we are forced to grow because of D's 
success, not because of its failures.

--rt
November 30, 2012
Re: D Stable Proposal
On Friday, 30 November 2012 at 19:52:44 UTC, Rob T wrote:
> On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote:
>> The issue here, as stated by Andrei, which I fully agree with, 
>> is that D is fighting for its own life. We have no choice but 
>> to improve the process, otherwise D will never grow past the 
>> current point it is at and will eventually fade away into 
>> obscurity.
>>
>> This is a do or die situation IMO.
>>
>> --rt
>
> Sorry, that came out in an overly bleak way. The really REALLY 
> good news, is that D has grown to the point where we are being 
> forced to adapt to the growth. What we're hoping to achieve is 
> a way that removes the limiters that are holding D back from 
> further growth.
>
> The "do or die" scenario only happens if D cannot continue to 
> grow, and other competing languages take over, like Rust and 
> perhaps Go. That's the only dire part to pay attention to, the 
> optimistic point being that we are forced to grow because of 
> D's success, not because of its failures.
>
> --rt

A much simpler way to state the current situation is that we're 
in fact experiencing a "good problem"!

--rt
November 30, 2012
Re: D Stable Proposal
On Fri, 2012-11-30 at 06:02 -0600, 1100110 wrote:
> I have just been reading that for advice and find the --no-ff
> comments 
> confusing.  Can you explain that please?  I see two contradicting
> claims.
> 
> 

Well the comments say that --no-ff does not create a single commit of
the merged in commits, but only create a merge commit. Which is right,
but it suffices to preserve the merge information and what was merged.
In a fast forward merge basically the following happens:


---*----*-----*-----*master
You branch to my_branch and do a commit

---*----*-----*-----*master
                   |----*mybranch

If you merge mybranch into master now:
---*----*-----*-----*----*master/mybranch


The information is now lost that the last commit actually came from
mybranch, with --no-ff you get a merge commit, which is special because
it has two parents:

git merge --no-ff mybranch:
                   
                   
---*----*-----*-----*---- * master
                   |    /
                   |----*mybranch

You can now list the commits that came from mybranch with the following
command:
git log master^..master^2

or simply visually print the merge graph in the log messages:
git log --graph
December 01, 2012
Re: D Stable Proposal
On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote:
> On 11/30/12 4:49 AM, 1100110 wrote:
>> Andrei's support is also necessary, IIRC he is one of main person behind
>> phobos. A stable version of D is not useful without a stable version of
>> phobos and druntime to go with it.
>
> I'm very supportive of a serious, meaningful initiative.
>
> My perception is that we're having growing pains - our process is
> lagging behind the participation in the project and the attention it
> receives. If Walter and I do not acknowledge that in time and act
> swiftly on it, we're heading toward a crisis in the community much, much
> larger and dangerous than the D1/D2 schism.
>
>
> Andrei

I know, I feel the same way.
December 03, 2012
Re: D Stable Proposal
On Saturday, 1 December 2012 at 03:16:36 UTC, 1100110 wrote:
> On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote:
>> On 11/30/12 4:49 AM, 1100110 wrote:
>>> Andrei's support is also necessary, IIRC he is one of main 
>>> person behind
>>> phobos. A stable version of D is not useful without a stable 
>>> version of
>>> phobos and druntime to go with it.
>>
>> I'm very supportive of a serious, meaningful initiative.
>>
>> My perception is that we're having growing pains - our process 
>> is
>> lagging behind the participation in the project and the 
>> attention it
>> receives. If Walter and I do not acknowledge that in time and 
>> act
>> swiftly on it, we're heading toward a crisis in the community 
>> much, much
>> larger and dangerous than the D1/D2 schism.
>>
>>
>> Andrei
>
> I know, I feel the same way.

The alienation will be between those who want to see D continue 
to evolve, vs those who want to see D cast in stone from any 
further breaking changes.

Example, check out the madness being argued in this thread ...
http://forum.dlang.org/thread/sdcmmiqtlcfrfgvmwvrr@forum.dlang.org?page=1

This kind of clashing will only get worse unless something is 
done about it.
--rt
1 2 3 4
Top | Discussion index | About this forum | D home