Klaus Schmidinger wrote:
Andreas Trauer wrote:Just starting with a first step would be quiet easy: All patches you already apply to your own VDR, could be seen by others in the CVS, so everyone can apply these changes right away. The changes you do by your own are not in the ML AFAIK. We get them not before the next (pre-)release. And then there are probably so many changes, that there can be conflicts with the patched versions.
Hi list, hi Klaus,
there are so many different patches and patch collections for VDR.
Is there a reason that there is no CVS system (e.g. sourceforge.net) used?
Yes: I prefer to keep it the way it is
I just prefer to release complete versions, rather than having to
deal with a CVS tree that grows wild into hundreds of directions.
I'll surely adopt patches (or at least the ideas behind them, since
many patches just do too much, and don't adhere to the VDR coding style,
so they can't be used just like that as I continue development,
and the first thing I'll work on will be the auto-PID stuff.
I didn't mention, that I was thinking about small patches/changes. I can't apply your intermediate patches, I can't apply small changes to the big patches (like Elchi etc...). And I don't know where to put my patches. Not all patch packets can be found here, some are in vdrportal.de, some are elsewhere. A CVS system could be a place where the good patches could go. If someone wants it all, he just need to check out the latest version. No need to find all the patches, no need to solve conflicts between patches (some may change some parts differently and they all base on the latest release version or even earlier versions).
I found the "newbie question" by Bud Millwood in the archive (Tue, 27
May 2003 17:15:15 +0200),
but the answers are not sufficient.
When someone has a patch, then it would be a good idea to put it in the
CVS, so everyone could apply it right away, but there is still one
version of the VDR.
A patch doesn't need to be in a CVS so that everybody can apply it. Or am I missing something here?
That is what I expect. You would be the maintainer. You could check those patches into the the official CVS when you decide that the patches are ok, e.g. bugfixes. If someone posts a bugfix on things I'm not involved in, I don't know if it is good to apply it or not. If you check it into the CVS, then I believe that it is checked by you and can apply it. Without CVS I have to wait for the next release and hope that it has not to much conflicts with the patch packets or my own patches I applied.Of course there must be someone, who decides which patch is interesting
enough for the most people. Probably Klaus (with some proxies?).
I prefer to decide for myself what goes into the official VDR
source code
I can understand that in the question functionality vs. stability you prefer stability for the official release, so functionality comes a little bit later.I see a lot of advantages in using a CVS system. There are a lot of
people providing good patches for different functionalities. The most
patches are provided for the mainline VDR 1.2.5, some are only for older
versions, but when some patches are applied, there will be problems to
apply more patches, that are based on the mainline version only.
If these patches would become part of the mainline, then it would be
much easier. Everyone could benefit from the better functionality.
The thing is just that I only want to have those things in the main
line that I am personally convinced of. I'd rather make additional
plugin interfaces that allow people to modify things as they like
than have each and every bell and whistle in the core code.
To me it doesn't make a difference either. I still would need to handle the different patches, they just don't belong to the VDR anymore, but to the plugins.Klaus, you have mailed on Tue, 20 May 2003 10:55:39 +0200 in the thread
*"vdr near final - time for cosmetic changes?" *that you plan to provide
a plugin interface for the OSD, that were the Elchi patch could go, but
that would not solve the problem, just move it to another place, because
there are also people who want to patch the Elchi-version to make it
look even better.
And where exactly would a CVS make a difference here? Wheter you patch a patch or patch a plugin doesn't seem that much different to me...
I think that there is a big gap between "blindly adopting" and "really convinced".So IMHO the best way would be, when the most patches would go in the
mainline as soon as possible after the patches are created, so everyone
could update his VDR before providing new (smaller) patches.
As I said above, I only want to have those things in the core code that I am really convinced of. If I would blindly adopt each and every patch just as it comes up, I believe the core code would degenerate pretty soon.
Andreas Trauer wrote:
Hi list, hi Klaus,Yes: I prefer to keep it the way it is ;-)
there are so many different patches and patch collections for VDR.
Is there a reason that there is no CVS system (e.g. sourceforge.net) used?
I just prefer to release complete versions, rather than having to
deal with a CVS tree that grows wild into hundreds of directions.
I'll surely adopt patches (or at least the ideas behind them, since
many patches just do too much, and don't adhere to the VDR coding style,
so they can't be used just like that ;-) as I continue development,
and the first thing I'll work on will be the auto-PID stuff.
I found the "newbie question" by Bud Millwood in the archive (Tue, 27A patch doesn't need to be in a CVS so that everybody can apply it.
May 2003 17:15:15 +0200),
but the answers are not sufficient.
When someone has a patch, then it would be a good idea to put it in the
CVS, so everyone could apply it right away, but there is still one
version of the VDR.
Or am I missing something here?
Of course there must be someone, who decides which patch is interestingI prefer to decide for myself what goes into the official VDR
enough for the most people. Probably Klaus (with some proxies?).
source code ;-)
I see a lot of advantages in using a CVS system. There are a lot ofThe thing is just that I only want to have those things in the main
people providing good patches for different functionalities. The most
patches are provided for the mainline VDR 1.2.5, some are only for older
versions, but when some patches are applied, there will be problems to
apply more patches, that are based on the mainline version only.
If these patches would become part of the mainline, then it would be
much easier. Everyone could benefit from the better functionality.
line that I am personally convinced of. I'd rather make additional
plugin interfaces that allow people to modify things as they like
than have each and every bell and whistle in the core code.
Klaus, you have mailed on Tue, 20 May 2003 10:55:39 +0200 in the threadAnd where exactly would a CVS make a difference here?
*"vdr near final - time for cosmetic changes?" *that you plan to provide
a plugin interface for the OSD, that were the Elchi patch could go, but
that would not solve the problem, just move it to another place, because
there are also people who want to patch the Elchi-version to make it
look even better.
Wheter you patch a patch or patch a plugin doesn't seem
that much different to me...
So IMHO the best way would be, when the most patches would go in theAs I said above, I only want to have those things in the core
mainline as soon as possible after the patches are created, so everyone
could update his VDR before providing new (smaller) patches.
code that I am really convinced of. If I would blindly adopt
each and every patch just as it comes up, I believe the core code
would degenerate pretty soon.
Klaus
-- Info: To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.