public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Henti Smith <bain@tcsn.co.za>
To: gentoo-dev@gentoo.org <gentoo-dev@gentoo.org>
Subject: [gentoo-dev] Proposed changes to how ebuilds are managed from newsletter.
Date: Tue, 29 Apr 2003 19:56:51 +0200	[thread overview]
Message-ID: <20030429195651.04f5fee2.bain@tcsn.co.za> (raw)

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.

* 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.

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?

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.

Henti 

--
gentoo-dev@gentoo.org mailing list


             reply	other threads:[~2003-04-29 18:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-29 17:56 Henti Smith [this message]
2003-04-29 19:24 ` [gentoo-dev] Proposed changes to how ebuilds are managed from newsletter Mark Gordon
2003-04-30  0:52   ` George Shapovalov
2003-04-30  7:26     ` Mark Gordon
2003-05-09 11:49 ` Mark Bainter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030429195651.04f5fee2.bain@tcsn.co.za \
    --to=bain@tcsn.co.za \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox