On 08/03/2010 03:03 PM, Peter Volkov wrote: > Hi. > > How should we version our packages in case we've backported upstream > patches from stable branch of development?
PV reflects the status of upstream that we base the ebuild on (usually a release) and then we apply individual reviewed patches on top of that in Gentoo revisions. > Bug 330667 requests _p or > _pre. I feel that _p|_pre versions should be left for VCS (read > development) versions of the package, while during backports we have the > best version with all important upstream+gentoo fixes available to the > moment and I'd better avoid to call it development. > If you read the bug you will see that our python has essentially been development versions so _p is in line with what you say above. > If we decide to go with _p or _pre could we agree on answers for the > following questions: > - Does single patch from upstream's VCS justify _p$(date|rev) version? > What if this is _the only_ patch in the upstream's VCS? No if the patch is small and can be reasonably understood. If the patch for example switches the used build system and I would think _p is called for. > - Now what about two patches? Three? N? When does few patches became > pile? You should ask upstream to make a release when they start to pile up. > - What if I drop single patch from the upstream's patchset for stable > branch, should we drop _pre _p version and add -rN? _p reflects upstream situation so dropping a patch from that is a Gentoo modification there so it would be _p12323-r1. > - What if there are two dependent patches, and first one fixes > indentation? Should we spend time on backporting second patch (time > consuming and error prone process) or use both and live closer to > upstream? > I would leave this up to the maintainer. Depends on how much time backporting takes. Regards, Petteri
signature.asc
Description: OpenPGP digital signature
