Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-council@g.o
From: Alex Alexander <wired@g.o>
Subject: Re: Council Agenda proposal for upcoming 2010-07-26 meeting
Date: Sun, 25 Jul 2010 13:51:29 +0300
On Sun, Jul 25, 2010 at 01:42:08AM +0000, Jorge Manuel B. S. Vicetto wrote:
> 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.

Good idea.

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


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

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
> >
> > 			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
too hackish.

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

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?
> > 
> - -- 
> Regards,
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections

Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more 
pgpMHWMCmpikw.pgp (PGP signature)
Council Agenda proposal for upcoming 2010-07-26 meeting
-- Alex Alexander
Re: Council Agenda proposal for upcoming 2010-07-26 meeting
-- Jorge Manuel B. S. Vicetto
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Council Agenda proposal for upcoming 2010-07-26 meeting
Next by thread:
Re: Council Agenda proposal for upcoming 2010-07-26 meeting
Previous by date:
Re: Council Agenda proposal for upcoming 2010-07-26 meeting
Next by date:
Re: Council Agenda proposal for upcoming 2010-07-26 meeting

Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.