On Sun, Jul 25, 2010 at 01:42:08AM +0000, Jorge Manuel B. S. Vicetto wrote:
> -----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.
> 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.
We haven't managed to find any decent alternatives for the name,
so lets stick to that :)
> > - review eclass removal policy
> > should it be 2 years since portage 22.214.171.124 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.
I think we need a lastrite email at least 30 days prior to removal,
to allow anyone using the eclass outside the tree to take action.
> > - 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.
Agreed. As long as the developers/teams ensure that nothing breaks on
the main tree after the changes, they should be free to do whatever they
> > - 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.
If it comes down to us, "die"ing looks better to me, EAPI_TOO_OLD seems
> > - 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.
I think the proper place is -council. In my opinion each ML has its
place and usage. That said, I don't really mind cross-posting to -dev to
get greater visibility.
> > 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
I like having a dedicated ML for council matters.
> > * 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
> > 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
> 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
Indeed, my recommendation's goal is not to force random outcomes. I think
of it as motivation for us to do our homework prior to meetings :)
*new* objections or data could invalidate the *vote* flag, pushing the
item to the next agenda (if no decision can be reached).
> > What do you think?
> - --
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more