digitalmars.D - dmd development model.
- Eldar Insafutdinov (5/5) Oct 12 2009 This has been raised numerous times by many people before, but still I'm...
- Moritz Warning (14/41) Oct 12 2009 Same opinion here.
- Andrei Alexandrescu (3/11) Oct 12 2009 FWIW I do as you say with Phobos.
- Walter Bright (3/22) Oct 12 2009 I do send it out for beta, but nobody responds.
- Moritz Warning (6/22) Oct 12 2009 Thanks for your reply.
- Walter Bright (4/6) Oct 12 2009 That's fine, but I've also emailed them that if they needed more time to...
- Leandro Lucarella (31/39) Oct 12 2009 I was about to ask the same thing via a private mail, but since there is
- Walter Bright (5/29) Oct 12 2009 I do agree that opening up the full source of dmd has been a huge win.
- Leandro Lucarella (22/53) Oct 13 2009 Well, thanks for trying and doing it, even when doing it slowly =)
- Robert Clipsham (6/10) Oct 13 2009 This is still on my to do list... I've pretty much got what I want
- Leandro Lucarella (9/20) Oct 13 2009 Thanks Robert for taking care of this.
- Eldar Insafutdinov (3/29) Oct 12 2009 Thank you. This is a great news for many of us. I will try my best to lo...
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
Moritz Warning <moritzwarning web.de> 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
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
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
On Mon, 12 Oct 2009 13:50:14 -0700, Walter Bright wrote:Eldar Insafutdinov wrote: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. ;)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.
Oct 12 2009
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
Walter Bright, el 12 de octubre a las 14:56 me escribiste:Moritz Warning wrote: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 KiwiI 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
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
Walter Bright, el 12 de octubre a las 21:57 me escribiste:Leandro Lucarella wrote: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)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 13 2009
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
Robert Clipsham, el 13 de octubre a las 16:26 me escribiste:Leandro Lucarella wrote: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...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
Walter Bright Wrote:Eldar Insafutdinov wrote: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.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