Gentoo Archives: gentoo-council

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Council Agenda proposal for upcoming 2010-07-26 meeting
Date: Sun, 25 Jul 2010 01:42:21
In Reply to: [gentoo-council] Council Agenda proposal for upcoming 2010-07-26 meeting by Alex Alexander
Hash: SHA1

On 24-07-2010 23:55, Alex Alexander wrote:
> Hi, > > following is the Council Agenda proposal for the upcoming meeting on > Monday, July 26th.
Alex, 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:
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 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 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 council@g.o > * open floor: listen to developers > > --- > > If you have something urgent not included above, please reply to this > thread. > > --- > > 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.
Sounds good.0
> 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 meeting. 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 objection.
> What do you think? >
- -- Regards, 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 - iQIcBAEBAgAGBQJMS5ZwAAoJEC8ZTXQF1qEPqEkP/0ffJgc7AeAQo2o7o//X+z+K f7CKlSXDx5oAZl498txXqx+wns/Z+cj+v7fSPX71lPcTSv0f3VyHQ0KH79rE5Eyy oa77yzed9fQMDU+BIckexihnhBo7VCZkXbSf8DTigyR8kGRRthB3i33ulFP2LUzB rI6lewXQzdfcRspMfLXVUFwCaPMKJoVe0b2zU6u0K/iqUyoi2zbCatxHi/Cg3ipV cMIiJNkN81iALkF2OGIT+j27OLWBAf+K8WngyXIYrq1NQMb1gWetpmL8Pinf+2ry sUJ/jVe8sf+mu/PILmzEnPoDE+Rcmr6w9LEYVYHPLs70RmmTeEBmETWcRHZxoAcN DY30bhxBYcX6fSR2sU2SORiK57L4yxYoBIDQQF4hY/gIhDpI+IoAvLa6jNv8+rea tOByFOleXWp/tCPY8g86hinRIgPchzQly6fqxfYvOnre1erjFaN0S3Nef0xx6yWk etZDdkYwbeBKjXmdvs1iMV29BAp4QFrniTWa+Ff8e2XMxHWqTU9EySzd97WExZ4m HHGo5HUhGk2BOgHewCknOO7Ywr0/6ezQfdNuJcZrTqu3O+q/55ZtDnG4BGuW9sKD qF8NhbD3w1UkkX3qaq5/kJpk3XZEqE0t756PmtMTnwu3K7mgiAoXotv6U+0h25Ot RpufPXmgWi2C7BPlWHvy =8PTe -----END PGP SIGNATURE-----