View mode: basic / threaded / horizontal-split · Log in · Help
October 12, 2009
dmd development model.
This has been raised numerous times by many people before, but still I'm going to write it. The last three releases are broken for both QtD and tango. Why is it happening? I see the reason in the dmd development model. Say dmd 2.031 works for a project (which can be a large one). The consequent release 2.032 does not. If you make a diff between the two versions it's considerably large. How are we supposed to locate the regression?

If dmd delepers contributed every change to the VCS separately, it would be much easier to track down the change that caused the issue. From my side I could test the version of dmd from trunk every 2 days and file bugs as they appear. That's how most of the open source projects work, and this model works fine. Few days before the release there can be an appropriate notice, so that people could test their code. That would make dmd releases less buggy. I know that Walter sends the compiler to tango devs prior to release, but that's not a robust solution to the problem, developers may not have time at the moment for example. However with the truly open model not only core developers of projects, but anyone can test the compiler.

What we have now is annoying. We have a series of non-working releases. LDC for example still hasn't updated it's front-end since dmd 1.045. Putting dmd to svn was a great move, but without adopting the advantages of VCS it's rather useless.

Thank you,
Eldar.
October 12, 2009
Re: dmd development model.
On Mon, 12 Oct 2009 14:48:17 -0400, Eldar Insafutdinov wrote:

> This has been raised numerous times by many people before, but still I'm
> going to write it. The last three releases are broken for both QtD and
> tango. Why is it happening? I see the reason in the dmd development
> model. Say dmd 2.031 works for a project (which can be a large one). The
> consequent release 2.032 does not. If you make a diff between the two
> versions it's considerably large. How are we supposed to locate the
> regression?
> 
> If dmd delepers contributed every change to the VCS separately, it would
> be much easier to track down the change that caused the issue. From my
> side I could test the version of dmd from trunk every 2 days and file
> bugs as they appear. That's how most of the open source projects work,
> and this model works fine. Few days before the release there can be an
> appropriate notice, so that people could test their code. That would
> make dmd releases less buggy. I know that Walter sends the compiler to
> tango devs prior to release, but that's not a robust solution to the
> problem, developers may not have time at the moment for example. However
> with the truly open model not only core developers of projects, but
> anyone can test the compiler.
> 
> What we have now is annoying. We have a series of non-working releases.
> LDC for example still hasn't updated it's front-end since dmd 1.045.
> Putting dmd to svn was a great move, but without adopting the advantages
> of VCS it's rather useless.
> 
> Thank you,
> Eldar.

Same opinion here.
There are quite some nice fixes in the last releases,
but it's useless if other regressions make it unusable.

I (sort of) understand why Walter can't look at other projects code
and can't even test it for legal reasons.


This problem would be solved by multiple commits over time (between 
releases). Users can test their projects against dmd trunk (Tango, QTD to 
name only a few).
It would be easier to locate and fix problems _before_ releases.
No beta/Pre- releases are needed.

A VCS is not for final code, it's for dirty work.
trunk don't have to contain shiny code with a history of complete commits.
It's allowed to be messy.
October 12, 2009
Re: dmd development model.
Eldar Insafutdinov wrote:
> This has been raised numerous times by many people before, but still I'm going to write it. The last three releases are broken for both QtD and tango. Why is it happening? I see the reason in the dmd development model. Say dmd 2.031 works for a project (which can be a large one). The consequent release 2.032 does not. If you make a diff between the two versions it's considerably large. How are we supposed to locate the regression?
> 
> If dmd delepers contributed every change to the VCS separately, it would be much easier to track down the change that caused the issue. From my side I could test the version of dmd from trunk every 2 days and file bugs as they appear. That's how most of the open source projects work, and this model works fine. Few days before the release there can be an appropriate notice, so that people could test their code. That would make dmd releases less buggy. I know that Walter sends the compiler to tango devs prior to release, but that's not a robust solution to the problem, developers may not have time at the moment for example. However with the truly open model not only core developers of projects, but anyone can test the compiler.
> 
> What we have now is annoying. We have a series of non-working releases. LDC for example still hasn't updated it's front-end since dmd 1.045. Putting dmd to svn was a great move, but without adopting the advantages of VCS it's rather useless.
> 
> Thank you,
> Eldar.

FWIW I do as you say with Phobos.

Andrei
October 12, 2009
Re: dmd development model.
Eldar Insafutdinov wrote:
> If dmd delepers contributed every change to the VCS separately, it
> would be much easier to track down the change that caused the issue.

Yeah, that's probably a good idea.

> From my side I could test the version of dmd from trunk every 2 days
> and file bugs as they appear. That's how most of the open source
> projects work, and this model works fine. Few days before the release
> there can be an appropriate notice, so that people could test their
> code. That would make dmd releases less buggy. I know that Walter
> sends the compiler to tango devs prior to release, but that's not a
> robust solution to the problem, developers may not have time at the
> moment for example.

I do send it out for beta, but nobody responds.

> However with the truly open model not only core
> developers of projects, but anyone can test the compiler.
> 
> What we have now is annoying. We have a series of non-working
> releases. LDC for example still hasn't updated it's front-end since
> dmd 1.045. Putting dmd to svn was a great move, but without adopting
> the advantages of VCS it's rather useless.
> 
> Thank you, Eldar.
October 12, 2009
Re: dmd development model.
On Mon, 12 Oct 2009 13:50:14 -0700, Walter Bright wrote:

> Eldar Insafutdinov wrote:
>> If dmd delepers contributed every change to the VCS separately, it
>> would be much easier to track down the change that caused the issue.
> 
> Yeah, that's probably a good idea.
> 
>> From my side I could test the version of dmd from trunk every 2 days
>> and file bugs as they appear. That's how most of the open source
>> projects work, and this model works fine. Few days before the release
>> there can be an appropriate notice, so that people could test their
>> code. That would make dmd releases less buggy. I know that Walter sends
>> the compiler to tango devs prior to release, but that's not a robust
>> solution to the problem, developers may not have time at the moment for
>> example.
> 
> I do send it out for beta, but nobody responds.

Thanks for your reply.

I think the people in question are too busy with life atm.
but I've also heard that there might not be enough time for review.

Anyway, more frequent commits would
make this procedure unnecessary at all. ;)
October 12, 2009
Re: dmd development model.
Walter Bright Wrote:

> Eldar Insafutdinov wrote:
> > If dmd delepers contributed every change to the VCS separately, it
> > would be much easier to track down the change that caused the issue.
> 
> Yeah, that's probably a good idea.
> 
> > From my side I could test the version of dmd from trunk every 2 days
> > and file bugs as they appear. That's how most of the open source
> > projects work, and this model works fine. Few days before the release
> > there can be an appropriate notice, so that people could test their
> > code. That would make dmd releases less buggy. I know that Walter
> > sends the compiler to tango devs prior to release, but that's not a
> > robust solution to the problem, developers may not have time at the
> > moment for example.
> 
> I do send it out for beta, but nobody responds.
> 
> > However with the truly open model not only core
> > developers of projects, but anyone can test the compiler.
> > 
> > What we have now is annoying. We have a series of non-working
> > releases. LDC for example still hasn't updated it's front-end since
> > dmd 1.045. Putting dmd to svn was a great move, but without adopting
> > the advantages of VCS it's rather useless.
> > 
> > Thank you, Eldar.

Thank you. This is a great news for many of us. I will try my best to locate the regression I've discovered and make a testcase.

Eldar.
October 12, 2009
Re: dmd development model.
Moritz Warning wrote:
> I think the people in question are too busy with life atm.
> but I've also heard that there might not be enough time for review.

That's fine, but I've also emailed them that if they needed more time to 
let me know, and those generated no response either.

If people want to be on the beta list, email me and let me know.
October 13, 2009
Re: dmd development model.
Walter Bright, el 12 de octubre a las 14:56 me escribiste:
> Moritz Warning wrote:
> >I think the people in question are too busy with life atm.
> >but I've also heard that there might not be enough time for review.
> 
> That's fine, but I've also emailed them that if they needed more
> time to let me know, and those generated no response either.
> 
> If people want to be on the beta list, email me and let me know.

I was about to ask the same thing via a private mail, but since there is
already a public discussion, here is what I think =)

I know it could be a little hard for you to change the way you work and
start making small self-contained commits, but since there are a lot of
bug fixes with patches in bugzilla now (thanks for releasing the code BTW,
which made this possible :), at least for those patches, is very easy to
do a single commit for each one.

And I agree, making DMD releases more organized could improve a *lot* this
situation. All you have to do is schedule the release, you can have
a period of time where you fold in new changes / bug fixes, then declare
a "feature freeze" ("bug fix folding freeze" for DMD 1) and make a release
candidate. You can give, I don't know, about a week, for testing the RC
and if there are no regressions or complains, you do the actual release
(or fix the regressions before releasing if there is any).

The RC can be just a tag in the VCS (I think it would be nicer to have an
easily distributable package though, Robert even offered himself to do
nightly builds automatically for you, so that shouldn't be a problem if
the offer is still open).


I think you are making huge improvements in moving DMD to a more open
development model (which I think it's crucial for widespread adoption of
D). If you can do smaller commits, improve the release scheduling and do
RCs, it would be a new huge step in that direction.


Thanks.

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi
October 13, 2009
Re: dmd development model.
Leandro Lucarella wrote:
> I know it could be a little hard for you to change the way you work and
> start making small self-contained commits, but since there are a lot of
> bug fixes with patches in bugzilla now (thanks for releasing the code BTW,
> which made this possible :), at least for those patches, is very easy to
> do a single commit for each one.
> 
> And I agree, making DMD releases more organized could improve a *lot* this
> situation. All you have to do is schedule the release, you can have
> a period of time where you fold in new changes / bug fixes, then declare
> a "feature freeze" ("bug fix folding freeze" for DMD 1) and make a release
> candidate. You can give, I don't know, about a week, for testing the RC
> and if there are no regressions or complains, you do the actual release
> (or fix the regressions before releasing if there is any).
> 
> The RC can be just a tag in the VCS (I think it would be nicer to have an
> easily distributable package though, Robert even offered himself to do
> nightly builds automatically for you, so that shouldn't be a problem if
> the offer is still open).
> 
> 
> I think you are making huge improvements in moving DMD to a more open
> development model (which I think it's crucial for widespread adoption of
> D). If you can do smaller commits, improve the release scheduling and do
> RCs, it would be a new huge step in that direction.


I do agree that opening up the full source of dmd has been a huge win. 
There are a lot of eyeballs looking at the code now, and a lot of 
patches for it posted to bugzilla. I admit I'm a little slow in changing 
the way I find it comfortable to work, but things do get better <g>.
October 13, 2009
Re: dmd development model.
Walter Bright, el 12 de octubre a las 21:57 me escribiste:
> Leandro Lucarella wrote:
> >I know it could be a little hard for you to change the way you work and
> >start making small self-contained commits, but since there are a lot of
> >bug fixes with patches in bugzilla now (thanks for releasing the code BTW,
> >which made this possible :), at least for those patches, is very easy to
> >do a single commit for each one.
> >
> >And I agree, making DMD releases more organized could improve a *lot* this
> >situation. All you have to do is schedule the release, you can have
> >a period of time where you fold in new changes / bug fixes, then declare
> >a "feature freeze" ("bug fix folding freeze" for DMD 1) and make a release
> >candidate. You can give, I don't know, about a week, for testing the RC
> >and if there are no regressions or complains, you do the actual release
> >(or fix the regressions before releasing if there is any).
> >
> >The RC can be just a tag in the VCS (I think it would be nicer to have an
> >easily distributable package though, Robert even offered himself to do
> >nightly builds automatically for you, so that shouldn't be a problem if
> >the offer is still open).
> >
> >
> >I think you are making huge improvements in moving DMD to a more open
> >development model (which I think it's crucial for widespread adoption of
> >D). If you can do smaller commits, improve the release scheduling and do
> >RCs, it would be a new huge step in that direction.
> 
> I do agree that opening up the full source of dmd has been a huge
> win. There are a lot of eyeballs looking at the code now, and a lot
> of patches for it posted to bugzilla. I admit I'm a little slow in
> changing the way I find it comfortable to work, but things do get
> better <g>.

Well, thanks for trying and doing it, even when doing it slowly =)

By the way, using a VCS capable of bisecting[1] combined with small
commits makes finding which code introduced a regression very easy, even
without having a small testcase (this is the problem we have right now
with Tango for example).

So I hope you can consider doing small commits (again, at least for the
patches in bugzilla that are already small in general). I'm not suggesting
changing the VCS (yet :) because it can be a little hard to learn a new
VCS and we can automatically convert the svn to other VCS (or use git-svn)
in the meantime.

[1] Practical exmaple using Git:
   http://jbowes.wordpress.com/2007/02/18/git-bisect-a-practical-example-with-yum/

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
	-- Carla Lucarella (10/2008 contando de su viaje a México)
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home