-----BEGIN PGP SIGNED MESSAGE-----
On 24-07-2010 23:55, Alex Alexander wrote:
> following is the Council Agenda proposal for the upcoming meeting on
> Monday, July 26th.
thanks for sending the agenda email. Just to speed up a few things in
the meeting, let me present my position in the issues to be discussed.
> * allow all members to show up (5 min)
> ** vote **
> add --as-needed to default profile's LDFLAGS
I'm ready to vote in favor of this proposal.
> ** discuss / vote **
> - required-use: http://dev.gentoo.org/~ferringb/required-use.html
I'm also ready to vote in favor of this proposal. I don't like the var
name, but I won't delay the vote because of the name.
> - review eclass removal policy
> should it be 2 years since portage 220.127.116.11 went stable?
I've raised this issue before and I maintain my position that there is
no need to wait 2 years.
If we drop the requirement and start dropping old and deprecated
eclasses, and seeing as Portage has been saving eclasses on vdb and
using them when uninstalling old packages for more than 2 years, we
should have no issues. But if we do, as I've suggested before, we can
just point users to the lastest version before removal on
sources.gentoo.org so they can get it back and put it on their portage
eclass dir. We can even add some official docs about this.
So to me we can just drop the eclasses when they stop being useful.
Having a policy requesting a warning email with some advance notice,
does sound a safe approach, though.
> - should there a policy about eclass API changes?
I don't think we should limit developers and teams from updating
eclasses. As some changes might have a larger impact than expected, in
particular because of overlays, I think we should require a warning
email with advanced notice. I'd say something like 15 days should be
enough for larger changes.
> - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in
> global scope on eclasses
> and replies
As I recall from the discussion at that time, there was an argument
about PMS not allowing die to be called in eclasses (in global scope?).
I can live with both options, so I'm open to what the PM people have to
say about it.
> - mailing lists
> should we post council agenda to -council? -dev? -project?
I haven't set my mind on this one yet, but sending to council would
allow easier retrieval at later dates.
> some devs suggest we should cross-post to -dev and -council
> but not everyone likes cross-posting as it can lead to fragmentation
As I've replied in the project thread, I don't have anything against
cross-posting for this.
> Petteri suggested punting -council and using -project instead
> * go through bugs assigned to email@example.com
> * open floor: listen to developers
> If you have something urgent not included above, please reply to this
> Note that I haven't added a duration to anything but the rollcall.
> Instead, I recommend we follow a 10 minutes per topic rule.
Let's try it.
> If a topic's discussion passes the 10 minute mark without reaching a
> decision, we move further discussion to the mailing lists.
> If we need to vote for that topic, we move it to the next agenda
> with a *vote* flag.
> Items with a *vote* flag cannot be moved a second time (unless there's
> new data to consider), so they must be settled at that agenda's meeting,
> in an attempt to avoid endless discussions.
We should aim to ensure that votes do happen when an item is marked to
be voted in a meeting. However it depends on council members being ready
to vote at the meeting and on no new objection being raised during a
If that fails, it might not be possible or desirable to have a vote when
people don't know what they're voting on or have some doubts about a new
> What do you think?
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----