summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-June/005977.html
blob: 9b10f96ef28561f7bd67fc8e2c0c04d8c75ebcc9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-dev] Backports policy proposal
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1308874214.22020.164.camel%40akroma.ephaone.org%3E">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="006091.html">
   <LINK REL="Next"  HREF="005981.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] Backports policy proposal</H1>
    <B>Michael Scherer</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1308874214.22020.164.camel%40akroma.ephaone.org%3E"
       TITLE="[Mageia-dev] Backports policy proposal">misc at zarb.org
       </A><BR>
    <I>Fri Jun 24 02:10:14 CEST 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="006091.html">[Mageia-dev] Proposal of a backporting process
</A></li>
        <LI>Next message: <A HREF="005981.html">[Mageia-dev] Backports policy proposal
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#5977">[ date ]</a>
              <a href="thread.html#5977">[ thread ]</a>
              <a href="subject.html#5977">[ subject ]</a>
              <a href="author.html#5977">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Hi,

as said, this is the 2nd mail of the 3 mails about handling backports.
It is about backport policy, ie what we update, and what we don't, with
a set of criteria, to make sure we fullfill our goals.

I will start by the fact we can all agree that we want to have a
breakage-free experience. One of the value of the project is the
quality, and traditionally, the best way to not break something is to
have minimal changes.
Yet, people have asked for newer version of packages, and people are ok
to trade a little bit of change and little bit of risk for new software,
and we have offered that in the past at Mandriva with some success.

Experience have showed that people care mostly about applications rather
than low level library and modules. Experience have also show that
people are not sure about backport, and that we should make sure
everything work fine so we can have more people that use them.

The Mandriva policy was rather good, and I think we can also all agree
there is packages that can clearly not be backportable without either
lots of QA, or without rebuilding lots of stuff :
- glibc, python, perl, xorg, etc

I would also say that the maintainer can also say that he doesn't want
the rpm be backported, either because he think that's not ready, or
because he think it should not be done. I think this will not happen
often, but for the rare case a problem would arise, the maintainer
should have the last word.

On the other hand, there is packages that can be backported without
impacting much :
- leaf packages ( those that nothing requires ), 
- packages not present in the distribution ( provided it doesn't
obsolete or provides stuff that would impact the distribution, like
backporting a new jvm with a obsolete on the current one ).

So for a start, I would suggest to use the same policy as Mandriva
( <A HREF="http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy">http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy</A> ).

Ie, only create a backport for rpm  that cannot have a negative impact
( leaf packages, newer one ), and then revise the policy in one year
based on request that were refused, to see if we can find something to
change.


I would also propose a few rules :

&quot;a package should have been in cauldron since 1 week before being
backported&quot;, so we can at least ensure there was a minimal test on it,
Ie, if I package stuff-virtual-manager, I cannot backport it before 1
week. If we have a package of stuff-virtual-manager since 1 month, and
that I update a new version, then I can backport. The idea is that a
newer packages may suffer from more bug than older one.


Another rule that we could add is that cauldron should always be newer
than backports, in order to ensure upgradability. The same goes for n-2
and n-1 release.
While this seems innocent, do not forget this will have a impact when we
do the version freeze.


Something that was discussed previously, we should make sure that
backport can be cherrypicked. If I backport trac, I will need to place
stricted Requires from subpackages on the main package and so on, in
order to ensure no mix of rpm. And since we plan to backport only leaf
packages, this would not affect others packages. However, this will have
a impact on the next issue, updates.

so :
- cannot be backported if this is not a leaf package, will be revised
later
- cannot be backported if the maintainer say &quot;no&quot;, but we assume he say
&quot;yes&quot; by default
- cannot be backported if it impact the dependency tree too much
( Obsoletes, Provides, etc )
- cannot be backported if the package was just created and is thus
basically untested in cauldron

- must not prevent upgrade to next release 

- strict requires between backported packages, in order to make sure
they can be cherrypicked ( ie, someone enable backports, install, remove
backports )

You can comment ( do not forget to trim the answer , and please keep
this on topic, that's why I did 3 mails ).

-- 
Michael Scherer

</PRE>












































<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="006091.html">[Mageia-dev] Proposal of a backporting process
</A></li>
	<LI>Next message: <A HREF="005981.html">[Mageia-dev] Backports policy proposal
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#5977">[ date ]</a>
              <a href="thread.html#5977">[ thread ]</a>
              <a href="subject.html#5977">[ subject ]</a>
              <a href="author.html#5977">[ author ]</a>
         </LI>
       </UL>

<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>