Re: [gentoo-dev] Gentoo Council Reminder for June 11

["Tiziano Müller" <dev-zero@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]

Am Dienstag, den 09.06.2009, 21:00 -0500 schrieb Doug Goldstein:
> On Thu, Jun 4, 2009 at 5:26 PM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> >
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> >
> > For more info on the Gentoo Council, feel free to browse our homepage:
> > http://www.gentoo.org/proj/en/council/
> >
> >
> > Following is the preliminary meeting agenda.
> >
> >
> > EAPI 3: Short discussion of the progress
> > ----------------------------------------
> >
> > zmedico will provide an update on the progress of the implementation. Short
> > discussion of problems and implementation decisions if needed.
> 
> I'd say let's involve all the package manager maintainer groups. Each
> packager manager can have a rep speak on their behalf and we can plow
> through this topic fairly quickly.
Sure, one prominent maintainer of an alternative package manager is
usually around during meetings. But since the more complex features are
already implemented in kdebuild and paludis supported kdebuild, we're
really waiting for support in our official package manager. I don't know
about the state of pkgcore though.

> >
> >
> > Default ACCEPT_LICENSE
> > ----------------------
> > Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> > whether that's ok. What happens to the X11 license files (one for each app)?
> 
> In virtually all situations MIT has been used for the X11 license,
> which should be sufficient enough for us. The previously proposed
> defaults for ACCEPT_LICENSE all looked reasonable to me.
> 
> >
> >
> > Bash-4 in EAPI-3
> > ----------------
> > Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> > first whether or not to open the EAPI-3 feature list at all.
> 
> No. bash-4 has seen some regressions and some oddities. 24 patches in
> and its starting to seem remotely sane, except the problem is it does
> not have wide scale adoption yet. I expect to see a lot of patches
> coming. Additionally, EAPI-3 has been an ongoing thing long enough.
> The more we keep pushing this off the more items should be shuffled
> in. We decided what EAPI-3 was a long time back. Stick with that.
> EAPI-4 can be the bases of bash-4 support.
Well, that's my opinion as well. But since there was an official request
for this we have to decide on it.

> 
> >
> >
> > Define EAPI development/deployment cycles
> > -----------------------------------------
> >
> > Goal: Start discussion about EAPI development/deployment. For example:
> > Collect problems of eapi introductions in the past, like reverting
> > ebuilds to former eapis to get them stable, not waiting for the pm
> > support a certain eapi before requesting stable keywords for ebuilds
> > using the new eapi, .... Collect problems of EAPI development like
> > feature-freeze, late feature removals (due to implementation problems).
> > Eventually develop a lightweight EAPI development model.
> 
> This is still something being discussed on the mailing lists and
> belongs there. Not in a council meeting.
Which mailinglist? Since council people have now pretty good experience
on what needs to be done to get an eapi ready I think it is the right
place to start the discussion.

> 
> If I am AFK during the council meeting due to being in a skiff, I have
> designated tanderson/gentoofan23 as my proxy.
> 
noted.


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]