Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
Am 13.06.2010 22:36, schrieb Duncan: Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 + 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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Moving unmaintained packages to Sunrise
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
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.dun...@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
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
On Sun, 13 Jun 2010 15:07:12 +0300 Markos Chandras hwoar...@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:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
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 gen...@mgorny.alt.pl wrote: On Sun, 13 Jun 2010 15:07:12 +0300 Markos Chandras hwoar...@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:mgo...@jabber.ru xmpp%3amgo...@jabber.ru
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
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ł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Moving unmaintained packages to Sunrise
Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 + 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
