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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] RFC: Opening Backports (once again...)
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20Opening%20Backports%20%28once%20again...%29&In-Reply-To=%3C201112111711.52603.alien%40rmail.be%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="010350.html">
<LINK REL="Next" HREF="010365.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] RFC: Opening Backports (once again...)</H1>
<B>Maarten Vanraes</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20Opening%20Backports%20%28once%20again...%29&In-Reply-To=%3C201112111711.52603.alien%40rmail.be%3E"
TITLE="[Mageia-dev] RFC: Opening Backports (once again...)">alien at rmail.be
</A><BR>
<I>Sun Dec 11 17:11:52 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="010350.html">[Mageia-dev] RFC: Opening Backports (once again...)
</A></li>
<LI>Next message: <A HREF="010365.html">[Mageia-dev] RFC: Opening Backports (once again...)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#10363">[ date ]</a>
<a href="thread.html#10363">[ thread ]</a>
<a href="subject.html#10363">[ subject ]</a>
<a href="author.html#10363">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Op zondag 11 december 2011 11:41:02 schreef Angelo Naselli:
><i> sabato 10 dicembre 2011 alle 17:09, Thomas Backlund ha scritto:
</I>><i> > Sorry, buth this wont work in reality...
</I>><i> >
</I>><i> > Consider this:
</I>><i> >
</I>><i> > version X in Mageia 1
</I>><i> > version X+1 in Cauldron
</I>><i> >
</I>><i> > version X+1 gets backported.
</I>><i> >
</I>><i> > version X+2 uploaded in Cauldron
</I>><i> > version X+2 cant be backported (depends on updated libs/packages in
</I>><i> > Cauldron, and we dont backport libs that can break working setups)
</I>><i> >
</I>><i> > version X+1 in backports need to be fixed (security/maintenance fix)
</I>><i> > (here your logic breaks down, there is no place to fix it)
</I>><i> >
</I>><i> >
</I>><i> > And since we aim for quality backports, the maintainer may want to
</I>><i> > stay with version X+1 in backports even if X+2 could be backported
</I>><i> > if maintainer think X+2 isn't a good candidate for some reason.
</I>><i>
</I>><i> So, couldn't we consider backports in the same way as updates?
</I>><i> The only difference is that they go into another branch, and they
</I>><i> need to have a higher version than in updates and lower than cauldron.
</I>><i>
</I>><i> Tests and validations follow the same rules, if a backport is not
</I>><i> validated won't be pushed.
</I>><i> Is that more work for QA? unfortunately yes, but i do hope tests
</I>><i> and validations can be done by more users interested in that
</I>><i> update/backport.
</I>><i>
</I>><i> Why using backports instead of updates then? because for some reasons
</I>><i> we -or maintainers- don't want to push as update a new version.
</I>><i> I'm not really in favour of a strict release update, we have already
</I>><i> pacakges not doing that (leaf ones, or those that are a pain to patch like
</I>><i> ff for instance,...).
</I>><i> In such a way backports is not going to be seen as a potential breakage of
</I>><i> the system, but as a part of distro life.
</I>><i>
</I>><i> A problem i can see though is if a maintainer decides that a version
</I>><i> that has been backported can become an update, even if it can be
</I>><i> managed by working on release version, that update is svn and HD room
</I>><i> effect...
</I>><i>
</I>><i> Angelo
</I>
you can have new version as updates.
backporting is the addition of new features and thus the possibility of new
bugs, even with QA, you can't completely get the same level of stability from
updates, as you get from backports...
but that's fine. it doesn't need to be, it's not enabled by default, it'd be
nice if those work well.
what we really want is for backports to be suggested in rpmdrake on a case by
case basis.
since fixing bugs is more important that adding new features and some people do
updates, but don't want any risk, it's completely valid that they are
separate.
i just vote that we make a svn backports branch, (NOT a separate repos, it'd
be nice if we can just branch it, which doesn't use any extra disk space), for
some packages it means we can add a patch on backports to make it work for
mga1 specifically and still merge patches from cauldron into backports if we
want (or wherever we branch from)
we should however keep matches close at a hand, in case people do weird
things, some automated checks could be done and possibly mailed somewhere to
show that suspicious activity is going on... if it's tmb, we know we can
ignore it then.
i think this is by far the most flexible solution, and we should try to keep
our level of maintainers high, but informing them of where it can go wrong,
what they should look for...
just my 0.02€
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="010350.html">[Mageia-dev] RFC: Opening Backports (once again...)
</A></li>
<LI>Next message: <A HREF="010365.html">[Mageia-dev] RFC: Opening Backports (once again...)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#10363">[ date ]</a>
<a href="thread.html#10363">[ thread ]</a>
<a href="subject.html#10363">[ subject ]</a>
<a href="author.html#10363">[ 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>
|
