October 12, 2009
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
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
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
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
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
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
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
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
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
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