| 1 |
В Срд, 04/08/2010 в 09:42 +0000, Jorge Manuel B. S. Vicetto пишет: |
| 2 |
> If you take KDE's team example, we provide ebuilds to track the stable |
| 3 |
> branch from upstream in our overlay. They're called <version>.9999. |
| 4 |
> It's true that our ebuild does use the live vcs, but in this case the |
| 5 |
> difference is that instead of the users using a live ebuild, they get |
| 6 |
> a snapshot of the tree done by our maintainer from time to time. |
| 7 |
> Trying to pretend these "snapshot" ebuilds are the release version is |
| 8 |
> very wrong and no one should assume they'll build fine. |
| 9 |
|
| 10 |
Even for official upstream releases build tests are not enough. So there |
| 11 |
is not difference with _p here. |
| 12 |
|
| 13 |
> There are already a few bugs that can be attributed to this. |
| 14 |
|
| 15 |
Ok, let's say that this depends on upstream. And for Gentoo this means |
| 16 |
that the decision how to set version for the package depends on |
| 17 |
maintainer. Lot's of packages do not have dedicated release tests |
| 18 |
upstream (even build tests) and for this packages I don't see difference |
| 19 |
between stable branch and release. In such case our version just |
| 20 |
indicates that our package is base on tarbal of that version and nothing |
| 21 |
more. |
| 22 |
|
| 23 |
> The point here is that one thing is for a maintainer to pick specific |
| 24 |
> commits from the stable branch and back port them to fix some bugs, |
| 25 |
> another thing is to blindly fetch a snapshot of the stable branch. |
| 26 |
|
| 27 |
In reality it's hard to see difference if commit was done blindly or it |
| 28 |
was well tested until obvious crash happens. |
| 29 |
|
| 30 |
> It would be based on a release if it only applied specific patches to |
| 31 |
> fix known issues. The minute you start "tracking" a stable branch you |
| 32 |
> should stop calling it a release and 300kloc is not a "small" patch. |
| 33 |
|
| 34 |
Actually I think this limit depends on size of project. In any case |
| 35 |
until we have something documented that's up to maintainer... |
| 36 |
|
| 37 |
> This is unfortunately the main issue here. You may work on a specific |
| 38 |
> package on Gentoo, but when that package is essential for the system |
| 39 |
> use / stability, it stops being just "your" package. This latest |
| 40 |
> example has lead users to a point where their PM stopped working. |
| 41 |
> Breaking the PM is not a small "oops" |
| 42 |
|
| 43 |
That's completely different topic... I'm not talking about stability at |
| 44 |
all. Of course, python is special package and should be treated/tested |
| 45 |
by maintainers as such! Probably for such core packages ~arch is not |
| 46 |
enough and we need different process... But that a different topic. |
| 47 |
|
| 48 |
Bug I mentioned pretends that we have policy how to set version for |
| 49 |
packages that use backported upstream patches. My point is that there is |
| 50 |
no such policy and line between _p or -rN is very fuzzy to set such |
| 51 |
policy. Thus bug itself is INVALID... |
| 52 |
|
| 53 |
-- |
| 54 |
Peter. |
Archives