www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd development model.

reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Oct 12 2009
next sibling parent Moritz Warning <moritzwarning web.de> writes:
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.
Oct 12 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.

Oct 12 2009
next sibling parent reply Moritz Warning <moritzwarning web.de> writes:
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. ;)
Oct 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 12 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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>.
Oct 12 2009
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Leandro Lucarella wrote:
 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).

This is still on my to do list... I've pretty much got what I want working manually now, just gotta find some time to set it up to run automatically. Once it's in place, having smaller commits will really make it more useful as you'll be able to pinpoint the exact changes which caused issues or made improvements.
Oct 13 2009
prev sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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.
Oct 12 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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
Oct 12 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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)
Oct 13 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Robert Clipsham, el 13 de octubre a las 16:26 me escribiste:
 Leandro Lucarella wrote:
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).

This is still on my to do list... I've pretty much got what I want working manually now, just gotta find some time to set it up to run automatically. Once it's in place, having smaller commits will really make it more useful as you'll be able to pinpoint the exact changes which caused issues or made improvements.

Thanks Robert for taking care of this. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- I've always been mad, I know I've been mad, like the most of us... very hard to explain why you're mad, even if you're not mad...
Oct 13 2009