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

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

[Henti Smith]

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

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@tcsn.co.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@gentoo.org mailing list

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

[George Shapovalov]

On Tuesday 29 April 2003 12:24, Mark Gordon wrote:
> > * These thematic groups are not intended to replace or even
> > necessarily align with Portage categories. Portage categories are a
[skipped]
> 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?
The implementation details have not been settled yet. Though it is quite 
likely that this information will be stored mostly server-side (probably with 
an option to query for it).

> > this proposal sounds good from the developers side .. but shows very
> > little leeway for user contributed interaction which from reading many
[skipped]
> 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?
Well, it is important to understand that this rerganization mostly concerns 
the developer side, as was pointed out in the text (and mentioned today by 
Dan Armak).
This has to settle first, before we will be able to proceed to implementing 
any user-side changes, as that clearly depends on inner organization. However 
the ideas of how to ease the ebuild processing are discussed as well. If you 
look at the featured dev section and follow the link to that bug ;) (I am 
talking about GWN, since this thread seem to have started off it, but just in 
case, that's #1523), you'll see such approach proposed. Parts of that has 
already made it into portage (KEYWORDS, gentoo-stats/stable, the latter ones 
are actually revamped to interoperate and scale better, but are nonetheless 
in function!).

> > 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
[skipped]
> > 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?
Yep, that's the idea. In fact large part of this user-dev interaction is going 
to be covered by the dev-side reorganization. As soon as the 
maintainer/developer/watcher positions are split and finalized we will start 
calling for users to fill in in the places where there is a shortage. As you 
can guess we cannot do this just now, before this stuff gets settled..

And thanks for the interest, this is what makes gentoo bettter!

George

--
gentoo-dev@gentoo.org mailing list

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

[Mark Gordon]

On Tue, 29 Apr 2003 17:52:15 -0700
George Shapovalov <george@gentoo.org> wrote:

<snip>

> Well, it is important to understand that this rerganization mostly
> concerns the developer side, as was pointed out in the text (and
> mentioned today by Dan Armak).
> This has to settle first, before we will be able to proceed to

<snip>

No problem. I just thought I would throw my ideas in whilst you were
listening.

> And thanks for the interest, this is what makes gentoo bettter!

Hey, it's for my benefit I'm doing this ;-)
-- 
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@gentoo.org mailing list

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

[Mark Bainter]

Henti Smith [bain@tcsn.co.za] wrote:
> here follows the proposal:
> 
[snip]
> 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 .. 
> 

Hrm.  I'm not sure how you're planning to handle dropping packages, but
perhaps they could be flagged in some way, either server side or in the
ebuild itself, and a tool could be provided within the portage tools 
group to do a check and see if any of the packages currently in use on
a machine are scheduled to be dropped?  Preferably something we could
run in a cron job...i.e. not a graphical client.

--
gentoo-dev@gentoo.org mailing list