1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 13-06-2010 08:41, Michał Górny wrote: |
5 |
> Hello, |
6 |
> |
7 |
> There are some packages which were 'readded' to the Sunrise overlay |
8 |
> after lying unmaintained in the tree for a long time and finally being |
9 |
> removed. One example could be net-im/ekg2 for removal of which I've been |
10 |
> personally waiting. |
11 |
> |
12 |
> Although such a workflow 'works' indeed, for most of the users packages |
13 |
> are just removed. Even if they use Sunrise, the delay of few days |
14 |
> required in order to get the new ebuild rewritten and reviewed causes |
15 |
> them to remove and forget about the package. And in fact, gx86 states |
16 |
> it was 'removed'. |
17 |
> |
18 |
> Currently, the Sunrise policy states that there could be added only |
19 |
> packages which are maintainer-wanted and thus not in gx86. For |
20 |
> maintainer-needed, there is a proxy-commit mechanism but it's a little |
21 |
> awkward, especially if the new ebuild is supposed to be written from |
22 |
> scratch (like ekg2 one was). |
23 |
> |
24 |
> Wouldn't it be better to officially support moving unmaintained |
25 |
> packages directly into Sunrise? In this case by 'unmaintained' I mean |
26 |
> those which have open bugs assigned to 'maintainer-needed' for a long |
27 |
> time, and are potentially a candidates for the treecleaning (not |
28 |
> necessarily being in the removal queue yet). |
29 |
|
30 |
I think you might not have been around at that time, but when the |
31 |
sunrise overlay was created, there was a proposal to create a sunset |
32 |
overlay, like the java team used and now kde uses as well. |
33 |
The purpose of this overlay would be to keep the packages that are |
34 |
removed from the tree because they have no maintainers. |
35 |
As was discussed back then, the people wishing to work on sunrise are |
36 |
likely not interested in having all the removed packages dumped in their |
37 |
shoulders. Besides, sunrise is about packages that have an interested |
38 |
user submitting and hopefully maintaining ebuilds for new packages, |
39 |
while sunset is likely to become a dumping ground for stuff that we |
40 |
can't find anyone to take care of. |
41 |
If we want to find a way to not drop the maintainer-needed packages, I'd |
42 |
prefer we move them to sunset and not to sunrise. As this overlay is |
43 |
likely to become large, probably "huge", and as it will host security |
44 |
vulnerable packages, we should evaluate whether we really want to host |
45 |
it and, if so, what measures to take to protect "distracted users". I |
46 |
think package masking all the packages put there with links to relevant |
47 |
bugs might be a first step. |
48 |
|
49 |
> The particular Sunrise user wanting to maintain the package suggests |
50 |
> moving it to Sunrise (to whom?). If developers agree on that, he is |
51 |
> allowed to prepare the Sunrise ebuild and even commit it to the |
52 |
> 'sunrise' (non-public) tree. |
53 |
> |
54 |
> When Sunrise dev does the final review, after which the package would |
55 |
> be moved to 'reviewed' (public) tree, he/she also masks the original |
56 |
> package in gx86 stating that the package is now maintained in Sunrise. |
57 |
> After 30 (or more) days, the masked gx86 packages are removed as usual. |
58 |
> |
59 |
> The advantage of such a workflow is quite obvious -- instead of seeing |
60 |
> 'removed' packages which they need to either copy to their own overlay |
61 |
> or abandon, users are advised to add 'sunrise' to their repository list |
62 |
> and use the user-maintained ebuild. And then the move is almost |
63 |
> transparent to current Sunrise users. |
64 |
|
65 |
The problem with the above is exposing users to potentially "dangerous" |
66 |
applications - from a security perspective. |
67 |
|
68 |
- -- |
69 |
Regards, |
70 |
|
71 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
72 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
73 |
-----BEGIN PGP SIGNATURE----- |
74 |
Version: GnuPG v2.0.15 (GNU/Linux) |
75 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
76 |
|
77 |
iQIcBAEBAgAGBQJMFOqSAAoJEC8ZTXQF1qEPVh0QAKT38JEDUHY4neIhQ44m5aeL |
78 |
sqZIfIULeVY4Xh5EaGJ/kS1cLyFuy+QXU2y/NLFWT7+DD9vPZiUGx/z90ph6irVC |
79 |
YURd9scd4SdDKJKv2vp56A0USPXfRqRxok6l1m2HvZaqMoV+WN9Y+WQ/wxcu69Ce |
80 |
2hDUikABMwAazjA5GotfC7Wa5Aadk6+6fYVSMiCZAtpD35rq+9yLJ8wJFr0YQq50 |
81 |
1Cj/B2vyA90uXRG/wfWhetU+sOLsOoF0yGoINHMzRon6J8SgQr+5mLsQYL1JhcsK |
82 |
yNem0omoBB0qio4kihxT5L11n8rK2nesLr+ay93udfPc/0hHy6J6rK+ZCW5alG1r |
83 |
fARHgKcdU+HPwXKp2xhAJyo/ooHZFN32DhEfEE6RF5M2KS4wq2kNhLnh0mnMRjtV |
84 |
GhH3TWC8DFuMwZDFwYZs99G1biCmc4jaw7xyAx9Q3c60vB0UGeVPlCb73CwuE3we |
85 |
5YHuEyG2TY7Xju7wGm/KLte70FUK+MynJL+yaF4fkxkVz7YzOSTMcEv9YgvWJ3kF |
86 |
aa1U1B6TQxEqqR2w734SNB3dE/BMyrWXvJ8WMfw63NpDRfkEVmC9ogarLvOtEjQ0 |
87 |
GQ9Id7hx85B+1+8LsKwrHJu09cEDsB7k0+l2AFGJ8llWX8ptBeYhZfLzhPzYllhB |
88 |
DEUzrXPW7/AyrLwpyU8j |
89 |
=7Q9z |
90 |
-----END PGP SIGNATURE----- |