Patch files for Contributions?

[airblaster]

Hi,

 

is there a reason that contributions usually don't include a patch file?

Or is it just that nobody thought of that before? ( but somehow I have got the feeling thats not the case...).

I think if contributions included a patch file it would make the wohl job of customizing OSC a lot easier, so I'd like to suggest including them.

 

Anyways, thanks to everyone for your great work on OSC!

[Guest]

You would have to ask individual contribution authors about this. There is no standard for maintaining these contributions and they aren't checked by the OSC team for any reason whatsoever.

[airblaster]

but wouldn't it be better to make some suggested guidelines of what a mod should contain, etc?

It would take a lot of time just to discuss this topic witch every single author of an contribution, and I don't think everyone would want to do it.

But if there was an suggested guideline they would think about it and maybe include patches.

[Guest]

Sure it is always easier to do something like that before you start. As it is now, I would say 10% of the contributions even have an author listening, 20% are coded by people who have no idea what they are doing and the reminder are abandoned.

 

However even with guidelines, there will be people who don't care and won't do it or won't have the technical expertise to follow the guidelines.

[Guest]

A lot of people don't have patch/diff on their development system, so for many people, a patch file would be just wasted space. Also, it wouldn't be *a* patch file, it would be multiple patch files. Very few contributions only modify one file.

 

The way that (good) contributions do it now is best. Offer up some context and a line number in a file. Show changes that need to be made. Everyone can use this, without switching OSes or buying outside tools. It provides enough information to handle modified files as well, which can be problematic when applying patch files.

 

As to the question of whether it would be better to make guidelines (in fact, look here for what currently exists), sure it would. However, that's all they would be is guidelines. It is better to encourage people to share their code, regardless of how they do it. In other words, it is better to make it possible for people to share their code without having to go through a long redesign process first. That's the whole purpose of open source, to make people's work generally available, so that others do not have to reinvent the wheel.

 

If there was a requirement for patch files, then there would end up being some people who did not know how to make a patch file or did not have the tools. Rather than go through all the trouble of learning and obtaining, some would simply not bother to share their code.

 

Cheers,

Matt

[airblaster]

guess its better to divide my answer into two parts...:

 

1.) Technical Problems (since I don't know what you know already I'll just write everything that could be important)

 

Almost every system has got the programs needed for free.

On Linux like Systems they are usually installed or can easily be installed from CD/DVD.

On Windows you don't need to install a complete development environment because there is already an rather easy to install package that includes everything thats neacessary: http://unxutils.sourceforge.net.

Another way that would be even more convenient in daily use would be making the patches out of CVS, but thats harder install and learn.

 

It isn't that much to do if you do one thing at a time. If you do it without CVS you just keep a copy of your old code and do a:

'diff -u -r -P oldcodedir newcodedir > mycontribution.diff'

There will only be one file that contains _all_ the changes, including newly created files.

(well, there might be better ways to use it, but this should work. Actually I began using diff and patch just about a week ago, so I'm quite new to this)

 

Even easier... open a commandline/shell at the root-directory of a catalog that hasn't this contribution (or an earlier version of it) applied and do a 'patch -p 1 --dry-run < mycontribution.diff' to test if the patch is working with you codebase. If its ok you just do a 'patch -p 1 < mycontribution.diff', if not you probeably need to change the -p 1 parameter (just take a look at 'patch --help' on how to use it)

 

2.) Weither its a good thing or not

 

First off: I don't say that people should quit making contributions the way the do now. I just say it would be nice if they also could include a patch file (or additionally upload the same Version of the Code additionally in a patch file only package if the size is really that much of an problem).

 

I also think if someone hasn't got the time to make a patchfile its better to release his/her contribution without it. Patchfiles should definitly not be a requirement.

But an additional patchfile whenever it is possible would be great. It would allow anyone who takes 30 Minutes to install the required tools and read the manual to apply most patches within two minutes.

[zimonline]

I have whated to do somthing like this aloge time ago but the problems r

 

1) first patch works fine but after that it gets tricky as the filees have been changed

 

2) stoped that idea after 1

 

What i am intrested in is a pach that take the clean code and adds a bunch of mods all together along the same lines as loaded5

this patch could then be supported as a contrabution and not as OSC

[tbannist]

My contribution (Product Query Factory / Query Factory) does use patch. But I the reason most contribution don't has more to do with the nature of the contributors than anything else. I would guess that most of the contributors are not experienced software developers, they're hobbists who likely don't even know that they don't know how to create a patch file. You've got three problems to solve, one getting people realize that patch files exist, two getting them realize that they're good and three getting them to learn how to make them.