Re: [gentoo-council] Council Agenda proposal for upcoming 2010-07-26 meeting

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
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: 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 2.1.4.4 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
> 		http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml
> 			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 - http://enigmail.mozdev.org/

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