1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 04-08-2010 07:56, Peter Volkov wrote: |
5 |
> В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет: |
6 |
>> On 08/03/2010 03:03 PM, Peter Volkov wrote: |
7 |
>>> Bug 330667 requests _p or _pre. I feel that _p|_pre versions |
8 |
>>> should be left for VCS (read development) versions of the |
9 |
>>> package, while during backports we have the best version with |
10 |
>>> all important upstream+gentoo fixes available to the moment and |
11 |
>>> I'd better avoid to call it development. |
12 |
>> |
13 |
>> If you read the bug you will see that our python has essentially |
14 |
>> been development versions so _p is in line with what you say |
15 |
>> above. |
16 |
> |
17 |
> Quotation from the bug: |
18 |
> |
19 |
> "gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3." |
20 |
> |
21 |
> Not taking into consideration that it is possible to name _p 3.1.2 |
22 |
> I would like to point that patches are from _stable_ branch as thus |
23 |
> all users want them. This is not development version. |
24 |
|
25 |
If you take KDE's team example, we provide ebuilds to track the stable |
26 |
branch from upstream in our overlay. They're called <version>.9999. |
27 |
It's true that our ebuild does use the live vcs, but in this case the |
28 |
difference is that instead of the users using a live ebuild, they get |
29 |
a snapshot of the tree done by our maintainer from time to time. |
30 |
Trying to pretend these "snapshot" ebuilds are the release version is |
31 |
very wrong and no one should assume they'll build fine. There are |
32 |
already a few bugs that can be attributed to this. |
33 |
|
34 |
>>> If we decide to go with _p or _pre could we agree on answers |
35 |
>>> for the following questions: - Does single patch from |
36 |
>>> upstream's VCS justify _p$(date|rev) version? What if this is |
37 |
>>> _the only_ patch in the upstream's VCS? |
38 |
>> |
39 |
>> No if the patch is small and can be reasonably understood. If the |
40 |
>> patch for example switches the used build system and I would |
41 |
>> think _p is called for. |
42 |
> |
43 |
>>> - Now what about two patches? Three? N? When does few patches |
44 |
>>> became pile? |
45 |
>> |
46 |
>> You should ask upstream to make a release when they start to pile |
47 |
>> up. |
48 |
> |
49 |
> Yup, but since "patchset being pile" is a clause to change version, |
50 |
> we should formally define what is a pile. 20kb unpacked? 10 |
51 |
> patches? Until this is done such decision is on maintainer's |
52 |
> discretion, like maintainer told in comment #1. |
53 |
|
54 |
The point here is that one thing is for a maintainer to pick specific |
55 |
commits from the stable branch and back port them to fix some bugs, |
56 |
another thing is to blindly fetch a snapshot of the stable branch. |
57 |
|
58 |
>>> - What if I drop single patch from the upstream's patchset for |
59 |
>>> stable branch, should we drop _pre _p version and add -rN? |
60 |
>> |
61 |
>> _p reflects upstream situation so dropping a patch from that is a |
62 |
>> Gentoo modification there so it would be _p12323-r1. |
63 |
> |
64 |
> Rigorously speaking even dropping one patch makes it not to be |
65 |
> _p12323 any more and we should version it somehow differently. How? |
66 |
> Since ebuild is based on upstream's stable tarbal obvious solution |
67 |
> is to use the tarbal's version. |
68 |
|
69 |
It would be based on a release if it only applied specific patches to |
70 |
fix known issues. The minute you start "tracking" a stable branch you |
71 |
should stop calling it a release and 300kloc is not a "small" patch. |
72 |
|
73 |
>>> - What if there are two dependent patches, and first one fixes |
74 |
>>> indentation? Should we spend time on backporting second patch |
75 |
>>> (time consuming and error prone process) or use both and live |
76 |
>>> closer to upstream? |
77 |
>> |
78 |
>> I would leave this up to the maintainer. Depends on how much |
79 |
>> time backporting takes. |
80 |
> |
81 |
> After reading your answers I don't understand why the bug is still |
82 |
> opened and what it is about. Arfrever told that he fells that it's |
83 |
> up to him how to version packages. And I agree with him in this |
84 |
> exact case. |
85 |
|
86 |
This is unfortunately the main issue here. You may work on a specific |
87 |
package on Gentoo, but when that package is essential for the system |
88 |
use / stability, it stops being just "your" package. This latest |
89 |
example has lead users to a point where their PM stopped working. |
90 |
Breaking the PM is not a small "oops" and doing it by continuously |
91 |
breaking our policies or ignoring one doesn't work alone, is a very |
92 |
serious offense. |
93 |
Should the toolchain team start providing "testing" gcc or glibc |
94 |
packages that have slight "oops" here and there that break systems? |
95 |
What about the kernel team deciding to mark stable some kernel |
96 |
versions with drivers that break hardware support without proper |
97 |
testing? Or what about the PERL team deciding they only care about the |
98 |
language and not the hundreds of packages that use it and start |
99 |
pushing new versions the day they're released no matter how many |
100 |
packages they break in the process? |
101 |
|
102 |
- -- |
103 |
Regards, |
104 |
|
105 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
106 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
107 |
-----BEGIN PGP SIGNATURE----- |
108 |
Version: GnuPG v2.0.16 (GNU/Linux) |
109 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
110 |
|
111 |
iQIcBAEBAgAGBQJMWTXuAAoJEC8ZTXQF1qEPp3EQAMfpoiEuXuPN8sWF1ZFG27M4 |
112 |
yvZC2ZLRfnp1mK8adT8LewkoVgBh4Plmyc0kaNZKBOMRUtIDZ1uun3lFJr6SbLwH |
113 |
i8E5OSSsotWubuo3iSYVaP1tefOxx6GtJqly86uIYbrFZE1HVsJ2j0DrL3pkO+b6 |
114 |
PMLi0mof4a3iVNhzNWiA0t9sETvzevYHHOgVg2c609w73oQBVDQnnyH0f7Il0Q3p |
115 |
9GjylllHXLEYuw9Fn4vtqKfTwgnhOBGfGHG+GSWBcU1rAhImwGzQOVoUBpPSpXHS |
116 |
gR5Pf+lhO5yYc6eCruCSfhkZjYoa3Zl9UW+ulu4zpNJQwvZo9qpoGyAehZ+uKHgU |
117 |
UgJPF4haQHZcJKGJjvMLI5hsSXbIAUKyDmLcm+2cIDj65WhePn4GoCZHzeRfOyTk |
118 |
/86vYW+gB0YcG7yThhkF8TBGimkaWAcWI69FEgRa/BPMMjGpc0JMQcbvSZjVL8jI |
119 |
Y1V9/qt3mqtYvNpNnHAXllb5nH7UwLNldSEqlHZ1wUGfU77/0w1BEJ9m4fulUm1u |
120 |
Bi/YmU4PcRiBzmDwnPsNtNckBNpPwVM9h4uAyC5g4sWefRc9RdOpZR0+ADD959hn |
121 |
DU1+LJn/mEC9Wr/AHV+8FtJaDcYUALbd/MyrWoOl/IFcEg5j+hZkktPuMXRdJOhU |
122 |
pMlw72B+TmyFJFF3gQ7P |
123 |
=Inrp |
124 |
-----END PGP SIGNATURE----- |