|From:||Alex Alexander <firstname.lastname@example.org>|
|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.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 126.96.36.199 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 insteadI 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 > 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