Brad Roberts wrote:
> Reports just mean more people are using the thing.

5 new ones today!

Brad Roberts, el  2 de junio a las 22:25 me escribiste:
> On 6/2/2010 9:22 PM, Leandro Lucarella wrote:
> > Trass3r, el  2 de junio a las 20:00 me escribiste:
> >>> You've been doing some great work. But the bugs are still being filed faster than they're being fixed :-(
> >>>
> >>
> >> Maybe guys like Don and so on who have done such awesome work in the past should get commit rights to speed up the fixing process.
> > 
> > And maybe is time for a DVCS, so Don (and others) can maintain their
> > own repos (which could be tested by other people too) and Walter can
> > easily pull patches that are working fine without any effort (now
> > I guess Walter have to do the patching and commiting himself, which is
> > more time consuming than a simple pull command).
> > 
> > I think is good for consistency that there is only one person who decides what goes in the official repo and what not, the problem is (I guess) now that task is very time consuming. DVCS makes that very easy.
> 
> For my 2 cents:
> 
> The dcvs systems are still too user unfriendly (though git is the only one I've used for more than toying around, I've looked at a couple others at least a little).

I don't think they are user unfriendly, is just a mind change you have to do. It's hard to change, it might have a steep learning curve, but once you set your mind around it, it's really easy to use (and very friendly, really, they put a lot of focus on usability; and I'm talking about git too).

> Additionally, I don't find the "put ready patches in bugzilla" to be particularly problematic at all from my end.

Me either! I'm not suggesting stop using bugzilla at all! What I suggest is to keep bugzilla as it is, but add a simple extra line "You can pull this patch from my repo at URL, branch BRANCH".

The 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

You can see the current approach is a lot of work for Walter (maybe he has some more efficient system than this, but it's a lot of work anyways).

There. Even more, you keep authorship information, which is lost now (the best you can do to see who is the author of a patch is go to bugzilla, and even then, you never know if the patch was applied as it was in bugzilla or if it was modified by Walter).

> In some ways it's superior, being guaranteed to stick around longer than someone might keep a random dcvs repo around.

As I said, I think too that it's good to have the patches in bugzilla too.

> Lastly, at least for my few contributions so far, I don't think any of them has gone in without at least some minor changes.

And that's another problem with the current approach, as I see it. People making patches receive feedback very rarely. It shouldn't be Walter who fixes the problematic patches, it should be the original author. This way, the author can learn and improve his future patches, and, again, Walter will have less work and could apply the patches faster. This point could be sound insignificant, but I beg Walter to give it a thought. Is like the issue of the source availability for the whole compiler. At first sight it could seems to be no big deal, since people had the front-end source and other backends to try patches out. In reality the patch submission situation improved exponentially with the release of the full source of the compiler. I think this issue will have the same effect, allowing people to contribute more and better code to the compiler.

And this last issue is independent of the DVCS, seriously Walter, please give it a thought. I think it would be a major difference if you start giving feedback to people about the patches and let them fix them instead of doing it yourself.


PS: Sorry about the long e-mail =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The number of wars fought between countries
That both have at least one McDonalds is zero

On Jun 3, 2010, at 10:28 AM, Leandro Lucarella <llucax at gmail.com> wrote:

> Brad Roberts, el  2 de junio a las 22:25 me escribiste:
>>
>>
>> For my 2 cents:
>>
>> The dcvs systems are still too user unfriendly (though git is the
>> only one I've
>> used for more than toying around, I've looked at a couple others at
>> least a little).
>
> I don't think they are user unfriendly, is just a mind change you have
> to do. It's hard to change, it might have a steep learning curve, but
> once you set your mind around it, it's really easy to use (and very
> friendly, really, they put a lot of focus on usability; and I'm
> talking
> about git too).

steep learning curve == user unfriendly

Anything is usable with enough practice...


>
>> Additionally, I don't find the "put ready patches in bugzilla" to be particularly problematic at all from my end.
>
> Me either! I'm not suggesting stop using bugzilla at all! What I
> suggest
> is to keep bugzilla as it is, but add a simple extra line "You can
> pull
> this patch from my repo at URL, branch BRANCH".
>
> The 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

You're stacking the deck by skipping steps you put in the other list.


> You can see the current approach is a lot of work for Walter (maybe he has some more efficient system than this, but it's a lot of work anyways).

I agree it'd be slightly easier on Walter after he had practice.

>

> The dcvs systems are still too user unfriendly (though git is the only
> one I've
> used for more than toying around, I've looked at a couple others at
> least a little).

I disagree. It might require some rethinking if you have exclusively used conventional CVS systems so far but in the end they are as user-friendly. In the end it's only 1 extra step to push the changeset to dsource after the local commit.

Mercurial might be less complicated than Git. I can't say for sure though cause I use the Windows Tortoise versions anyway. These are nearly equivalent when it comes to user-friendliness.

Jason House, el  3 de junio a las 11:42 me escribiste:
> On Jun 3, 2010, at 10:28 AM, Leandro Lucarella <llucax at gmail.com> wrote:
> 
> >Brad Roberts, el  2 de junio a las 22:25 me escribiste:
> >>
> >>
> >>For my 2 cents:
> >>
> >>The dcvs systems are still too user unfriendly (though git is
> >>the only one I've
> >>used for more than toying around, I've looked at a couple others
> >>at least a little).
> >
> >I don't think they are user unfriendly, is just a mind change you have
> >to do. It's hard to change, it might have a steep learning curve, but
> >once you set your mind around it, it's really easy to use (and very
> >friendly, really, they put a lot of focus on usability; and I'm
> >talking
> >about git too).
> 
> steep learning curve == user unfriendly
> 
> Anything is usable with enough practice...

I don't agree, but I won't continue talking about this subject, it was not my intention to start a VCS-war. =)

> >>Additionally, I don't find the "put ready patches in bugzilla" to be particularly problematic at all from my end.
> >
> >Me either! I'm not suggesting stop using bugzilla at all! What I
> >suggest
> >is to keep bugzilla as it is, but add a simple extra line "You can
> >pull
> >this patch from my repo at URL, branch BRANCH".
> >
> >The 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
> 
> You're stacking the deck by skipping steps you put in the other list.

What steps?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
No debemos temer a la muerte, porque es la mejor recompensa de la vida.
	-- Ren & Stimpy

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.
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.

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

On Jun 3, 2010, at 2:17 PM, Leandro Lucarella <llucax at gmail.com> wrote:

> Jason House, el  3 de junio a las 11:42 me escribiste:
>> On Jun 3, 2010, at 10:28 AM, Leandro Lucarella <llucax at gmail.com> wrote:
>>
>>>
>>>
>>> The 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
>>
>> You're stacking the deck by skipping steps you put in the other list.
>
> What steps?

 From the original steps: 5bis, 6, and an equivalent of 1 for copy/
paste of the URL. 5bis is really 90% (or more) of the work which is
why the exact version control methodology is almost unimportant.

I'm not trying to argue for/against svn/git. I just want to ensure a
balanced presentation of facts.

Don Clugston <dclugston at googlemail.com> 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.

3) Could be ameliorated by having a known folder for the test suite, and pull contents to that as well.

> 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.

See above. Any bug could have an associated test file.

Both of these ideas place the onus of patching on the patcher, not on Walter. Of course, both would require a naming standard and possibly further information on the details.

-- 
Simen

Jason House, el  3 de junio a las 17:17 me escribiste:
> On Jun 3, 2010, at 2:17 PM, Leandro Lucarella <llucax at gmail.com> wrote:
> 
> >Jason House, el  3 de junio a las 11:42 me escribiste:
> >>On Jun 3, 2010, at 10:28 AM, Leandro Lucarella
> >><llucax at gmail.com> wrote:
> >>
> >>>
> >>>
> >>>The 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
> >>
> >>You're stacking the deck by skipping steps you put in the other list.
> >
> >What steps?
> 
> From the original steps: 5bis, 6, and an equivalent of 1 for copy/ paste of the URL. 5bis is really 90% (or more) of the work which is why the exact version control methodology is almost unimportant.

I think this is missing the point, but just for completeness, 1) is not
necessary for frequent contributors, as you can "alias" a remote repo.
Walter can do something like:
git remote add don URL_FOR_DON # once
git pull don BRANCH

5bis was covered by the other part of the e-mail. The ideal would be that Walter give enough feedback to let contributors narrow that 90% to nothing with enough time. Even more, as more people get expertise, other people could do the patch reviewing/feedback, so the final patch that Walter pull at the end don't take any Walter's attention. But again, this is independent of the VCS.

> I'm not trying to argue for/against svn/git. I just want to ensure a balanced presentation of facts.

Excellent. I'm trying to do that too.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
De tan fina la condesa, por no cagarse, reza.
	-- Ricardo Vaporeso