[gentoo-dev] Moving unmaintained packages to Sunrise

[gentoo-dev] Moving unmaintained packages to Sunrise

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

Hello,

There are some packages which were 'readded' to the Sunrise overlay
after lying unmaintained in the tree for a long time and finally being
removed. One example could be net-im/ekg2 for removal of which I've been
personally waiting.

Although such a workflow 'works' indeed, for most of the users packages
are just removed. Even if they use Sunrise, the delay of few days
required in order to get the new ebuild rewritten and reviewed causes
them to remove and forget about the package. And in fact, gx86 states
it was 'removed'.

Currently, the Sunrise policy states that there could be added only
packages which are maintainer-wanted and thus not in gx86. For
maintainer-needed, there is a proxy-commit mechanism but it's a little
awkward, especially if the new ebuild is supposed to be written from
scratch (like ekg2 one was).

Wouldn't it be better to officially support moving unmaintained
packages directly into Sunrise? In this case by 'unmaintained' I mean
those which have open bugs assigned to 'maintainer-needed' for a long
time, and are potentially a candidates for the treecleaning (not
necessarily being in the removal queue yet).

The particular Sunrise user wanting to maintain the package suggests
moving it to Sunrise (to whom?). If developers agree on that, he is
allowed to prepare the Sunrise ebuild and even commit it to the
'sunrise' (non-public) tree.

When Sunrise dev does the final review, after which the package would
be moved to 'reviewed' (public) tree, he/she also masks the original
package in gx86 stating that the package is now maintained in Sunrise.
After 30 (or more) days, the masked gx86 packages are removed as usual.

The advantage of such a workflow is quite obvious -- instead of seeing
'removed' packages which they need to either copy to their own overlay
or abandon, users are advised to add 'sunrise' to their repository list
and use the user-maintained ebuild. And then the move is almost
transparent to current Sunrise users.

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Moving unmaintained packages to Sunrise

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On 06/13/2010 10:41 AM, Michał Górny wrote:
> Wouldn't it be better to officially support moving unmaintained
> packages directly into Sunrise? In this case by 'unmaintained' I mean
> those which have open bugs assigned to 'maintainer-needed' for a long
> time, and are potentially a candidates for the treecleaning (not
> necessarily being in the removal queue yet).

What's stopping you or any of the sunrise guys to pick up packages when
treecleaners send the last rites? You have 30 days minimum, to get a new
ebuild rolling before it gets the axe. Sounds like plenty of time to me.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Duncan]

Michał Górny posted on Sun, 13 Jun 2010 10:41:43 +0200 as excerpted:

> Wouldn't it be better to officially support moving unmaintained packages
> directly into Sunrise?

++

I've thought something like that was needed for awhile, tho I'm not sure 
it fits the sunrise theme too well.  But if not there, surely somewhere, 
and I see no reason to fragment overlays just for that, so sunrise is 
good. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

If you start moving maintainer-needed package on Sunrise then Sunrise will
end up as a garbage collector overlay having many many ebuilds that nobody
will actually maintain. If you care about maintainer-needed package then
step up and proxy maintain it. The delay ( which is not that big if you
cooperate with an active developer/herd ) might be a drawback but still... I
don't want sunrise to become a place where abandoned ebuilds will end up.

On Sun, Jun 13, 2010 at 1:38 PM, Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Sun, 13 Jun 2010 10:41:43 +0200 as excerpted:
>
> > Wouldn't it be better to officially support moving unmaintained packages
> > directly into Sunrise?
>
> ++
>
> I've thought something like that was needed for awhile, tho I'm not sure
> it fits the sunrise theme too well.  But if not there, surely somewhere,
> and I see no reason to fragment overlays just for that, so sunrise is
> good. =:^)
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

[-- Attachment #2: Type: text/html, Size: 1512 bytes --]

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Rémi Cardona]

Le 13/06/2010 14:07, Markos Chandras a écrit :
> If you start moving maintainer-needed package on Sunrise then Sunrise
> will end up as a garbage collector overlay having many many ebuilds that
> nobody will actually maintain. If you care about maintainer-needed
> package then step up and proxy maintain it. The delay ( which is not
> that big if you cooperate with an active developer/herd ) might be a
> drawback but still... I don't want sunrise to become a place where
> abandoned ebuilds will end up. 

+1, unmaintained ebuilds should just go away. We have to stop pretending
to maintain an ebuild when no one does.

Besides, everything we have is either in CVS or subversion, so nothing
is lost.

If anything, we should be advertising where deleted ebuilds are and how
users can revive them if they want them.

Cheers,

Rémi

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Sun, 13 Jun 2010 15:07:12 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:

> If you start moving maintainer-needed package on Sunrise then Sunrise
> will end up as a garbage collector overlay having many many ebuilds
> that nobody will actually maintain. If you care about
> maintainer-needed package then step up and proxy maintain it. The
> delay ( which is not that big if you cooperate with an active
> developer/herd ) might be a drawback but still... I don't want
> sunrise to become a place where abandoned ebuilds will end up.

But who's talking here about moving abandoned ebuilds just to keep
them? I'd wanted just to make it simpler to switch the 'maintainership'
from Gentoo devs to Sunrise users, when the second are ready to
maintain the ebuild well.

You may take a look at Sunrise net-im/ekg2 ebuild as an example. It has
probably almost nothing in common with the original ebuild. It even uses
an alternate build system, allows to fine-tune the build like not many
packages do. Do you consider that an 'abandoned ebuild'?

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

We ( as treecleaners ) can't move the packages to sunrise. If there are
users out there who want to maintain them either move the ebuilds on sunrise
themselves or proxy maintain them.

On Sun, Jun 13, 2010 at 7:35 PM, Michał Górny <gentoo@mgorny.alt.pl> wrote:

> On Sun, 13 Jun 2010 15:07:12 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
>
> > If you start moving maintainer-needed package on Sunrise then Sunrise
> > will end up as a garbage collector overlay having many many ebuilds
> > that nobody will actually maintain. If you care about
> > maintainer-needed package then step up and proxy maintain it. The
> > delay ( which is not that big if you cooperate with an active
> > developer/herd ) might be a drawback but still... I don't want
> > sunrise to become a place where abandoned ebuilds will end up.
>
> But who's talking here about moving abandoned ebuilds just to keep
> them? I'd wanted just to make it simpler to switch the 'maintainership'
> from Gentoo devs to Sunrise users, when the second are ready to
> maintain the ebuild well.
>
> You may take a look at Sunrise net-im/ekg2 ebuild as an example. It has
> probably almost nothing in common with the original ebuild. It even uses
> an alternate build system, allows to fine-tune the build like not many
> packages do. Do you consider that an 'abandoned ebuild'?
>
> --
> Best regards,
> Michał Górny
>
> <http://mgorny.alt.pl>
> <xmpp:mgorny@jabber.ru <xmpp%3Amgorny@jabber.ru>>
>

[-- Attachment #2: Type: text/html, Size: 2035 bytes --]

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On 6/13/10 6:35 PM, Michał Górny wrote:
> But who's talking here about moving abandoned ebuilds just to keep
> them? I'd wanted just to make it simpler to switch the 'maintainership'
> from Gentoo devs to Sunrise users, when the second are ready to
> maintain the ebuild well.

Can you suggest a specific plan or process how to do that?

Please don't go into discussion "no, the devs should do that" vs "no,
the users should do that".

Currently it seems the users can take the "last-rited" ebuilds and get
them into sunrise. They can step up as proxy maintainers and prevent the
package from getting tree-cleaned.

There are many options, which can be used right now and have existed for
months.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Moving unmaintained packages to Sunrise

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-06-2010 08:41, Michał Górny wrote:
> Hello,
> 
> There are some packages which were 'readded' to the Sunrise overlay
> after lying unmaintained in the tree for a long time and finally being
> removed. One example could be net-im/ekg2 for removal of which I've been
> personally waiting.
> 
> Although such a workflow 'works' indeed, for most of the users packages
> are just removed. Even if they use Sunrise, the delay of few days
> required in order to get the new ebuild rewritten and reviewed causes
> them to remove and forget about the package. And in fact, gx86 states
> it was 'removed'.
> 
> Currently, the Sunrise policy states that there could be added only
> packages which are maintainer-wanted and thus not in gx86. For
> maintainer-needed, there is a proxy-commit mechanism but it's a little
> awkward, especially if the new ebuild is supposed to be written from
> scratch (like ekg2 one was).
> 
> Wouldn't it be better to officially support moving unmaintained
> packages directly into Sunrise? In this case by 'unmaintained' I mean
> those which have open bugs assigned to 'maintainer-needed' for a long
> time, and are potentially a candidates for the treecleaning (not
> necessarily being in the removal queue yet).

I think you might not have been around at that time, but when the
sunrise overlay was created, there was a proposal to create a sunset
overlay, like the java team used and now kde uses as well.
The purpose of this overlay would be to keep the packages that are
removed from the tree because they have no maintainers.
As was discussed back then, the people wishing to work on sunrise are
likely not interested in having all the removed packages dumped in their
shoulders. Besides, sunrise is about packages that have an interested
user submitting and hopefully maintaining ebuilds for new packages,
while sunset is likely to become a dumping ground for stuff that we
can't find anyone to take care of.
If we want to find a way to not drop the maintainer-needed packages, I'd
prefer we move them to sunset and not to sunrise. As this overlay is
likely to become large, probably "huge", and as it will host security
vulnerable packages, we should evaluate whether we really want to host
it and, if so, what measures to take to protect "distracted users". I
think package masking all the packages put there with links to relevant
bugs might be a first step.

> The particular Sunrise user wanting to maintain the package suggests
> moving it to Sunrise (to whom?). If developers agree on that, he is
> allowed to prepare the Sunrise ebuild and even commit it to the
> 'sunrise' (non-public) tree.
> 
> When Sunrise dev does the final review, after which the package would
> be moved to 'reviewed' (public) tree, he/she also masks the original
> package in gx86 stating that the package is now maintained in Sunrise.
> After 30 (or more) days, the masked gx86 packages are removed as usual.
> 
> The advantage of such a workflow is quite obvious -- instead of seeing
> 'removed' packages which they need to either copy to their own overlay
> or abandon, users are advised to add 'sunrise' to their repository list
> and use the user-maintained ebuild. And then the move is almost
> transparent to current Sunrise users.

The problem with the above is exposing users to potentially "dangerous"
applications - from a security perspective.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMFOqSAAoJEC8ZTXQF1qEPVh0QAKT38JEDUHY4neIhQ44m5aeL
sqZIfIULeVY4Xh5EaGJ/kS1cLyFuy+QXU2y/NLFWT7+DD9vPZiUGx/z90ph6irVC
YURd9scd4SdDKJKv2vp56A0USPXfRqRxok6l1m2HvZaqMoV+WN9Y+WQ/wxcu69Ce
2hDUikABMwAazjA5GotfC7Wa5Aadk6+6fYVSMiCZAtpD35rq+9yLJ8wJFr0YQq50
1Cj/B2vyA90uXRG/wfWhetU+sOLsOoF0yGoINHMzRon6J8SgQr+5mLsQYL1JhcsK
yNem0omoBB0qio4kihxT5L11n8rK2nesLr+ay93udfPc/0hHy6J6rK+ZCW5alG1r
fARHgKcdU+HPwXKp2xhAJyo/ooHZFN32DhEfEE6RF5M2KS4wq2kNhLnh0mnMRjtV
GhH3TWC8DFuMwZDFwYZs99G1biCmc4jaw7xyAx9Q3c60vB0UGeVPlCb73CwuE3we
5YHuEyG2TY7Xju7wGm/KLte70FUK+MynJL+yaF4fkxkVz7YzOSTMcEv9YgvWJ3kF
aa1U1B6TQxEqqR2w734SNB3dE/BMyrWXvJ8WMfw63NpDRfkEVmC9ogarLvOtEjQ0
GQ9Id7hx85B+1+8LsKwrHJu09cEDsB7k0+l2AFGJ8llWX8ptBeYhZfLzhPzYllhB
DEUzrXPW7/AyrLwpyU8j
=7Q9z
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Duncan]

Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 +0000 as
excerpted:

> there was a proposal to create a sunset overlay, like the java team used
> and now kde uses as well. The purpose of this overlay would be to keep
> the packages that are removed from the tree because they have no
> maintainers. As was discussed back then, the people wishing to work on
> sunrise are likely not interested in having all the removed packages
> dumped in their shoulders. Besides, sunrise is about packages that have
> an interested user submitting and hopefully maintaining ebuilds for new
> packages, while sunset is likely to become a dumping ground for stuff
> that we can't find anyone to take care of. If we want to find a way to
> not drop the maintainer-needed packages, I'd prefer we move them to
> sunset and not to sunrise. As this overlay is likely to become large,
> probably "huge", and as it will host security vulnerable packages, we
> should evaluate whether we really want to host it and, if so, what
> measures to take to protect "distracted users". I think package masking
> all the packages put there with links to relevant bugs might be a first
> step.

You obviously read the proposal differently than I did.  MG can pop in and 
say what he intended, but as I read it, and why I said "++", is...

We change the policy of sunrise, not to be a dumping ground for /all/ tree-
cleaned packages, but to allow interested users who see that a package 
they're interested in is unmaintained, to add it to (the unpublic part of) 
sunrise before the package is removed and potentially before it's even 
masked for removal, such that it can be approved and ready to "go public" 
in sunrise at the same time it's removed (or even when masked for removal) 
from the main tree.

So packages wouldn't be dumped there without a maintainer.  The only ones 
that would qualify would be those where a user actively proposes to 
maintain them in sunrise, the idea being that in some instances (as with 
the posted example), they can be maintained better there than they can be 
proxy-maintained in-tree.

Apparently, sunrise has been around long enough, now, that there has been 
at least one package that started in sunrise, was added to the tree, then 
the person who added it lost interest or retired... and now it's rotting 
in the tree, and the same user that put it in sunrise before is still 
interested in it and has updated ebuilds, etc, but can't easily get 
proxies to commit the new ebuilds to the tree.  From my read, that was 
apparently what sparked the post and whole proposed change.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]

Am 13.06.2010 22:36, schrieb Duncan:
> Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 +0000 as
> excerpted:
> 
>> there was a proposal to create a sunset overlay, like the java team used
>> and now kde uses as well. The purpose of this overlay would be to keep
>> the packages that are removed from the tree because they have no
>> maintainers. As was discussed back then, the people wishing to work on
>> sunrise are likely not interested in having all the removed packages
>> dumped in their shoulders. Besides, sunrise is about packages that have
>> an interested user submitting and hopefully maintaining ebuilds for new
>> packages, while sunset is likely to become a dumping ground for stuff
>> that we can't find anyone to take care of. If we want to find a way to
>> not drop the maintainer-needed packages, I'd prefer we move them to
>> sunset and not to sunrise. As this overlay is likely to become large,
>> probably "huge", and as it will host security vulnerable packages, we
>> should evaluate whether we really want to host it and, if so, what
>> measures to take to protect "distracted users". I think package masking
>> all the packages put there with links to relevant bugs might be a first
>> step.
> 
> You obviously read the proposal differently than I did.  MG can pop in and 
> say what he intended, but as I read it, and why I said "++", is...
> 
> We change the policy of sunrise, not to be a dumping ground for /all/ tree-
> cleaned packages, but to allow interested users who see that a package 
> they're interested in is unmaintained, to add it to (the unpublic part of) 
> sunrise before the package is removed and potentially before it's even 
> masked for removal, such that it can be approved and ready to "go public" 
> in sunrise at the same time it's removed (or even when masked for removal) 
> from the main tree.
> 
> So packages wouldn't be dumped there without a maintainer.  The only ones 
> that would qualify would be those where a user actively proposes to 
> maintain them in sunrise, the idea being that in some instances (as with 
> the posted example), they can be maintained better there than they can be 
> proxy-maintained in-tree.
> 
> Apparently, sunrise has been around long enough, now, that there has been 
> at least one package that started in sunrise, was added to the tree, then 
> the person who added it lost interest or retired... and now it's rotting 
> in the tree, and the same user that put it in sunrise before is still 
> interested in it and has updated ebuilds, etc, but can't easily get 
> proxies to commit the new ebuilds to the tree.  From my read, that was 
> apparently what sparked the post and whole proposed change.
> 

I think, your proposed way is already possible. The policy of sunrise is only to not dublicate
packages in main tree. If they will surely be dropped and this fact can be seen in public, e.g.
because of the announcement and mask, i have no problems with users joining #gentoo-sunrise and
maintaining that package in sunrise overlay.

You should just remember, that those, who want to add the unmaintained package to sunrise, should
also plan to maintain it there, sunrise will not become a place to move broken packages to ;-)

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Moving unmaintained packages to Sunrise

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On 06/13/2010 05:26 PM, Jorge Manuel B. S. Vicetto wrote:

> 
>> Wouldn't it be better to officially support moving unmaintained
>> packages directly into Sunrise? In this case by 'unmaintained' I mean
>> those which have open bugs assigned to 'maintainer-needed' for a long
>> time, and are potentially a candidates for the treecleaning (not
>> necessarily being in the removal queue yet).
> 
> I think you might not have been around at that time, but when the
> sunrise overlay was created, there was a proposal to create a sunset
> overlay, like the java team used and now kde uses as well.

We (java) still use it and call it junkyard. That's an adequate
description for the quality of the overlay.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Moving unmaintained packages to Sunrise

[Sebastian Pipping]

On 06/13/10 16:26, Jorge Manuel B. S. Vicetto wrote:
> If we want to find a way to not drop the maintainer-needed packages, I'd
> prefer we move them to sunset and not to sunrise.

Agreed.

If there is a user-maintainer move to sunrise, if there isn't move to
sunset.


> As this overlay is
> likely to become large, probably "huge", and as it will host security
> vulnerable packages, we should evaluate whether we really want to host
> it and, if so, what measures to take to protect "distracted users". I
> think package masking all the packages put there with links to relevant
> bugs might be a first step.

We introduced a "graveyard" quality level to layman recently that allows
for marking such repositories (and a split tree in the future).
Quoting the current repositories.dtd:

  [..]
  quality (core|stable|testing|experimental|graveyard) #REQUIRED
  [..]

So Layman can be made handling such a repo specially, say displaying
certain warnings.



Sebastian