[gentoo-dev] One-Day Gentoo Council Reminder for January 22

[gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

This is your one-day friendly reminder !  The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
channel topic for the exact time (but it's probably 2000 UTC).

If you're supposed to show up, please show up.  If you're not supposed
to show up, then show up anyways and watch your Council monkeys dance
for you.

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

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

On 15:35 Wed 21 Jan     , Donnie Berkholz wrote:
> This is your one-day friendly reminder !  The monthly Gentoo Council
> meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
> channel topic for the exact time (but it's probably 2000 UTC).
> 
> If you're supposed to show up, please show up.  If you're not supposed
> to show up, then show up anyways and watch your Council monkeys dance
> for you.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/

Here's what I've got:

Discuss on-list before meeting
---------------------------------------
- Council meta stuff (-council)
  - Can the size change? Minimum? Maximum?
  - Should we have 2-year staggered terms?
- PMS, bug #250077: Do we need to get involved in this? (-dev)

Meeting topics
--------------
- Council meta stuff: What needs to happen before decisions?
- Open bug review

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh]

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

On Wed, 21 Jan 2009 16:02:29 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> - PMS, bug #250077: Do we need to get involved in this? (-dev)

The question for this one, really, is whether people are happy having
such a vaguely specified utility whose behaviour keeps changing in
ways that break existing idioms. If they are, at the very least we'd
need a guarantee from the Portage people that they're not going to
change its behaviour yet again, and ideally they'd revert the recent
behaviour changes back to what stable Portage does.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Tobias Scherbaum]

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

Donnie Berkholz wrote:
> Discuss on-list before meeting
> ---------------------------------------
> - Council meta stuff (-council)
>   - Can the size change? Minimum? Maximum?
>   - Should we have 2-year staggered terms?

I'm in favor of a fixed size of council members, I'd like to see at
least 5 council members *if* developers want to change the size. I
dislike the idea of stretched 2-year terms, instead I prefer having
1-year staggered terms (voting every 6 months and replace 3 or 4 council
members). This would allow to put open council slots into the next
election, we wouldn't need to hold extra elections for open slots then.

Anyways, this is something we can discuss - but as a change to the
voting procedure most likely does change or extend what's written down
in GLEP 39 I'd like to see a election on those changes.

> - PMS, bug #250077: Do we need to get involved in this? (-dev)

We haven't been asked to get involved, therefore we don't need to.

  Tobias

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

On 18:23 Thu 22 Jan     , Tobias Scherbaum wrote:
> Donnie Berkholz wrote:
> > Discuss on-list before meeting
> > ---------------------------------------
> > - Council meta stuff (-council)
> >   - Can the size change? Minimum? Maximum?
> >   - Should we have 2-year staggered terms?
> 
> I'm in favor of a fixed size of council members, I'd like to see at
> least 5 council members *if* developers want to change the size. I
> dislike the idea of stretched 2-year terms, instead I prefer having
> 1-year staggered terms (voting every 6 months and replace 3 or 4 council
> members). This would allow to put open council slots into the next
> election, we wouldn't need to hold extra elections for open slots then.
> 
> Anyways, this is something we can discuss - but as a change to the
> voting procedure most likely does change or extend what's written down
> in GLEP 39 I'd like to see a election on those changes.

I replied to -council to keep this discussion off -dev.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ulrich Mueller]

>>>>> On Thu, 22 Jan 2009, Tobias Scherbaum wrote:

>> - PMS, bug #250077: Do we need to get involved in this? (-dev)

> We haven't been asked to get involved, therefore we don't need to.

<http://thread.gmane.org/gmane.linux.gentoo.devel/59321/focus=59324>

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Tobias Scherbaum]

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

Ulrich Mueller wrote:
> >>>>> On Thu, 22 Jan 2009, Tobias Scherbaum wrote:
> 
> >> - PMS, bug #250077: Do we need to get involved in this? (-dev)
> 
> > We haven't been asked to get involved, therefore we don't need to.
> 
> <http://thread.gmane.org/gmane.linux.gentoo.devel/59321/focus=59324>
> 

well, http://article.gmane.org/gmane.linux.gentoo.devel/59428 

We do have the procedure you did ask for and I personally tend to agree
with what Donnie said. 

  Tobias

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Jeremy Olexa]

Donnie Berkholz wrote:
> This is your one-day friendly reminder !  The monthly Gentoo Council
> meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
> channel topic for the exact time (but it's probably 2000 UTC).
> 
> If you're supposed to show up, please show up.  If you're not supposed
> to show up, then show up anyways and watch your Council monkeys dance
> for you.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
> 

Sorry for the late request.

Can we get a consensus on bash version in the tree? this thread[1] is 
unresolved. I understand that the PMS draft is not set in stone (or 
something), but please...let's progress and update the spec[2]. I feel 
that this makes it hard for other projects relying on Gentoo to do some 
things without being able to *know* what version of bash is allowed.

Currently, our /draft/ says bash-3.0 but our tree says otherwise.

[1]: http://thread.gmane.org/gmane.linux.gentoo.devel/59154
[2]: Or make the tree comply, I don't really care tbh.

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

On 21:28 Wed 21 Jan     , Jeremy Olexa wrote:
> Can we get a consensus on bash version in the tree? this thread[1] is  
> unresolved. I understand that the PMS draft is not set in stone (or  
> something), but please...let's progress and update the spec[2]. I feel  
> that this makes it hard for other projects relying on Gentoo to do some  
> things without being able to *know* what version of bash is allowed.

Which projects relying on Gentoo are having a hard time? It's helpful to 
know the impact of a problem when deciding what to do about it.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Jeremy Olexa]

Donnie Berkholz wrote:
> On 21:28 Wed 21 Jan     , Jeremy Olexa wrote:
>> Can we get a consensus on bash version in the tree? this thread[1] is  
>> unresolved. I understand that the PMS draft is not set in stone (or  
>> something), but please...let's progress and update the spec[2]. I feel  
>> that this makes it hard for other projects relying on Gentoo to do some  
>> things without being able to *know* what version of bash is allowed.
> 
> Which projects relying on Gentoo are having a hard time? It's helpful to 
> know the impact of a problem when deciding what to do about it.
> 

Well.. pet projects, nothing major really.

However,
In Gentoo Prefix, I found the issue in the original post on the other 
thread because my host system had bash-3.0 on it so I wanted to save a 
lengthy compile on an obscure platform. If Gentoo specs say "bash-3.X is 
guarenteed to work" then it is simple to say that we require that the 
user compiles this version while bootstrapping a new Prefix. Otherwise, 
its a mystery what works. Some platforms that I bootstrap on have 
bash-2.05 and it would be nice to *know* what I should upgrade to.

I think the spec should just be upgraded because it isn't exactly 
obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We already 
have 3.1 features in the tree, I'm not sure where the red tape is here.

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh]

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

On Wed, 21 Jan 2009 22:10:29 -0600
Jeremy Olexa <darkside@gentoo.org> wrote:
> I think the spec should just be upgraded because it isn't exactly 
> obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We
> already have 3.1 features in the tree, I'm not sure where the red
> tape is here.

The problem is, if the tree uses 3.1 and you don't have 3.1, it's a
massive pain in the ass to upgrade. We waited a loooong time between
3.0 going stable and allowing it in the tree because of that.

Ideally we'd say "no using 3.1 features unless EAPI=3", but that would
be messy with eclasses even if developers did know that += is a 3.1
feature...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

On 16:11 Thu 22 Jan     , Ciaran McCreesh wrote:
> On Wed, 21 Jan 2009 22:10:29 -0600
> Jeremy Olexa <darkside@gentoo.org> wrote:
> > I think the spec should just be upgraded because it isn't exactly 
> > obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We
> > already have 3.1 features in the tree, I'm not sure where the red
> > tape is here.
> 
> The problem is, if the tree uses 3.1 and you don't have 3.1, it's a
> massive pain in the ass to upgrade. We waited a loooong time between
> 3.0 going stable and allowing it in the tree because of that.
> 
> Ideally we'd say "no using 3.1 features unless EAPI=3", but that would
> be messy with eclasses even if developers did know that += is a 3.1
> feature...

Can this be fixed by adding bash dependencies to things using new 
features? As long as we keep them out of the build path of bash, things 
ought to work. Then we could add a repoman check for new features, if we 
wanted.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh]

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

On Thu, 22 Jan 2009 08:56:23 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Can this be fixed by adding bash dependencies to things using new 
> features? As long as we keep them out of the build path of bash,
> things ought to work.

Only if you're guaranteed bash 3.1 on boxes that do metadata
generation. Which means it won't work for overlays.

> Then we could add a repoman check for new features, if we wanted.

Can't do that unless you write a feature-complete bash parser and
pretend-execute every possible path an ebuild can take...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh]

On Thu, Jan 22, 2009 at 5:02 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Only if you're guaranteed bash 3.1 on boxes that do metadata
> generation. Which means it won't work for overlays.

Come to think of it... This is yet another reason GLEP 55 is necessary.

-- 
Ciaran McCreesh

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Donnie Berkholz]

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

On 17:02 Thu 22 Jan     , Ciaran McCreesh wrote:
> On Thu, 22 Jan 2009 08:56:23 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Can this be fixed by adding bash dependencies to things using new 
> > features? As long as we keep them out of the build path of bash,
> > things ought to work.
> 
> Only if you're guaranteed bash 3.1 on boxes that do metadata
> generation. Which means it won't work for overlays.

I'm not an expert on metadata generation, so please tell me if I'm wrong 
here. Most if not all overlays don't ship pregenerated metadata, which 
means users have to generate it locally. Without doing so, they cannot 
install anything from that overlay that uses bash features they lack. 
They can still install things from that overlay that don't use the new 
bash features.

Consequently, packages in overlays using new bash features won't work 
till you upgrade your bash. They also won't be able to give you a good 
error about how to fix it, because you can't guarantee that you'll be 
able to parse the ebuild/eclass as far as the bash dependency.

I guess a GLEP 42 news item would sort of work, but I really wish we had 
tree dependencies. Another option would be to make overlay maintainers 
generate their own metadata.

> > Then we could add a repoman check for new features, if we wanted.
> 
> Can't do that unless you write a feature-complete bash parser and
> pretend-execute every possible path an ebuild can take...

We're getting into pretty weird territory here -- if you had slotted 
bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n 
foo.ebuild, etc.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Ciaran McCreesh]

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

On Thu, 22 Jan 2009 09:28:31 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Only if you're guaranteed bash 3.1 on boxes that do metadata
> > generation. Which means it won't work for overlays.
> 
> I'm not an expert on metadata generation, so please tell me if I'm
> wrong here. Most if not all overlays don't ship pregenerated
> metadata, which means users have to generate it locally. Without
> doing so, they cannot install anything from that overlay that uses
> bash features they lack. They can still install things from that
> overlay that don't use the new bash features.
> 
> Consequently, packages in overlays using new bash features won't work 
> till you upgrade your bash. They also won't be able to give you a
> good error about how to fix it, because you can't guarantee that
> you'll be able to parse the ebuild/eclass as far as the bash
> dependency.

It's the "won't work" bit that's the problem. Using bash-3.1 features
with older bash won't generally give a fatal error. It'll just result
in an easily missable message being shown to stderr, and the package
carrying on with duff information. The failures can be extremely
unobvious and can result in utterly h0rked packages being installed.

> I guess a GLEP 42 news item would sort of work, but I really wish we
> had tree dependencies.

There're always profiles... But profiles have to be updated long before
3.1 features are in use, to give people time to upgrade.

> Another option would be to make overlay maintainers generate their
> own metadata.

Probably not viable. Metadata generation moves hosting an overlay from
something you do with a VCS to a complicated procedure involving
several interacting tools -- it's complicated enough that even the way
it's done for gentoo-x86 doesn't always work properly...

> We're getting into pretty weird territory here -- if you had slotted 
> bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n 
> foo.ebuild, etc.

That still wouldn't catch a lot of things... Unfortunately repoman
can't replace developer knowledge.

Short of persuading upstream to add a feature that makes bash able to
die if it detects you using features added in a version newer than the
one you tell it, there's not much that can be done beyond educating
developers, restricting newer bash features to newer EAPIs and using
GLEP 55 to handle the metadata generation problem.

-- 
Ciaran McCreesh

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