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

Likewise.

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

Likewise.

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

Agreed.

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

> > 	- 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
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
www.linuxized.com