Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
John Brooks wrote: Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. No need for an additional mail/bugzie alias here, we could simply use a KEYWORD like the existing 'Inclusion' (which isn't used that much for now, 63 open bugs have that keyword) or a new 'HasPatch' as a counterpart for 'NeedPatch'. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
On Mon, Aug 18, 2008 at 5:12 PM, Tobias Scherbaum [EMAIL PROTECTED] wrote: John Brooks wrote: Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. No need for an additional mail/bugzie alias here, we could simply use a KEYWORD like the existing 'Inclusion' (which isn't used that much for now, 63 open bugs have that keyword) or a new 'HasPatch' as a counterpart for 'NeedPatch'. (This email isn't targeted towards Tobias - just replying) What is wrong with the KEYWORD called 'EBUILD' defined as: Marks an issue to be a user submitted ebuild. ? You can easily make a search that is assigned to maintainer-needed and has the EBUILD keyword (or any keyword).[1] I feel like you guys are trying to solve issues related to an underlying problem but not actually targeting the problem itself. The main issue is a lack of man-power. Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. This would cut down on our current 247 maintainer-needed bugs[2] or our 35 bugs assigned to maintainer-needed with 'bump' in the summary[3]. However, keep in mind that we do have 497 bugs assigned to anyone with 'bump' in the summary[4]. Just some thoughts to ponder, Jeremy [1]: http://tinyurl.com/6y653y [2]: http://tinyurl.com/6olohq [3]: http://tinyurl.com/5d3tfl [4]: http://tinyurl.com/689y5p
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
Jeremy Olexa wrote: Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. My opinion is that packages should not be removed from the tree just because there is no assigned maintainer. Even moving a package to sunrise effectively makes it invisible to many users, and a great strength of Gentoo is that it has such a variety of packages in the tree. I do see that there are potential problems with unmaintained packages, so it is a good goal to try to solve that. Perhaps developers who have the time and choose to make themselves available to do simple version bumps on unmaintained packages could put themselves on a mailing list to receive such bug reports. Encouraging users to be proxy maintainers is a great idea too (as others have suggested). As a last resort, otherwise working packages could be masked as unmaintained, which is probably better than total removal (after all, they could still be useful to some users. -Joe
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
I agree that packages shouldn't be removed or moved because they have no active developer maintaining them - that is going to take the value of portage down quite a lot. Outdated packages do too, but not in quite the same way. I like the idea of a list or mailing list of developers willing to help update unmaintained packages, and if community submitted ebuilds were encouraged a bit more, the job would be pretty simple. Most of the times i've done version bumps myself have just involved changing the name and fixing up patches. I definitely like the idea of encouraging proxy maintainers, as I said before. Becoming a full developer is (from what i've seen externally) quite difficult and requires a lot of dedicated time, but the user community is much larger - and 100 people doing one ebuild each is going to work better than one person doing 100 ebuilds. As another interesting idea for encouraging proxy maintainence, once an easier/more developed system exists for that (such as the mailing list mentioned before), perhaps a notice should be added to unmaintained ebuilds mentioning that it has no active maintainer, to warn users that a newer version may be available (in which case they can file a bug, etc) and encourage those with the time and skills to take up some of the work on those ebuilds. I would be very willing to work on some ebuilds if it didn't involve chasing a trail of vaguely relevant developers down until one pays attention. :P I would think that masking them due to a lack of maintainence should be used only as a last resort - if a package is blocking other updates or is extremely out of date (unsupported by upstream / everything else). But in those situations, deleting might be a better idea anyway, because what purpose does it really serve? - John Brooks On Mon, Aug 18, 2008 at 5:35 PM, Joe Peterson [EMAIL PROTECTED] wrote: Jeremy Olexa wrote: Also, devs willing to maintain packages but then later retiring and leaving the packages in limbo. Maybe there should be some policy such as, when devs retire if no one else steps up to maintain the package, then it automatically gets moved to sunrise overlay and only maintained packages stay in the portage tree. My opinion is that packages should not be removed from the tree just because there is no assigned maintainer. Even moving a package to sunrise effectively makes it invisible to many users, and a great strength of Gentoo is that it has such a variety of packages in the tree. I do see that there are potential problems with unmaintained packages, so it is a good goal to try to solve that. Perhaps developers who have the time and choose to make themselves available to do simple version bumps on unmaintained packages could put themselves on a mailing list to receive such bug reports. Encouraging users to be proxy maintainers is a great idea too (as others have suggested). As a last resort, otherwise working packages could be masked as unmaintained, which is probably better than total removal (after all, they could still be useful to some users. -Joe
[gentoo-dev] Suggestion: remove app-office/borg from portage.
Hi, Borg hasn't been updated in portage for a while despite the fact that new versions were released over a year ago (see http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest app-office/borg gets removed from portage. Regards, Aniruddha
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
On Sat, 16 Aug 2008 09:17:10 +0200 Aniruddha [EMAIL PROTECTED] wrote: Borg hasn't been updated in portage for a while despite the fact that new versions were released over a year ago (see http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest app-office/borg gets removed from portage. Why not put together an ebuild for a recent version? If there are no major changes, an ebuild will probably get it updated quickly enough, in my experience. Rob.
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
On Sat, 2008-08-16 at 19:30 +0100, Robert Bridge wrote: On Sat, 16 Aug 2008 09:17:10 +0200 Aniruddha [EMAIL PROTECTED] wrote: Borg hasn't been updated in portage for a while despite the fact that new versions were released over a year ago (see http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest app-office/borg gets removed from portage. Why not put together an ebuild for a recent version? If there are no major changes, an ebuild will probably get it updated quickly enough, in my experience. Rob. I've filed the bugreport (version bump) a year ago. It looks like borg has no maintainer. Regards, Aniruddha
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
On Sat, 16 Aug 2008 18:42:35 +0200 Aniruddha [EMAIL PROTECTED] wrote: I've filed the bugreport (version bump) a year ago. It looks like borg has no maintainer. So maintain it. You don't need to be a dev to write an ebuild, and there are enough devs who are happy to throw an eye over user donated ebuilds and commit them to the tree... Removing a package from portage simply because no one has commited the up-to-date version you want is silly. If the only problem is no version bumping, provide the ebuild. Someone will commit it. I've done that for a few packages, it's not hard. I don't know anything about borg specifically, but as a user, I would not want to see packages being removed from portage just because the devs are too busy to write version bump ebuilds. Rob.
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
It can be somewhat difficult to find someone to look over and commit an ebuild on an unmaintained package though - the several times i've done that have involved tracking down developers with previous commits to the package or who are active in the category and trying to find one who isn't retired (I have good taste in packages, apparently - high turnover :P). On one, I had to talk to 7 different developers before I found someone willing and able to help. Just adding to the bug probably won't help unless it's assigned to someone - take a look at it's changelog (/usr/portage/category/package/Changelog) and try to get in touch with specific people if nobody responds to the tracker. Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. - John Brooks On Sat, Aug 16, 2008 at 2:18 PM, Robert Bridge [EMAIL PROTECTED] wrote: On Sat, 16 Aug 2008 18:42:35 +0200 Aniruddha [EMAIL PROTECTED] wrote: I've filed the bugreport (version bump) a year ago. It looks like borg has no maintainer. So maintain it. You don't need to be a dev to write an ebuild, and there are enough devs who are happy to throw an eye over user donated ebuilds and commit them to the tree... Removing a package from portage simply because no one has commited the up-to-date version you want is silly. If the only problem is no version bumping, provide the ebuild. Someone will commit it. I've done that for a few packages, it's not hard. I don't know anything about borg specifically, but as a user, I would not want to see packages being removed from portage just because the devs are too busy to write version bump ebuilds. Rob.
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Bridge wrote: On Sat, 16 Aug 2008 18:42:35 +0200 Aniruddha [EMAIL PROTECTED] wrote: I've filed the bugreport (version bump) a year ago. It looks like borg has no maintainer. So maintain it. You don't need to be a dev to write an ebuild, and there are enough devs who are happy to throw an eye over user donated ebuilds and commit them to the tree... And then there's the sunrise overlay [1]. Cheers, Arun [1] http://overlays.gentoo.org/proj/sunrise -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkinH2UACgkQ+Vqt1inD4uyUHQCfTtssO+sJ7DO3LB2acCvRoqAS znQAoI3eDIJQmDYcsoNfQNIQGHEIhUN6 =qewP -END PGP SIGNATURE-
