[gentoo-dev] Gentoo Council Reminder for June 11

[gentoo-dev] Gentoo Council Reminder for June 11

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/


Following is the preliminary meeting agenda.


EAPI 3: Short discussion of the progress
----------------------------------------

zmedico will provide an update on the progress of the implementation. Short
discussion of problems and implementation decisions if needed.


Default ACCEPT_LICENSE
----------------------
Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
whether that's ok. What happens to the X11 license files (one for each app)?


Bash-4 in EAPI-3
----------------
Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
first whether or not to open the EAPI-3 feature list at all.


Define EAPI development/deployment cycles
-----------------------------------------

Goal: Start discussion about EAPI development/deployment. For example:
Collect problems of eapi introductions in the past, like reverting
ebuilds to former eapis to get them stable, not waiting for the pm
support a certain eapi before requesting stable keywords for ebuilds
using the new eapi, .... Collect problems of EAPI development like
feature-freeze, late feature removals (due to implementation problems).
Eventually develop a lightweight EAPI development model.



Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30
-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Nirbheek Chauhan]

On Fri, Jun 5, 2009 at 3:56 AM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> Default ACCEPT_LICENSE
> ----------------------
> Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> whether that's ok. What happens to the X11 license files (one for each app)?
>

The x11 team[1] came to the conclusion that following RedHat's lead
and just using MIT as license for Xorg packages should suffice since
they are quite careful about these things. This should definitely be
better than the current practice anyway.

Are there any other packages or sets of packages with horrible LICENSE
behaviour similar to this?


1. Remi, could you reply here and confirm for record purposes?

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Rémi Cardona]

Nirbheek Chauhan a écrit :
> The x11 team[1] came to the conclusion that following RedHat's lead
> and just using MIT as license for Xorg packages should suffice since
> they are quite careful about these things. This should definitely be
> better than the current practice anyway.

That's indeed my plan. All the X packages I've checked in Fedora's cvs 
have MIT as the license. I think this will definitely help clean up 
gentoo-x86/license.

As long as we all agree that LICENSE is only informational (ie, we try 
to do our best but comes with no guarantee). For the record, even simple 
X packages such as libs and/or protos may have 2 or more 
similar-but-not-identical license headers in various files, dozens of 
copyright holders.

So anyone doing _serious_ license work on X packages shouldn't even rely 
on what we currently provide as those licenses may not reflect the 
actual license of all files in our packages.

Bottom line, everyone considers them to be MIT/X11 which seems to be 
fairly accurate.

My plan is to go over each package as time permits, check the license 
and then make the x-modular eclass set the default license to MIT 
instead of ${PN}.

I could definitely use a hand to check all those packages :)

Cheers,

Rémi

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Nirbheek Chauhan]

On Fri, Jun 5, 2009 at 1:47 PM, Rémi Cardona<remi@gentoo.org> wrote:
> My plan is to go over each package as time permits, check the license and
> then make the x-modular eclass set the default license to MIT instead of
> ${PN}.
>
> I could definitely use a hand to check all those packages :)
>

Here's a list of packages that inherit x-modular.eclass and don't
define LICENSE (prefixed by "Plz2fix"):

http://dev.gentoo.org/~nirbheek/files/x-modular-packages-without-LICENSE

Command used to generate it:

for ebuild in */*/*.ebuild; do grep -qe x-modular "${ebuild}" && {
grep -qe LICENSE "${ebuild}" && echo "Fine: ${ebuild}" || echo
"Plz2fix: ${ebuild}"; }; done > x-modular-packages-without-LICENSE

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Doug Goldstein]

On Thu, Jun 4, 2009 at 5:26 PM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
>
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
>
>
> Following is the preliminary meeting agenda.
>
>
> EAPI 3: Short discussion of the progress
> ----------------------------------------
>
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.

I'd say let's involve all the package manager maintainer groups. Each
packager manager can have a rep speak on their behalf and we can plow
through this topic fairly quickly.
>
>
> Default ACCEPT_LICENSE
> ----------------------
> Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> whether that's ok. What happens to the X11 license files (one for each app)?

In virtually all situations MIT has been used for the X11 license,
which should be sufficient enough for us. The previously proposed
defaults for ACCEPT_LICENSE all looked reasonable to me.

>
>
> Bash-4 in EAPI-3
> ----------------
> Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> first whether or not to open the EAPI-3 feature list at all.

No. bash-4 has seen some regressions and some oddities. 24 patches in
and its starting to seem remotely sane, except the problem is it does
not have wide scale adoption yet. I expect to see a lot of patches
coming. Additionally, EAPI-3 has been an ongoing thing long enough.
The more we keep pushing this off the more items should be shuffled
in. We decided what EAPI-3 was a long time back. Stick with that.
EAPI-4 can be the bases of bash-4 support.

>
>
> Define EAPI development/deployment cycles
> -----------------------------------------
>
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, .... Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.

This is still something being discussed on the mailing lists and
belongs there. Not in a council meeting.

If I am AFK during the council meeting due to being in a skiff, I have
designated tanderson/gentoofan23 as my proxy.

-- 
Doug Goldstein

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]

Am Dienstag, den 09.06.2009, 21:00 -0500 schrieb Doug Goldstein:
> On Thu, Jun 4, 2009 at 5:26 PM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> >
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> >
> > For more info on the Gentoo Council, feel free to browse our homepage:
> > http://www.gentoo.org/proj/en/council/
> >
> >
> > Following is the preliminary meeting agenda.
> >
> >
> > EAPI 3: Short discussion of the progress
> > ----------------------------------------
> >
> > zmedico will provide an update on the progress of the implementation. Short
> > discussion of problems and implementation decisions if needed.
> 
> I'd say let's involve all the package manager maintainer groups. Each
> packager manager can have a rep speak on their behalf and we can plow
> through this topic fairly quickly.
Sure, one prominent maintainer of an alternative package manager is
usually around during meetings. But since the more complex features are
already implemented in kdebuild and paludis supported kdebuild, we're
really waiting for support in our official package manager. I don't know
about the state of pkgcore though.

> >
> >
> > Default ACCEPT_LICENSE
> > ----------------------
> > Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> > whether that's ok. What happens to the X11 license files (one for each app)?
> 
> In virtually all situations MIT has been used for the X11 license,
> which should be sufficient enough for us. The previously proposed
> defaults for ACCEPT_LICENSE all looked reasonable to me.
> 
> >
> >
> > Bash-4 in EAPI-3
> > ----------------
> > Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> > first whether or not to open the EAPI-3 feature list at all.
> 
> No. bash-4 has seen some regressions and some oddities. 24 patches in
> and its starting to seem remotely sane, except the problem is it does
> not have wide scale adoption yet. I expect to see a lot of patches
> coming. Additionally, EAPI-3 has been an ongoing thing long enough.
> The more we keep pushing this off the more items should be shuffled
> in. We decided what EAPI-3 was a long time back. Stick with that.
> EAPI-4 can be the bases of bash-4 support.
Well, that's my opinion as well. But since there was an official request
for this we have to decide on it.

> 
> >
> >
> > Define EAPI development/deployment cycles
> > -----------------------------------------
> >
> > Goal: Start discussion about EAPI development/deployment. For example:
> > Collect problems of eapi introductions in the past, like reverting
> > ebuilds to former eapis to get them stable, not waiting for the pm
> > support a certain eapi before requesting stable keywords for ebuilds
> > using the new eapi, .... Collect problems of EAPI development like
> > feature-freeze, late feature removals (due to implementation problems).
> > Eventually develop a lightweight EAPI development model.
> 
> This is still something being discussed on the mailing lists and
> belongs there. Not in a council meeting.
Which mailinglist? Since council people have now pretty good experience
on what needs to be done to get an eapi ready I think it is the right
place to start the discussion.

> 
> If I am AFK during the council meeting due to being in a skiff, I have
> designated tanderson/gentoofan23 as my proxy.
> 
noted.


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, 9 Jun 2009 21:00:22 -0500
Doug Goldstein <cardoe@gentoo.org> wrote:
> > zmedico will provide an update on the progress of the
> > implementation. Short discussion of problems and implementation
> > decisions if needed.
> 
> I'd say let's involve all the package manager maintainer groups. Each
> packager manager can have a rep speak on their behalf and we can plow
> through this topic fairly quickly.

Paludis has been ready to go whenever for a few weeks now.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Ulrich Mueller]

>>>>> On Tue, 9 Jun 2009, Doug Goldstein wrote:

> > Bash-4 in EAPI-3
> > ----------------
> > Goal: A request has been made to allow bash-4.0 features in
> > EAPI-3. Decide first whether or not to open the EAPI-3 feature
> > list at all.

> No. bash-4 has seen some regressions and some oddities. 24 patches
> in and its starting to seem remotely sane, except the problem is it
> does not have wide scale adoption yet. I expect to see a lot of
> patches coming.

I agree. It's too early for bash-4 in the tree. Also Portage would
have to depend on bash-4 then.

> Additionally, EAPI-3 has been an ongoing thing long enough. The more
> we keep pushing this off the more items should be shuffled in. We
> decided what EAPI-3 was a long time back. Stick with that.

This is not a strong argument. The current bottleneck is the
implementation of EAPI-3 features in Portage. If we reopen the feature
list, but allow only things that have zero implementation cost in
Portage, then it would cause no additional delay.

Ulrich

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

Tiziano Müller wrote:
> EAPI 3: Short discussion of the progress
> ----------------------------------------
> 
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.

Guess that's a rather short topic. Nothing to discuss for us.

> Default ACCEPT_LICENSE
> ----------------------
> Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> whether that's ok. What happens to the X11 license files (one for each app)?

The proposed default looks good to me. Besides that the X11 license
stuff needs to get sorted out finally (if it hasn't been already -
MIT?).

> Bash-4 in EAPI-3
> ----------------
> Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> first whether or not to open the EAPI-3 feature list at all.

I'm against re-opening the feature list for EAPI-3, let's get EAPI-3
finally implemented and put this on the agenda for EAPI-4. I don't see
the pressure to allow bash-4.0 stuff now.

> Define EAPI development/deployment cycles
> -----------------------------------------
> 
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, .... Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.

The main "problem" is that there is no deployment process for newer
EAPIs specified right now. In the past we had something like "there must
be two releases (stage sets) including a Portage version supporting new
features" before people were allowed to use new features in tree. We had
a timeframe of something about a half year between introduction of new
features and usage of them. At least in theory.

While having such a longer timeframe would make the deployment of new
EAPIs somewhat easier (especially the special cases when newer versions
of a package were migrated to a shiny new EAPI which isn't supported by
a stable Portage yet and there's a need for quick versions bump due to
security bugs) I think something inbetween that old process and the
currently used one would be useful. For example something like: New
EAPIs can be used in tree once a Portage version supporting that
specific EPAI has been marked as stable plus a transition period of -
say - 4 weeks after the Portage version has been made stable on the
first architecture.

And for EAPI development: I did dislike the google spreadsheet which has
been used for EAPI-3 and don't think this has proved to be useful. If we
do opt for any public collaboration development process (instead of say
some file in $SCM) we should use a simple Wiki and be done. Tracking
changes made to that document is a requirement from my pov. Using bugs
for each feature and an EAPI tracker bug would be another possible way
to organize this.

  Tobias


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Wed, 10 Jun 2009 23:21:49 +0200
Tobias Scherbaum <dertobi123@gentoo.org> wrote:
> And for EAPI development: I did dislike the google spreadsheet which
> has been used for EAPI-3 and don't think this has proved to be
> useful. If we do opt for any public collaboration development process
> (instead of say some file in $SCM) we should use a simple Wiki and be
> done. Tracking changes made to that document is a requirement from my
> pov. Using bugs for each feature and an EAPI tracker bug would be
> another possible way to organize this.

Oh please no wiki. The problem for EAPI 3 was that feature requests
were on a google spreadsheet, and on bugzilla, and on a pms draft
branch, and on a text file in various people's devspaces.

The workflow that'd be easiest is:

* Requests go onto bugzilla, where they could be nicely organised into
  "can do this now", "probably not doable in the timeframe we're
  looking for" and "not detailed enough to be usable".

* We get rough diffs for PMS for everything in the "can do this now"
  category, and give them all an arbitrary codename that in no way
  describes the feature (so that certain people can't vote and discuss
  things based upon what they think the feature is without bothering to
  find out if it's anything to do with what they assume).

* Based upon developer feedback, the Council rates each of those
  codenames as "yes", "no", "whatever" or "needs more discussion". For
  those that need discussion, the people who voted for discussion
  explain what they think needs discussing, and we sort that out.

* The PMS people come up with exact wording for things that are mostly
  "yes".

* The Council votes for final approval, pending Portage implementation.

* Portage implements it in ~arch. People start using it in ~arch.

* Portage goes stable. People are allowed to start using it in stable
  for things that aren't deps of anything super-critical.

What we don't need is lots of people running around doing their own
thing in different places. What we do need is for a single
waterflow-like workflow with a good way of coordinating it that doesn't
rely upon the PMS team chasing everyone up and trying to keep track of
everything.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Ciaran McCreesh wrote:
> Oh please no wiki.

Whatever. My requirements are quite simple: public accessible, no
accounts needed on 3rd party systems (like Google) to add feature
requests or comments and changes must be traceable. Using bugzilla fits
those criteria as well.

> The problem for EAPI 3 was that feature requests
> were on a google spreadsheet, and on bugzilla, and on a pms draft
> branch, and on a text file in various people's devspaces.

Agreed.

> The workflow that'd be easiest is:
> 
> * Requests go onto bugzilla, where they could be nicely organised into
>   "can do this now", "probably not doable in the timeframe we're
>   looking for" and "not detailed enough to be usable".

* "can do this now" requests are added to a tracker bug for the upcoming
EAPI.

> * We get rough diffs for PMS for everything in the "can do this now"
>   category, and give them all an arbitrary codename that in no way
>   describes the feature (so that certain people can't vote and discuss
>   things based upon what they think the feature is without bothering to
>   find out if it's anything to do with what they assume).
> 
> * Based upon developer feedback, the Council rates each of those
>   codenames as "yes", "no", "whatever" or "needs more discussion". For
>   those that need discussion, the people who voted for discussion
>   explain what they think needs discussing, and we sort that out.
> 
> * The PMS people come up with exact wording for things that are mostly
>   "yes".
> 
> * The Council votes for final approval, pending Portage implementation.

Looks good so far.

> * Portage implements it in ~arch. People start using it in ~arch.

I'd propose: Portage implements it in ~arch. People can start using it
in overlays.

> * Portage goes stable. People are allowed to start using it in stable
>   for things that aren't deps of anything super-critical.

I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed
to start using it for things that aren't deps of anything
super-critical.

> What we don't need is lots of people running around doing their own
> thing in different places. What we do need is for a single
> waterflow-like workflow with a good way of coordinating it that doesn't
> rely upon the PMS team chasing everyone up and trying to keep track of
> everything.

ack.

  Tobias


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Gentoo Council Reminder for June 11

[Duncan]

Tobias Scherbaum <dertobi123@gentoo.org> posted
1244672807.6190.35.camel@homer.ob.libexec.de, excerpted below, on  Thu, 11
Jun 2009 00:26:47 +0200:

>> * The Council votes for final approval, pending Portage implementation.
> 
> Looks good so far.
> 
>> * Portage implements it in ~arch. People start using it in ~arch.
> 
> I'd propose: Portage implements it in ~arch. People can start using it
> in overlays.

The problem with that is that it's a NOOP.  People can use whatever they 
want in overlays, already, a feature that's a good part of their 
dynamic.  Thus, "can start using it in overlays" is entirely meaningless.

Now one could add the single word "official" in there, as in "official 
overlays", defining that term much as layman does.  (Actually, it appears 
the layman manpage uses the terms "fully supported" and "non-official", 
not specifically the term "official", altho the contrasting "non-
official" does have the implication of making "fully supported" overlays 
synonymous with "official overlays".)

>> * Portage goes stable. People are allowed to start using it in stable
>>   for things that aren't deps of anything super-critical.
> 
> I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed
> to start using it for things that aren't deps of anything
> super-critical.

Question.  Was the omission of a specific ~arch allowed step deliberate?  
You went from "allowed in overlays" to "allowed in stable", without a 
stop in ~arch.  Either it was deliberate and an reason would have been 
useful, or it was simply overlooked.

(FWIW, a policy that ~arch portage of an approved EAPI allows ~arch 
packages, stable portage allows stable packages, but with the cost of 
putting it in ~arch before stable portage has it stated explicitly -- 
that anyone choosing to do so should be prepared to revert to a previous 
EAPI should a security bump require it before portage stabilizes -- that 
sort of policy works for me.  Problems we've had can thus be explained as 
not making that cost of following ~arch portage with ~arch packages 
explicit, I believe, so make it explicit and let the maintainers then 
choose based on that.  Perhaps add the additional caveat that it may ONLY 
be done with the signoff of a backup maintainer and/or the supporting 
project as well, in the hopefully unusual case that the maintainer that 
did the conversion goes MIA when a security bug comes up to press the 
matter, so there's always someone else that understands the situation 
well enough to handle the revert to a stable EAPI as necessary.  However 
that's not a strongly held position and doesn't mean I oppose the above, 
only that I'd like clarification thereof.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.06.10 22:21, Tobias Scherbaum wrote:
[snip]

> The main "problem" is that there is no deployment process for newer
> EAPIs specified right now. In the past we had something like "there
> must be two releases (stage sets) including a Portage version 
> supporting new features" before people were allowed to use new 
> features in tree. We had a timeframe of something about a half year 
> between introduction of  new features and usage of them. At least in 
> theory.
> 
> While having such a longer timeframe would make the deployment of new
> EAPIs somewhat easier (especially the special cases when newer
> versions of a package were migrated to a shiny new EAPI which isn't 
> supported by a stable Portage yet and there's a need for quick 
> versions bump due to security bugs) I think something inbetween that 
> old process and the
> currently used one would be useful. For example something like: New
> EAPIs can be used in tree once a Portage version supporting that
> specific EPAI has been marked as stable plus a transition period of -
> say - 4 weeks after the Portage version has been made stable on the
> first architecture.

What about the case where the new EAPI breaks backwards compatibility 
with existing package managers, as would be the case with glep 55?

Its quite true that such changes can be introduced after a wait and 
only upset late adoptors. By implementing the key feature of glep 55, 
which is making the EAPI known to the PM without sourcing the ebuild,
we would only need one last wait to introduce new features in this 
way in later EAPIs.PMs would then know the EAPI in advance and ignore 
ebuilds using EAPIs they don't understand.

[snip]

> 
>   Tobias
> 
> 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkowMGEACgkQTE4/y7nJvaswcgCfUa5dKLY8YYMyL7FjhIcNVXJg
pO8An33Z2+1lm2jzkh9ciANzOhH+PqXv
=yiKg
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tobias Scherbaum]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

Roy Bamford wrote:
> What about the case where the new EAPI breaks backwards compatibility 
> with existing package managers, as would be the case with glep 55?
> 
> Its quite true that such changes can be introduced after a wait and 
> only upset late adoptors. By implementing the key feature of glep 55, 
> which is making the EAPI known to the PM without sourcing the ebuild,
> we would only need one last wait to introduce new features in this 
> way in later EAPIs.PMs would then know the EAPI in advance and ignore 
> ebuilds using EAPIs they don't understand.

But still then the special case I mentioned comes in. Newer version
migrated to newer EAPI. Urgent bump for security reasons is necessary.
Backporting the ebuild is necessary. Not that likely, but iirc we had
that special case for EAPI-2.

Putting in a wait for 4 or 8 weeks or whatever doesn't cost us anything
but does simplify things and gives us a clear deployment process. 

I do know we have developers with nil interest in our stable branch, but
we also have users heavily relying on our stable branch.

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Thu, 11 Jun 2009 00:37:33 +0200
Tobias Scherbaum <dertobi123@gentoo.org> wrote:
> Putting in a wait for 4 or 8 weeks or whatever doesn't cost us
> anything but does simplify things and gives us a clear deployment
> process. 

It loses us reasonably wide testing of Portage's implementation in
~arch. I'd rather not see Portage go stable with an EAPI before that
EAPI's been tested in the main tree for packages that are used by a
half decent number of ~arch users.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Gentoo Council Reminder for June 11

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090610234403.58bc6587@snowcone, excerpted below, on  Wed, 10 Jun 2009
23:44:03 +0100:

> On Thu, 11 Jun 2009 00:37:33 +0200
> Tobias Scherbaum <dertobi123@gentoo.org> wrote:
>> Putting in a wait for 4 or 8 weeks or whatever doesn't cost us anything
>> but does simplify things and gives us a clear deployment process.
> 
> It loses us reasonably wide testing of Portage's implementation in
> ~arch. I'd rather not see Portage go stable with an EAPI before that
> EAPI's been tested in the main tree for packages that are used by a half
> decent number of ~arch users.

Extremely good point.

As an unreformed ~arch user with the scars to prove it, I know I'm a 
tester for a lot of this stuff and relish the opportunity. =:^)  But 
there's been times I've shuddered at the thought of something I've dealt 
with hitting stable and I'm sure I'm not an exception in that regard, so 
anything that would lose us that valuable testing buffer had better have 
a VERY good reason.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman