Council Agenda proposal for upcoming 2010-07-26 meeting

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Council Agenda proposal for upcoming 2010-07-26 meeting

Alex Alexander
Hi,

following is the Council Agenda proposal for the upcoming meeting on
Monday, July 26th.

* allow all members to show up (5 min)
** vote **
        add --as-needed to default profile's LDFLAGS
** discuss / vote **
        - required-use: http://dev.gentoo.org/~ferringb/required-use.html
        - review eclass removal policy
                should it be 2 years since portage 2.1.4.4 went stable?
        - should there a policy about eclass API changes?
        - 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
        - mailing lists
                should we post council agenda to -council? -dev? -project?
                some devs suggest we should cross-post to -dev and -council
                        but not everyone likes cross-posting as it can lead to fragmentation
                Petteri suggested punting -council and using -project instead
* go through bugs assigned to [hidden email]
* 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.

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.

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.

What do you think?

--
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Council Agenda proposal for upcoming 2010-07-26 meeting

Jorge Manuel B. S. Vicetto-2
-----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.


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

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

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

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

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

> 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
> * go through bugs assigned to [hidden email]
> * 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.

> What do you think?
>

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMS5ZwAAoJEC8ZTXQF1qEPqEkP/0ffJgc7AeAQo2o7o//X+z+K
f7CKlSXDx5oAZl498txXqx+wns/Z+cj+v7fSPX71lPcTSv0f3VyHQ0KH79rE5Eyy
oa77yzed9fQMDU+BIckexihnhBo7VCZkXbSf8DTigyR8kGRRthB3i33ulFP2LUzB
rI6lewXQzdfcRspMfLXVUFwCaPMKJoVe0b2zU6u0K/iqUyoi2zbCatxHi/Cg3ipV
cMIiJNkN81iALkF2OGIT+j27OLWBAf+K8WngyXIYrq1NQMb1gWetpmL8Pinf+2ry
sUJ/jVe8sf+mu/PILmzEnPoDE+Rcmr6w9LEYVYHPLs70RmmTeEBmETWcRHZxoAcN
DY30bhxBYcX6fSR2sU2SORiK57L4yxYoBIDQQF4hY/gIhDpI+IoAvLa6jNv8+rea
tOByFOleXWp/tCPY8g86hinRIgPchzQly6fqxfYvOnre1erjFaN0S3Nef0xx6yWk
etZDdkYwbeBKjXmdvs1iMV29BAp4QFrniTWa+Ff8e2XMxHWqTU9EySzd97WExZ4m
HHGo5HUhGk2BOgHewCknOO7Ywr0/6ezQfdNuJcZrTqu3O+q/55ZtDnG4BGuW9sKD
qF8NhbD3w1UkkX3qaq5/kJpk3XZEqE0t756PmtMTnwu3K7mgiAoXotv6U+0h25Ot
RpufPXmgWi2C7BPlWHvy
=8PTe
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Council Agenda proposal for upcoming 2010-07-26 meeting

Alex Alexander
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 [hidden email]
> > * 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

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Council Agenda proposal for upcoming 2010-07-26 meeting

Rich Freeman
In reply to this post by Jorge Manuel B. S. Vicetto-2
On 07/24/2010 09:42 PM, Jorge Manuel B. S. Vicetto wrote:

> On 24-07-2010 23:55, Alex Alexander wrote:
>> 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.

Might I suggest that items that aren't ripe for voting simply be voted
down, with comments made that the item isn't being outright rejected so
much as rejected-for-now, with more work needed.  Guidance should of
course be given on what needs to be done.

Sometimes an idea just isn't worked out enough to move forward - there
isn't consensus.  The council meetings shouldn't really be the place to
do such working-out.  IRC, blogs, lists, etc are all much better for this.

I'm not a big fan of standing agenda items - even for status updates.
If there are status updates they should be VERY brief - after all you
could just provide it via the list.  If an item isn't worked out then
just keep it outside of the meeting.

You would need to make sure that for things like devrel appeals/etc that
appropriate action is taken while the issue remains under consideration
(I'm not sure whether policy is to ban before appeal and then unban
later, or vice-versa), and make sure everybody understands that the
appeal is still in effect.

If immature items become a big problem, here is another thought - have
more meetings, but only one meeting per month is official.  The
unofficial meetings would just be designated times where everybody can
show up and have discussion, but no votes would be held.  That would
give people time to work out issues, without triggering slacker clauses
and taking up official meeting time.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: Council Agenda proposal for upcoming 2010-07-26 meeting

Petteri Räty-2
In reply to this post by Alex Alexander
On 25.7.2010 2.55, Alex Alexander wrote:

> Hi,
>
> following is the Council Agenda proposal for the upcoming meeting on
> Monday, July 26th.
>
> * allow all members to show up (5 min)
> ** vote **
> add --as-needed to default profile's LDFLAGS
> ** discuss / vote **
> - required-use: http://dev.gentoo.org/~ferringb/required-use.html
> - review eclass removal policy
> should it be 2 years since portage 2.1.4.4 went stable?
> - should there a policy about eclass API changes?

> - 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
> - mailing lists
> should we post council agenda to -council? -dev? -project?

We should handle punting -council first. If it survives then -council is
the logical choice.

> some devs suggest we should cross-post to -dev and -council
> but not everyone likes cross-posting as it can lead to fragmentation

The outcome of the cross-posting thread on gentoo-project is that cross
posting is only allowed when using gentoo-dev-announce.

Regards,
Petteri