forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: How To submit a patch
Date Thu, 25 Nov 2004 11:37:11 GMT
David Crossley wrote:
> I really don't like this 'build patch' ability.
> Sorry Cheche, it is a good idea but


...

> There are big problems with the 'build patch' target
> because it just packages the diffs for *every* changed
> file that it finds. This is okay if those are the only
> changes in a users' working copy. However when they have
> other work in testing, then that stuff gets added in too.

Yes, there is not much can be done about that. Although it shouldn't be 
too hard for us to work our way through that - but then I haven't tried 
and you have :-))

> The biggest issue occurs when they submit a patch to the
> issue tracker, and it sits there because we don't have time
> or priority to commit it. When next they go to make other
> contributions, the old changes are still tangled up in their
> automated patch.

Well a patch shouldn't just sit there like that. I know, it's very easy 
for me to say that most of us have other stuff to do and we can't focus 
all the time on the patches submitted for individual needs (must have 
been a good 8 months between my commits at one point). But we really 
need to make a concerted effort to get patches applied ASAP. If we are 
trying to attract more developers we need to acknowledge those who are 
contributing and get there patches applied quickly.

For potential new developers getting those first couple of patches 
applied and seeing the credits on changes.html are critical in 
encouraging a developer to stick with the project.

I, for one, will do the best I can to apply patches quickly (I have alot 
of time for Forrest at the moment - have you noticed ;-))

> It would be better if we had a simple How-To document that
> just described the manual steps ... svn diff > mypatch.txt

Yes, this would be good, but the first time you try to create such a 
patch you tend to get confused (well I did) and include everything, 
which brings us back to stage one again from a developer point of view 
and makes it much harder for new developers.

I like making the barrier as low as possible for the first patch (build 
patch is good for this) and then we can focus on educating developers on 
the "correct" was after that first patch is applied.

So, in summary, I would say lets keep "build patch" for the user list 
(perhaps with a disclaimer saying "only use this if you don't know how 
to create a proper patch using the svn tools"). On the dev list we 
ensure folk know how to use the svn tools as you suggest.

Ross

Mime
View raw message