Re: [gentoo-dev] Proposed changes to how ebuilds are managed from newsletter.

[Mark Gordon]

On Tue, 29 Apr 2003 19:56:51 +0200
Henti Smith <bain@×××××××.za> wrote:

> here follows the proposal:
>
> In an effort to remedy at least part of this problem, Gentoo developer
> Dan Armak recently summarized and RFC'd a proposal for reorganizing
> how Gentoo Linux manages and maintains ebuilds within the Portage
> tree. The new proposal has four key features:
>
> * All ebuilds should, if at all possible, have at least one maintainer
> assigned to them. Major ebuilds, such as KDE, GNOME and XFree86 might
> have two or three
>   developers assigned to them. Realistically, only those ebuilds which
>   are complicated or otherwise unusual are likely to have their own
>   maintainers.
>
> * For the ebuilds that cannot have their own maintainer and are not
> complicated enough to require one, they will be organized into
> thematic groups. So, there might be a
>   "sound" category and a "video" category. Each themed group will have
>   one or more maintainers assigned to it who are responsible for
>   watching for newer upstream versions and bumping those ebuilds in
>   the testing branch of Portage.
>
> * These thematic groups are not intended to replace or even
> necessarily align with Portage categories. Portage categories are a
> user-side convenience designed to make
>   organizing packages easier. Themed groups of maintainers are a
>   developer-side convenience, designed to ensure complete coverage of
>   the Portage tree.
>
Since these categories don't align with the portage categories, I assume
the package will specify which category it belongs to in place of the
maintainer field?

> * Finally, if an ebuild is deemed to be complicated enough to need a
> dedicated maintainer, it will be listed as "unmaintained" and in need
> of a new owner. If it is not
>   picked up within a pre-determined amount of time, it will be masked
>   and later dropped from Portage. For those people familiar with
>   Debian Linux, this is similar to the method they use for their
>   package maintenance.

Sounds reasonable. If any of us users are sufficiently interested in
such a package we can always volunteer to take responsibility for it.

> Currently, this solution is in the draft stage and is subject to
> revision or even complete abandonment if a better solution comes
> along.
>
> This sounds good ... I do however have a few questions ..
>
> this proposal sounds good from the developers side .. but shows very
> little leeway for user contributed interaction which from reading many
> mails and discussions seems to be the real problem. The users
> contribute and it takes a long time for a responce. this system will
> make ebuild responcibility inside the development group easer to
> assign .. but if as was proposed, a package needs a dedicated
> developer .. and one does not rise to take it .. it gets dropped ..
> will this be regardless of user usage and contribution .. or will
> users that contribute to packages be "accepted" in to the development
> folds for ebuilds for that package?

Perhaps users should say if they are prepared to maintain a package when
they submit the ebuild, and if they are and no other developer is
interested they can be considered as a junior maintainer?

> I also think users can be used a lot better to do little things that
> developers needn't have to do .. but end up doing anyway, like looking
> for latest versions of packages already in the portage tree. This
> doesn't realy make sence for me since there is an existing ebuild that
> works and has passed the "to be allowed to portage" test, it should be
> easer for a user to take that ebuild .. bump the version and test it
> submit it and the "group"  / "dedicated" developer can test and fine
> tune if need be.
>
> Maybe be a little more clear on how users will interact with
> developers in the ebuild system will help since users are very keen on
> helping with ebuilds.

Perhaps also have a way for users to register that they are monitor a
package, so developers can decide to spend less time checking for
updates on packages where several users are also checking?
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.

--
gentoo-dev@g.o mailing list