Don Clugston, el  3 de junio a las 22:45 me escribiste:
> On 3 June 2010 16:28, Leandro Lucarella <llucax at gmail.com> wrote:
> > Walter's job goes from:
> > 1) Copy the text from bugzilla
> > 2) Open a text file
> > 3) Paste the text
> > 4) Save the text file
> > 5) Apply the patch
> > 5bis) Maybe modify the patch in some way
> > 6) Commit, writing a commit message
> 
> >
> > To:
> > 1) run git pull URL BRANCH
> 
> This shows a significant misunderstanding of where the time goes.
> There are three things that take a lot of time: (1) understanding the
> bug, and how the patch is trying to fix it;  (2) running the test
> suite (takes about half an hour); (3) adding the bug to the test
> suite.

That is (or should be) all part of fixing the bug, not merging the
patch.

(The non-availability of the test suite is another *big* issue in
allowing good contributions).

> Making the changes to the existing code is usually (though not always) pretty trivial and quick. The majority of the patches which I have made are just one-line or two-line changes.

OK, but I don't see the relation with what I was talking about.

> You've also missed the steps of reproducing the existing bug, and checking that the bug now passes. This always involves copying code from bugzilla into a text editor.

And, again, is (or should be) part of making the patch, not merging it.

> It should be pretty clear from this that (2) and (3) have some major
> opportunities for efficiency improvement. Far more significant IMHO
> than any changes to the compiler version control system.

That's probably true, but without a public test suite I can't make any suggestions on how to improve that =)

But again, I don't want to flame in this list, I really like this list being concise and to the point, and let the NG general group for more philosophic discussions. So, I'm not trying to convince anyone of anything, just wanted you to give it a thought. If you really think that using a DVCS will not help enough to make the effort, seems pretty reasonable for me. I just think the development model of D has a lot to improve (as I stated before), but I know this kind of changes are hard.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Every year is getting shorter never seem to find the time.
Plans that either come to nought or half a page of scribbled lines.
Hanging on in quiet desparation is the English way.
The time is gone, the song is over, thought I'd something more to say.

Walter Bright, el  3 de junio a las 14:16 me escribiste:
> Don Clugston wrote:
> >This shows a significant misunderstanding of where the time goes.
> >There are three things that take a lot of time: (1) understanding the
> >bug, and how the patch is trying to fix it;  (2) running the test
> >suite (takes about half an hour); (3) adding the bug to the test
> >suite.
> >Making the changes to the existing code is usually (though not always)
> >pretty trivial and quick. The majority of the patches which I have
> >made are just one-line or two-line changes.
> >
> >You've also missed the steps of reproducing the existing bug, and checking that the bug now passes. This always involves copying code from bugzilla into a text editor.
> >
> >It should be pretty clear from this that (2) and (3) have some major
> >opportunities for efficiency improvement. Far more significant IMHO
> >than any changes to the compiler version control system.
> >
> 
> A couple more things need to happen:
> 
> 4. have to fold it into D1, or if it's a D1 patch, fold it into D2 5. update change logs, bugzilla resolution messages

And that is (or should be) part of making the patch too, not merging it. If patches are not good or complete enough, you should give people feedback and tell them what to change to make a quality and complete patch, not fix the patch for them. If you do that, people will not learn and you will work much more than you should, as it happened when the back-end source was not available. I hope sometime in the future you can see that.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
3 people die every year, testing if a 9 volts battery works on their tongue

Leandro Lucarella wrote:
> And this last issue is independent of the DVCS, seriously Walter, please

Is there any part of using a DVCS that fundamentally couldn't be had with a branches directory in the current SVN repo? If anyone with a dsource account could request a branch to play around in, what but a given UI would be different?

On 6/3/2010 8:51 PM, Benjamin Shropshire wrote:
> Leandro Lucarella wrote:
>> And this last issue is independent of the DVCS, seriously Walter, please
> 
> Is there any part of using a DVCS that fundamentally couldn't be had with a branches directory in the current SVN repo? If anyone with a dsource account could request a branch to play around in, what but a given UI would be different?

There's a lot of useful features:
  1) private local branches
  2) full source history so you can diff and explore offline
  3) isolation from failures of 'the central repo'
  4) exchanging changes quickly and easily between non-central repos
      (ok, you might argue that one is just #1 and #3 combined)

Likely several more will occur to me right after hitting send. :)

I actually like git quite a lot, but I still argue that it's learning curve / brick wall makes it user unfriendly enough to not bother.  ie, the startup costs make the benefit hard to justify.  There's so many OTHER process changes I'd like to see that are totally independent from the way we manage source that I'd rather work on those first.

Later,
Brad

On 6/3/2010 3:39 PM, Leandro Lucarella wrote:
> 
> 
> Walter Bright, el  3 de junio a las 14:16 me escribiste:
>>
>> A couple more things need to happen:
>>
>> 4. have to fold it into D1, or if it's a D1 patch, fold it into D2 5. update change logs, bugzilla resolution messages
> 
> And that is (or should be) part of making the patch too, not merging it. If patches are not good or complete enough, you should give people feedback and tell them what to change to make a quality and complete patch, not fix the patch for them. If you do that, people will not learn and you will work much more than you should, as it happened when the back-end source was not available. I hope sometime in the future you can see that.
> 

You want the barrier to entry for patch creation to be as low as possible. Every hoop you make people jump through the less likely they are to bother doing anything.  Feedback is certainly good, and might increase the quality of the submissions.  I'll take an incomplete fix over no fix though.

As a specific version of that, if I had to fix D1 as well, I'd likely stop producing fixes.  My interest lies in D2 alone.  It's easy to argue that a fix for d2 is worth having without the corresponding d1 fix.

You want the work Walter has to do to be as low as possible.  The more someone else does the less he does and the higher the overall throughput.  There's obvious goodness here.

Those are conflicting goals.  There's no perfect solution, but there's always room for improvement, so it's all good.

Later,
Brad

Brad Roberts, el  3 de junio a las 21:45 me escribiste:
> On 6/3/2010 3:39 PM, Leandro Lucarella wrote:
> > 
> > 
> > Walter Bright, el  3 de junio a las 14:16 me escribiste:
> >>
> >> A couple more things need to happen:
> >>
> >> 4. have to fold it into D1, or if it's a D1 patch, fold it into D2 5. update change logs, bugzilla resolution messages
> > 
> > And that is (or should be) part of making the patch too, not merging it. If patches are not good or complete enough, you should give people feedback and tell them what to change to make a quality and complete patch, not fix the patch for them. If you do that, people will not learn and you will work much more than you should, as it happened when the back-end source was not available. I hope sometime in the future you can see that.
> > 
> 
> You want the barrier to entry for patch creation to be as low as possible.  Every hoop you make people jump through the less likely they are to bother doing anything.  Feedback is certainly good, and might increase the quality of the submissions.  I'll take an incomplete fix over no fix though.

Of course, but feedback is the key. I'm not saying to be a jerk and tell people "your patch is not good enough, next!" like the soup nazi. I'm talking about *encouraging* people to make good patches. People is often more willing to do it if they have good advice that you might think.

Please, don't focus in the possible "negative" side of what I say. I'm not suggesting to be unreasonable.

> As a specific version of that, if I had to fix D1 as well, I'd likely stop producing fixes.  My interest lies in D2 alone.  It's easy to argue that a fix for d2 is worth having without the corresponding d1 fix.

That's another issue. Porting a patch to another branch is another type of work. And it makes sense that that is done by the branch maintainer (that, unfortunately, now Walter is for both branches; I think it would be good to have a maintainer for D1 so Walter can focus on D2).

> You want the work Walter has to do to be as low as possible.  The more someone else does the less he does and the higher the overall throughput.  There's obvious goodness here.

I don't understand what you mean.

> Those are conflicting goals.  There's no perfect solution, but there's always room for improvement, so it's all good.

:)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y tuve amores, que fue uno s?lo
El que me dej? de a pie y me ense?? todo...