Gentoo Archives: gentoo-council

From: Alex Alexander <wired@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 10:51:27
In Reply to: Re: [gentoo-council] Council Agenda proposal for upcoming 2010-07-26 meeting by "Jorge Manuel B. S. Vicetto"
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.
> > ** 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.
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 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 want.
> > - 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