[gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Tiziano Müller]

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


Things I'd like to see being discussed are:

Organizational:
- staggered elections ... did we came to a conclusion there?
- what happens if we get too less candidates (either by nomination or by
_reopen_nominations)?
- the Secretary-Job ... we got a volunteer, is that ok for everyone? If
yes, I'd like to add something like this to the council page:
  "On it's first meeting a new council should nominate a Secretary.
Depending on the availability of candidates, this might either be a
council member volunteering to do it, a volunteering developer or a
staff-member or in case no dedicated Secretary is found the council
members have to do it in a rotating scheme (either rotate on every
meeting or every n times). The Secretary is responsible for keeping the
log of the meeting, putting together a summary and publishing it on the
council page."

Technical:
- prepalldocs ... do we need more information to decide? Should I ask on
-dev to get more input?
- Bugs remaining:
234711 - GLEP 54: scm package version suffix
234713 - GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
234716 - Extent of Code of Conduct enforcement
What is the status for them?
- DVCS ... dberkholz mentioned it and I think we should take another look/get a status update
- Homepage: any news on reorganizing the index? any news on the redesign? Can the council push this by trying to delegate the task to someone?
- GSoC: where are the results? Why aren't they on the front page? If beacon is usable, can we set it up on the page to edit docs/pages?




-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
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: 197 bytes --]

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> Things I'd like to see being discussed are:
> 
Thanks for putting this list together, Tiziano, and I think it serves as 
a great reminder of things to renew discussion about on the existing 
threads if they aren't resolved.

I want to stress again the importance of discussing topics on the 
mailing lists before the meetings. Many of these things will take some 
thinking and some research, and it's not ideal to use our meeting time 
on things that could easily be done in advance.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Tiziano Müller]

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

Am Dienstag, den 10.02.2009, 13:25 -0800 schrieb Donnie Berkholz: 
> On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> > Things I'd like to see being discussed are:
> > 
> Thanks for putting this list together, Tiziano, and I think it serves as 
> a great reminder of things to renew discussion about on the existing 
> threads if they aren't resolved.
> 
> I want to stress again the importance of discussing topics on the 
> mailing lists before the meetings. Many of these things will take some 
> thinking and some research, and it's not ideal to use our meeting time 
> on things that could easily be done in advance.

That's true. But just deciding that we need people to discuss it and
then not fostering that discussion ourselves actively is not acceptable.
Once we get the task to take care of a matter we have to take care of it
until it's done completely. This involves bringing the subject up on the
mailinglist (and not just publish the summary and wait for people to
read through it and then start a discussion depending on what they may
find in the summary), get the information we need to be able to decide
somewhere else, etc.
Why don't we assign each task to one of us council members to do that,
so we get for every task someone who's taking care of it, making sure it
gets on the agenda again, maybe even preparing a summary of the matter
for the rest of the council (in complicated cases), posting on the
mailing-list, commenting on the corresponding bug, etc.?
I guess that's what Ciaran meant in the "Secretary"-Thread.

Cheers,
Tiziano


-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
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: 197 bytes --]

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 07:53 Thu 12 Feb     , Tiziano Müller wrote:
> That's true. But just deciding that we need people to discuss it and 
> then not fostering that discussion ourselves actively is not 
> acceptable. Once we get the task to take care of a matter we have to 
> take care of it until it's done completely. This involves bringing the 
> subject up on the mailinglist (and not just publish the summary and 
> wait for people to read through it and then start a discussion 
> depending on what they may find in the summary), get the information 
> we need to be able to decide somewhere else, etc.
> 
> Why don't we assign each task to one of us council members to do that, 
> so we get for every task someone who's taking care of it, making sure 
> it gets on the agenda again, maybe even preparing a summary of the 
> matter for the rest of the council (in complicated cases), posting on 
> the mailing-list, commenting on the corresponding bug, etc.? I guess 
> that's what Ciaran meant in the "Secretary"-Thread.

I agree that it's a great idea to assign someone responsibility for 
following up, and I think that the person who brings up the topic is 
best qualified and motivated to do so. I don't see any reason to require 
it to be a council member.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 07:50:56 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> I agree that it's a great idea to assign someone responsibility for 
> following up, and I think that the person who brings up the topic is 
> best qualified and motivated to do so. I don't see any reason to
> require it to be a council member.

Unfortunately, things are often postponed because Council members
haven't done their homework or haven't looked at proposals until half
an hour before the meeting, not because there's more work required...

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 15:55 Thu 12 Feb     , Ciaran McCreesh wrote:
> On Thu, 12 Feb 2009 07:50:56 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > I agree that it's a great idea to assign someone responsibility for 
> > following up, and I think that the person who brings up the topic is 
> > best qualified and motivated to do so. I don't see any reason to
> > require it to be a council member.
> 
> Unfortunately, things are often postponed because Council members
> haven't done their homework or haven't looked at proposals until half
> an hour before the meeting, not because there's more work required...

Ciaran,

What do you propose we do to change this?

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 08:01:14 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> What do you propose we do to change this?

I suggest a preliminary agenda gets sent out a week before the meeting.
Afterwards, Council members make sure they've read up on everything,
asked all their questions and posted initial opinions at least three
days in advance. Then, assuming satisfactory answers to all of the
above, a decision can be reached in the meeting with little discussion
-- and going over one hour shall not put a stop to it.

To make sure this happens, I suggest that any Council member who
does not post their preliminary opinion (which can include a list of
questions that they consider unaddressed, and which can change as new
information becomes available) at least two days before the meeting is
counted as not being at the meeting for slacker purposes.

Emergency measures can still go in later, if necessary, and if
responses aren't received to questions then measures can still be
postponed -- the procedure needs to be flexible and can be ignored
where appropriate.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 16:12 Thu 12 Feb     , Ciaran McCreesh wrote:
> I suggest a preliminary agenda gets sent out a week before the 
> meeting. Afterwards, Council members make sure they've read up on 
> everything, asked all their questions and posted initial opinions at 
> least three days in advance. Then, assuming satisfactory answers to 
> all of the above, a decision can be reached in the meeting with little 
> discussion -- and going over one hour shall not put a stop to it.
> 
> To make sure this happens, I suggest that any Council member who does 
> not post their preliminary opinion (which can include a list of 
> questions that they consider unaddressed, and which can change as new 
> information becomes available) at least two days before the meeting is 
> counted as not being at the meeting for slacker purposes.

I like pretty much all of this. My only problem continues to be meeting 
length.

The current meeting time falls in the middle of the workday in the US, 
so long meetings aren't an option for at least Mark and me. I think Mark 
intends to send out a rescheduling note soon to see if we can fix that, 
but our evenings are horrible for the Europeans, etc.

That's just another reason why I'd like to push things onto the lists to 
the point where we could even drop live meetings entirely and simply 
have deadlines instead. It sometimes seems like the main purpose of 
meetings is to allow people to bring up last-minute objections.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Tiziano Müller]

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

Am Donnerstag, den 12.02.2009, 08:01 -0800 schrieb Donnie Berkholz:
> On 15:55 Thu 12 Feb     , Ciaran McCreesh wrote:
> > On Thu, 12 Feb 2009 07:50:56 -0800
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > > I agree that it's a great idea to assign someone responsibility for 
> > > following up, and I think that the person who brings up the topic is 
> > > best qualified and motivated to do so. I don't see any reason to
> > > require it to be a council member.
> > 
> > Unfortunately, things are often postponed because Council members
> > haven't done their homework or haven't looked at proposals until half
> > an hour before the meeting, not because there's more work required...
> 
> Ciaran,
> 
> What do you propose we do to change this?
> 

From my past experience I can say that having someone responsible for a
task within the leading group is a good way to have the whole team
informed about what's going on.

-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
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: 197 bytes --]

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 17:47 Thu 12 Feb     , Tiziano Müller wrote:
> From my past experience I can say that having someone responsible for 
> a task within the leading group is a good way to have the whole team 
> informed about what's going on.

I agree with having someone responsible. I don't see what "within the 
leading group" adds, and the continued assertion that this is required 
could use some support.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Website changes [WAS] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> - Homepage: any news on reorganizing the index?

Well, we just reorganized it a couple of weeks ago. Have you checked it 
lately? Or were you looking for a complete redesign when you said this?

> Can the council push this by trying to delegate the task to someone?

Matthew Summers (quantumsummers) has been experimenting with a 
django-based version. I haven't kept close tabs on what he's up to.

This is too large a chunk of work to simply delegate to someone and tell 
them to do it. You have to have people who are both enthusiastic and 
knowledgeable with time to work on it.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Website changes [WAS] Preliminary Meeting-Topics for 12 February 2009

[Tiziano Müller]

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

Am Dienstag, den 10.02.2009, 15:11 -0800 schrieb Donnie Berkholz:
> On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> > - Homepage: any news on reorganizing the index?
> 
> Well, we just reorganized it a couple of weeks ago. Have you checked it 
> lately?
Yes I've checked it and I like it.

>  Or were you looking for a complete redesign when you said this?
Yes, there were some plans sometime and as far as I remember there was
also a competition for the design. Or am I wrong?

> 
> > Can the council push this by trying to delegate the task to someone?
> 
> Matthew Summers (quantumsummers) has been experimenting with a 
> django-based version. I haven't kept close tabs on what he's up to.
> 
> This is too large a chunk of work to simply delegate to someone and tell 
> them to do it. You have to have people who are both enthusiastic and 
> knowledgeable with time to work on it.
Well, let's see what comes out of "beacon", that would be a good start
to have a simpler editing tool.


-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
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: 197 bytes --]

Re: [gentoo-council] Website changes [WAS] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 15:51 Wed 11 Feb     , Tiziano Müller wrote:
> Am Dienstag, den 10.02.2009, 15:11 -0800 schrieb Donnie Berkholz:
> > On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> > > - Homepage: any news on reorganizing the index?
> > 
> > Well, we just reorganized it a couple of weeks ago. Have you checked it 
> > lately?
> 
> Yes I've checked it and I like it.
> 
> >  Or were you looking for a complete redesign when you said this?
> 
> Yes, there were some plans sometime and as far as I remember there was 
> also a competition for the design. Or am I wrong?

Curtis got sick of working on it and frustrated with the endless 
bugfixes, and he quit Gentoo altogether. The person who actually won the 
contest never did anything beyond the initial design he submitted.

> > > Can the council push this by trying to delegate the task to someone?
> > 
> > Matthew Summers (quantumsummers) has been experimenting with a 
> > django-based version. I haven't kept close tabs on what he's up to.
> > 
> > This is too large a chunk of work to simply delegate to someone and tell 
> > them to do it. You have to have people who are both enthusiastic and 
> > knowledgeable with time to work on it.
> 
> Well, let's see what comes out of "beacon", that would be a good start 
> to have a simpler editing tool.

Huh? This thread was about the website redesign. I don't understand what 
you're getting at.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Website changes [WAS] Preliminary Meeting-Topics for 12 February 2009

[Luca Barbato]

Donnie Berkholz wrote:
> On 15:51 Wed 11 Feb     , Tiziano Müller wrote:
>> Am Dienstag, den 10.02.2009, 15:11 -0800 schrieb Donnie Berkholz:
>>> Matthew Summers (quantumsummers) has been experimenting with a 
>>> django-based version. I haven't kept close tabs on what he's up to.
>>>
>>> This is too large a chunk of work to simply delegate to someone and tell 
>>> them to do it. You have to have people who are both enthusiastic and 
>>> knowledgeable with time to work on it.
>> Well, let's see what comes out of "beacon", that would be a good start 
>> to have a simpler editing tool.
> 
> Huh? This thread was about the website redesign. I don't understand what 
> you're getting at.

since both are based on django he assumes probably one could be a base 
for the other

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] GSoC results from 2008 [WAS] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
> - GSoC: where are the results? Why aren't they on the front page?

Alec, do you know the status of the 2008 projects' integration and the 
status of the students involved? If not, could you request it from the 
mentors (including me) and present it here?

This would be nice to have together in the next month so we have the 
info for this year's application.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] GSoC results from 2008 [WAS] Preliminary Meeting-Topics for 12 February 2009

[Alec Warner]

On Tue, Feb 10, 2009 at 3:13 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 09:12 Tue 10 Feb     , Tiziano Müller wrote:
>> - GSoC: where are the results? Why aren't they on the front page?
>
> Alec, do you know the status of the 2008 projects' integration and the
> status of the students involved? If not, could you request it from the
> mentors (including me) and present it here?

I'll try to find some time this weekend.

-Alec

>
> This would be nice to have together in the next month so we have the
> info for this year's application.
>
> --
> Thanks,
> Donnie
>
> Donnie Berkholz
> Developer, Gentoo Linux
> Blog: http://dberkholz.wordpress.com
>

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Tiziano Müller]

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

Am Dienstag, den 10.02.2009, 09:12 +0000 schrieb Tiziano Müller:
> Things I'd like to see being discussed are:
> 
> Organizational:
> - staggered elections ... did we came to a conclusion there?
> - what happens if we get too less candidates (either by nomination or by
> _reopen_nominations)?
> - the Secretary-Job ... we got a volunteer, is that ok for everyone? If
> yes, I'd like to add something like this to the council page:
>   "On it's first meeting a new council should nominate a Secretary.
> Depending on the availability of candidates, this might either be a
> council member volunteering to do it, a volunteering developer or a
> staff-member or in case no dedicated Secretary is found the council
> members have to do it in a rotating scheme (either rotate on every
> meeting or every n times). The Secretary is responsible for keeping the
> log of the meeting, putting together a summary and publishing it on the
> council page."
> 
> Technical:
> - prepalldocs ... do we need more information to decide? Should I ask on
> -dev to get more input?
> - Bugs remaining:
> 234711 - GLEP 54: scm package version suffix
> 234713 - GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
> 234716 - Extent of Code of Conduct enforcement
> What is the status for them?
> - DVCS ... dberkholz mentioned it and I think we should take another look/get a status update
> - Homepage: any news on reorganizing the index? any news on the redesign? Can the council push this by trying to delegate the task to someone?
> - GSoC: where are the results? Why aren't they on the front page? If beacon is usable, can we set it up on the page to edit docs/pages?

... and another issue asked by darkside already for the last meeting:
- bash version in the tree  ... please crawl archives.g.o on the -dev ml
or your own archive for that.


-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
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: 197 bytes --]

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 15:53 Thu 12 Feb     , Tiziano Müller wrote:
> ... and another issue asked by darkside already for the last meeting: 
> - bash version in the tree ... please crawl archives.g.o on the -dev 
> ml or your own archive for that.

To save everyone else wasting time on this, I did it:

http://archives.gentoo.org/gentoo-dev/msg_7254f04268189c86613391a2993a2805.xml

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 08:00 Thu 12 Feb     , Donnie Berkholz wrote:
> On 15:53 Thu 12 Feb     , Tiziano Müller wrote:
> > ... and another issue asked by darkside already for the last meeting: 
> > - bash version in the tree ... please crawl archives.g.o on the -dev 
> > ml or your own archive for that.
> 
> To save everyone else wasting time on this, I did it:
> 
> http://archives.gentoo.org/gentoo-dev/msg_7254f04268189c86613391a2993a2805.xml

This will come up whenever new features show up in bash, so it's not 
purely a 3.1 issue. Here are a couple of options that have been 
mentioned in earlier discussion:


Option A: Add bash dependencies to things using new features, and 
guarantee bash 3.1 on boxes doing metadata generation. This would break 
overlay users who aren't on 3.1 yet. (And will happen for new features 
in the future, too.)

Option B: bash 3.1 has been stable since April 2006. We could lock down 
on the 3.1 feature set in EAPIs 0-2 and require new EAPIs for new bash 
features. Currently, PMS is set at 3.0 rather than 3.1.


I think we should update the PMS to bash 3.1 to allow for '+=' use. I 
looked through the bash changelog, and 3.2 didn't appear to add any new 
and useful features. We should then require a new EAPI for new bash 
features.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 08:16:45 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> I think we should update the PMS to bash 3.1 to allow for '+=' use. I 
> looked through the bash changelog, and 3.2 didn't appear to add any
> new and useful features. We should then require a new EAPI for new
> bash features.

That would require GLEP 55 to provide any protection. A new EAPI on its
own wouldn't be enough.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 16:21 Thu 12 Feb     , Ciaran McCreesh wrote:
> On Thu, 12 Feb 2009 08:16:45 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > I think we should update the PMS to bash 3.1 to allow for '+=' use. I 
> > looked through the bash changelog, and 3.2 didn't appear to add any
> > new and useful features. We should then require a new EAPI for new
> > bash features.
> 
> That would require GLEP 55 to provide any protection. A new EAPI on its
> own wouldn't be enough.

What kind of protection are you talking about, and is it already in 
place for every bash feature in 3.0?

-- 
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 09:10:55 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 16:21 Thu 12 Feb     , Ciaran McCreesh wrote:
> > On Thu, 12 Feb 2009 08:16:45 -0800
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > > I think we should update the PMS to bash 3.1 to allow for '+='
> > > use. I looked through the bash changelog, and 3.2 didn't appear
> > > to add any new and useful features. We should then require a new
> > > EAPI for new bash features.
> > 
> > That would require GLEP 55 to provide any protection. A new EAPI on
> > its own wouldn't be enough.
> 
> What kind of protection are you talking about

The problem is, without GLEP 55, EAPI isn't known before the ebuild is
sourced to generate metadata. If someone uses += anywhere that older
bash looks when sourcing for metadata generation (which is not just
global scope), the package manager won't know that the EAPI says that
bash-3.1 is required for sourcing until after it's already done the
sourcing, by which point it's too late.

> and is it already in  place for every bash feature in 3.0?

The bash 3.0 transition was done before EAPIs came along, and was
handled by the old fashioned "wait for ages until we're absolutely sure
that everyone has bash 3.0 before continuing" method.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Donnie Berkholz]

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

On 17:21 Thu 12 Feb     , Ciaran McCreesh wrote:
> The problem is, without GLEP 55, EAPI isn't known before the ebuild is 
> sourced to generate metadata. If someone uses += anywhere that older 
> bash looks when sourcing for metadata generation (which is not just 
> global scope)

Where else does it look?

> the package manager won't know that the EAPI says that bash-3.1 is 
> required for sourcing until after it's already done the sourcing, by 
> which point it's too late.

OK. What could we do about this? GLEP 55 was one suggestion.


I'm seeing a lot of people shooting down suggestions, and not many 
people presenting good, workable solutions. Could we get some more of 
those on the table?

Here's basically what I've seen:

- GLEP 55 will solve all the world's problems
- Change PMS to bash 3.1, and go with the "wait a while" that we'd 
  previously done

--
Thanks,
Donnie

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

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 09:37:43 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 17:21 Thu 12 Feb     , Ciaran McCreesh wrote:
> > The problem is, without GLEP 55, EAPI isn't known before the ebuild
> > is sourced to generate metadata. If someone uses += anywhere that
> > older bash looks when sourcing for metadata generation (which is
> > not just global scope)
> 
> Where else does it look?

It has to be able to parse the file, which means it can get confused by
things that appear to older versions to be mismatched brackets, even if
they're hidden deep in some function.

> > the package manager won't know that the EAPI says that bash-3.1 is 
> > required for sourcing until after it's already done the sourcing,
> > by which point it's too late.
> 
> OK. What could we do about this? GLEP 55 was one suggestion.
>
> I'm seeing a lot of people shooting down suggestions, and not many 
> people presenting good, workable solutions. Could we get some more of 
> those on the table?

GLEP 55 *is* the good, workable solution. There still haven't been
legitimate any technical objections to it.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Alistair Bush]

Ciaran McCreesh wrote:
>>
>> I'm seeing a lot of people shooting down suggestions, and not many 
>> people presenting good, workable solutions. Could we get some more of 
>> those on the table?
> 
> GLEP 55 *is* the good, workable solution. There still haven't been
> legitimate any technical objections to it.
> 

Stick the eapi in metadata.xml may be another solution.   But I think
GLEP 55 is the proper solution.

Alistair

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Fri, 13 Feb 2009 08:01:16 +1300
Alistair Bush <ali_bush@gentoo.org> wrote:
> Stick the eapi in metadata.xml may be another solution.

That's horrible. For one, it means the package manager has to be able
to deal with XML. For two, it's adding yet another place to go for
information, which means things can very easily get out of sync. For
three, developers are going to get awfully sick of having to edit
metadata.xml for every bump they do...

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Luca Barbato]

Alistair Bush wrote:
> 
> Ciaran McCreesh wrote:
>>> I'm seeing a lot of people shooting down suggestions, and not many 
>>> people presenting good, workable solutions. Could we get some more of 
>>> those on the table?
>> GLEP 55 *is* the good, workable solution. There still haven't been
>> legitimate any technical objections to it.
>>
> 
> Stick the eapi in metadata.xml may be another solution.   But I think
> GLEP 55 is the proper solution.

http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst

Other solutions.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 12 Feb 2009 20:54:48 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
> 
> Other solutions.

...fails in exactly the same way the current solution does.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Peter Volkov]

В Чтв, 12/02/2009 в 18:03 +0000, Ciaran McCreesh пишет:
> GLEP 55 *is* the good, workable solution. There still haven't been
> legitimate any technical objections to it.

This issue was discussed already... [1]

If you and think that EAPI is meta-information then it should not be
inside file name and then it's possible to parse ebuild and get EAPI
from some defined-format line. Performance penalties can be mitigated by
some new caching (you know better than me that it's good idea to
re-implement caching in any case).

If it's not meta-information and can be put inside file name, then put
it differently, not inside extension. It "breaks current package
managers" is not an argument since it's possible to change format now
and we'll have this feature later.

We are already discussing this feature more than year. Many people
voiced concerns about .eapi extension so why don't you try fix same
issue differently? Yes it's harder and probably longer but I don't
believe it's impossible.


[1] http://archives.gentoo.org/gentoo-dev/msg_95f3b65a36aaa5aa9635a7f8cb1b7592.xml

-- 
Peter.

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 19 Feb 2009 13:06:01 +0300
Peter Volkov <pva@gentoo.org> wrote:
> В Чтв, 12/02/2009 в 18:03 +0000, Ciaran McCreesh пишет:
> > GLEP 55 *is* the good, workable solution. There still haven't been
> > legitimate any technical objections to it.
> 
> This issue was discussed already... [1]

...and there weren't any legitimate technical objections.

> If you and think that EAPI is meta-information then it should not be
> inside file name and then it's possible to parse ebuild and get EAPI
> from some defined-format line. Performance penalties can be mitigated
> by some new caching (you know better than me that it's good idea to
> re-implement caching in any case).

The only thing that can parse ebuilds is bash, and it can only do that
once it already knows the EAPI. Another cache won't solve anything
since there's no way to generate that cache to begin with -- and a
second level of cache would slow things down, not speed them up.

> We are already discussing this feature more than year. Many people
> voiced concerns about .eapi extension so why don't you try fix same
> issue differently? Yes it's harder and probably longer but I don't
> believe it's impossible.

Because all the alternatives are worse, and none of the objections to
the extension have been technical in nature. They've all been "we don't
want you to apply anti-mould paint to the rotting bikeshed because it's
only available in brown".

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Luca Barbato]

Ciaran McCreesh wrote:
> ...and there weren't any legitimate technical objections.

Beside "it doesn't solve anything". A perfect solution for non existent 
problems isn't a viable solution.

>> If you and think that EAPI is meta-information then it should not be
>> inside file name and then it's possible to parse ebuild and get EAPI
>> from some defined-format line. Performance penalties can be mitigated
>> by some new caching (you know better than me that it's good idea to
>> re-implement caching in any case).
> 
> The only thing that can parse ebuilds is bash,

False.

> Because all the alternatives are worse,

Disputed and disputable.

> and none of the objections to the extension have been technical in
> nature.

Yet most people do not care.

> They've all been "we don't want you to apply anti-mould paint to the
> rotting bikeshed because it's only available in brown".

And smells bad.

You can also replace it when/if is rotting.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Thu, 19 Feb 2009 14:30:20 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > ...and there weren't any legitimate technical objections.
> 
> Beside "it doesn't solve anything". A perfect solution for non
> existent problems isn't a viable solution.

Have you been paying any attention at all?

Without GLEP 55, we can't change global scope behaviour. This means no
per-cat/pkg eclasses, no new global scope callable functions, no
changes to inherit, no fix for the eclasses needing a particular EAPI
problem and no new bash versions.

> > The only thing that can parse ebuilds is bash,
> 
> False.

Please provide one other thing that can parse ebuilds, and demonstrate
how to use it to do metadata generation.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Peter Volkov]

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

Filename extension is a "suffix to the name of a computer file, designed
to show its format" (-- wikipedia). General format of ebuilds is bash.
Putting version of bash scripts inside filename extension just breaks
common convention people got accustomed to.

В Чтв, 19/02/2009 в 12:51 +0000, Ciaran McCreesh пишет:
> On Thu, 19 Feb 2009 13:06:01 +0300
> Peter Volkov <pva@gentoo.org> wrote:
> > If you and think that EAPI is meta-information then it should not be
> > inside file name and then it's possible to parse ebuild and get EAPI
> > from some defined-format line. Performance penalties can be mitigated
> > by some new caching (you know better than me that it's good idea to
> > re-implement caching in any case).
> 
> The only thing that can parse ebuilds is bash, and it can only do that
> once it already knows the EAPI.

You don't need to parse full bash script. You just need to get

EAPI="something"

string from there. If you wish to implement new ebuild format, e.g.
ebuilds in xml, in such a case you'll change extension on .xebuild or
whatever suits better.

> Another cache won't solve anything since there's no way to generate
> that cache to begin with -- and a second level of cache would slow
> things down, not speed them up.

I told about caching just to avoid "it's slow to get EAPI from ebuild"
argument.

> Because all the alternatives are worse, and none of the objections to
> the extension have been technical in nature. They've all been "we don't
> want you to apply anti-mould paint to the rotting bikeshed because it's
> only available in brown".

If by technical objection you mean 'explanation why technically it's
impossible or bad to implement .eapi extensions' I agree with you. It is
possible to code it and it will work. But ... again. Statement is:

Filename extension is a "suffix to the name of a computer file, designed
to show its format". General format of ebuilds is bash. Putting version
of bash scripts inside filename extension just breaks common convention
people got accustomed to. Although this is not a technical objection it
is not unimportant. Even color is important if your are talking about
things people will see/use on daily basis. I doubt you'll paint your
room in violet only because you can easy get this paint right now.

That said, technically there are other solutions for this problem, e.g.
1) it is possible to read one line of defined format from any file 2) it
is possible to make eapi inside ebuild name (foo-1.0-eapi2.ebuild), but
not as extension. Any solution, even breaking compatibility solution, we
could already start using if we had forgotten about GLEP 55 long time
ago...

Putting GLEP 55 infinite number of times on council agenda makes me feel
that this issue has something common with perpetuum mobile. At least I'd
like similar resolution from our council as the Royal Academy of
Sciences in Paris did in 1775. It's hard to tell anything new about GLEP
55 but people still don't like it, so, council, please, ban it forever
and let something else arise.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Fri, 20 Feb 2009 00:11:32 +0300
Peter Volkov <pva@gentoo.org> wrote:
> Filename extension is a "suffix to the name of a computer file,
> designed to show its format" (-- wikipedia). General format of
> ebuilds is bash. Putting version of bash scripts inside filename
> extension just breaks common convention people got accustomed to.

Ebuilds are written in a domain specific language that's built on top of
bash. Hence why we use .ebuild, not .bash... An EAPI can be thought of
as a version of that DSL, so it's just like .mp3.

> You don't need to parse full bash script. You just need to get
> 
> EAPI="something"
> 
> string from there. If you wish to implement new ebuild format, e.g.
> ebuilds in xml, in such a case you'll change extension on .xebuild or
> whatever suits better.

Except with current rules, the only way you can get that EAPI=something
string is to evaluate the entire ebuild inside a special environment
that already knows the EAPI up-front.

> > Another cache won't solve anything since there's no way to generate
> > that cache to begin with -- and a second level of cache would slow
> > things down, not speed them up.
> 
> I told about caching just to avoid "it's slow to get EAPI from ebuild"
> argument.

Uh. So you don't understand the metadata generation process at all then?

> That said, technically there are other solutions for this problem,
> e.g. 1) it is possible to read one line of defined format from any
> file

No it isn't. The only way to get the EAPI from an ebuild is to evaluate
it in an environment where EAPI is already known.

> 2) it is possible to make eapi inside ebuild name
> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even
> breaking compatibility solution, we could already start using if we
> had forgotten about GLEP 55 long time ago...

This is just the same as GLEP 55, except that it breaks current package
managers and is more typing. In other words, it's a bad solution.

> Putting GLEP 55 infinite number of times on council agenda makes me
> feel that this issue has something common with perpetuum mobile. At
> least I'd like similar resolution from our council as the Royal
> Academy of Sciences in Paris did in 1775. It's hard to tell anything
> new about GLEP 55 but people still don't like it, so, council,
> please, ban it forever and let something else arise.

GLEP 55 is necessary, and there *still* haven't been any legitimate
technical objections to it, nor have there been any viable alternatives
proposed.

-- 
Ciaran McCreesh

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

[gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009

[Ryan Hill]

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

On Fri, 20 Feb 2009 00:11:32 +0300
Peter Volkov <pva@gentoo.org> wrote:

> That said, technically there are other solutions for this problem,
> e.g. 1) it is possible to read one line of defined format from any
> file 2) it is possible to make eapi inside ebuild name
> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even
> breaking compatibility solution, we could already start using if we
> had forgotten about GLEP 55 long time ago...

I really don't understand why foo-0.1.eapi3.ebuild is considered an
acceptable solution and foo-0.1.ebuild.eapi3 is not.

They have the same advantages, arguments about aesthetics aside, and
seem to be a much cleaner solution than any other that has been
proposed.  But the former has one distinct disadvantage that the latter
does not:  any currently released version of portage does not work
correctly with ebuilds having version suffixes it does not recognize.
For example, you cannot currently create a Manifest in a package
directory containing a file named package-1.0.eapi3.ebuild.

We can modify portage, of course, to recognize this suffix, and then
wait long enough for that release to trickle down.  But later, if we
want to add another suffix, -scm perhaps, or something we
haven't considered yet, we again have to go through the same process. I
thought the reason we introduced EAPI was to free us from this.

It may seem a minor gripe, but it doesn't take much imagination to come
up with other scenarios where this could become a bigger problem.  

With a format such as .ebuild.eapiX we would avoid these issues.
Portage (without any modifications) will not recognize these files as
ebuilds (which is exactly the behaviour we want if it doesn't
understand the EAPI), so the format of the version string is moot.  We
could introduce -scm (or whatever) in EAPI X, and be able to use it
immediately.

Your argument that the .ebuild file suffix is required by convention
does not hold water.  Ebuilds are not bash scripts.  They are
specialized scripts for package management that happen to be written
in bash ;).  You make the point yourself that if you wanted to implement
a new ebuild format or change the language ebuilds are written in, you
would change the extension to something else.  I'd like to argue that
we've already done so twice and I hear number 3 is coming real soon now.

> Putting GLEP 55 infinite number of times on council agenda makes me
> feel that this issue has something common with perpetuum mobile. At
> least I'd like similar resolution from our council as the Royal
> Academy of Sciences in Paris did in 1775. It's hard to tell anything
> new about GLEP 55 but people still don't like it, so, council,
> please, ban it forever and let something else arise.

I'm sorry, but until you come up with a better reason than "it's
tradition", I'm afraid this will continue to be submitted indefinitely.
You will have to provide technical objections why this approach is
unacceptable before anyone can come up with something that is.

Here is an example, to get you started:
If a Manifest is generated using a portage version that supports an
EAPI and recognizes a package atom containing a version suffix that
was added in that EAPI as an ebuild and thus categorizes it as EBUILD in
the Manifest, do portage versions that do not support the EAPI have
trouble when they see the entry marked EBUILD for a package atom they
think is invalid?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009

[Luca Barbato]

Ryan Hill wrote:
> On Fri, 20 Feb 2009 00:11:32 +0300
> Peter Volkov <pva@gentoo.org> wrote:
> 
>> That said, technically there are other solutions for this problem,
>> e.g. 1) it is possible to read one line of defined format from any
>> file 2) it is possible to make eapi inside ebuild name
>> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even
>> breaking compatibility solution, we could already start using if we
>> had forgotten about GLEP 55 long time ago...
> 
> I really don't understand why foo-0.1.eapi3.ebuild is considered an
> acceptable solution and foo-0.1.ebuild.eapi3 is not.

I guess that principle of the least surprise counts there.

> They have the same advantages, arguments about aesthetics aside, and
> seem to be a much cleaner solution than any other that has been
> proposed.

Using either manifests and or switch sync path is even less invasive if 
you consider that point raised against the proposal to switch extensions 
every time something changes in the ebuild format is that is misleading.

> But the former has one distinct disadvantage that the latter
> does not:  any currently released version of portage does not work
> correctly with ebuilds having version suffixes it does not recognize.
> For example, you cannot currently create a Manifest in a package
> directory containing a file named package-1.0.eapi3.ebuild.

Portage should warn/die if stray files are present. So the whole thing 
looks to me as a way to harness a bug.

> We can modify portage, of course, to recognize this suffix, and then
> wait long enough for that release to trickle down.  But later, if we
> want to add another suffix, -scm perhaps, or something we
> haven't considered yet, we again have to go through the same process. I
> thought the reason we introduced EAPI was to free us from this.

As stated before this eapi had been considered a ugly solution looking 
for problems to solve.

> With a format such as .ebuild.eapiX we would avoid these issues.

Using manifest to have portage validate/invalidate ebuilds works as well 
and is completely transparent.

> Portage (without any modifications) will not recognize these files as
> ebuilds (which is exactly the behaviour we want if it doesn't
> understand the EAPI), so the format of the version string is moot.  We
> could introduce -scm (or whatever) in EAPI X, and be able to use it
> immediately.


> I'm sorry, but until you come up with a better reason than "it's
> tradition", I'm afraid this will continue to be submitted indefinitely.
> You will have to provide technical objections why this approach is
> unacceptable before anyone can come up with something that is.

Usually in order to get something changed is the burden of the 
proponents make it worthy for everybody else. Moreover if the change 
causes any annoyance, its usefulness has to be considered superior to 
the damage. We got people that annoyed about this proposal that they 
stated they'll quit if it is passed.

> Here is an example, to get you started:
> If a Manifest is generated using a portage version that supports an
> EAPI and recognizes a package atom containing a version suffix that
> was added in that EAPI as an ebuild and thus categorizes it as EBUILD in
> the Manifest, do portage versions that do not support the EAPI have
> trouble when they see the entry marked EBUILD for a package atom they
> think is invalid?

Manifest2 is backward compatible to manifest1 by ignoring lines it 
couldn't parse, so if we have portage embed the eapi information there 
we'd archive the same result being completely transparent.

This proposal is in the migration-paths document, why we shouldn't use a 
less invasive approach, that is using pretty much the same principle but 
   doesn't have the shortcoming the extension rename ?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009

[Ciaran McCreesh]

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

On Mon, 23 Feb 2009 00:37:47 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Using either manifests

...which doesn't solve the metadata generation problem at all, and
which doesn't work with existing package managers...

> and or switch sync path is even less invasive

...which goes against the whole point of inventing EAPI, and which
makes the upgrade path a regular pain in the ass...

> if you consider that point raised against the proposal to switch
> extensions every time something changes in the ebuild format is that
> is misleading.

How is it misleading? It shows exactly what's going on.

> > But the former has one distinct disadvantage that the latter
> > does not:  any currently released version of portage does not work
> > correctly with ebuilds having version suffixes it does not
> > recognize. For example, you cannot currently create a Manifest in a
> > package directory containing a file named package-1.0.eapi3.ebuild.
> 
> Portage should warn/die if stray files are present. So the whole
> thing looks to me as a way to harness a bug.

Portage already can't generate manifests correctly if it doesn't support
all EAPIs present... This is obvious; why do you bring up such a
blatantly irrelevant argument?

> As stated before this eapi had been considered a ugly solution
> looking for problems to solve.

As stated before, you're talking nonsense. Which part of the long list
of problems it was created to solve don't you understand?

> > With a format such as .ebuild.eapiX we would avoid these issues.
> 
> Using manifest to have portage validate/invalidate ebuilds works as
> well and is completely transparent.

...and doesn't solve the metadata generation problem, nor does it work
with existing package managers.

> Usually in order to get something changed is the burden of the 
> proponents make it worthy for everybody else. Moreover if the change 
> causes any annoyance, its usefulness has to be considered superior to 
> the damage. We got people that annoyed about this proposal that they 
> stated they'll quit if it is passed.

Boo frickin' hoo. It's a technical necessity, and a few malcontents
threatening to throw their toys out of the pram need to be told to grow
up and deal with reality.

> This proposal is in the migration-paths document, why we shouldn't
> use a less invasive approach, that is using pretty much the same
> principle but doesn't have the shortcoming the extension rename ?

Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.

-- 
Ciaran McCreesh

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

Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato]

Ciaran McCreesh wrote:
> Because your proposal addresses none of the underlying problems which
> GLEP 55 was created to solve.

As said long ago the glep doesn't tell enough:

"The current way of specifying the EAPI in ebuilds is flawed. In order 
to get the EAPI the package manager needs to source the ebuild, which 
itself needs the EAPI in the first place. Otherwise it imposes a serious 
limitation, namely every ebuild, using any of the future EAPIs, will 
have to be source'able by old package managers and hence there is no way 
to do any of the following:

         * Change the behaviour of inherit in any way (for example, to 
extend or change eclass functionality).
         * Add new global scope functions in any sane way.
         * Extend versioning rules in an EAPI - for example, addition of 
the scm suffix - GLEP54"

Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the ones showing an eapi it understands
- keeps going.

Apparently we do not have any issue...

Now problems:
1- the cache could get a non compatible change
2- the user triggers a metadata cache regeneration
    -> the ebuild is sourced -> portage could fail or do something 
unpredictable
3- overlays do not provide metadata cache
4- A package manager different from portage do not use the provided cache.

Solutions:
1- move the incompatible cache out of ancient portage scope (like in a 
separate directory)
2- The user will get unpredictable behavior, but portage tell you when 
upgrading is needed...
3- you'd have to disable them
4- unsupported.

Apparently for this side we don't have much to do if we get a valid cache.

Ebuilds have to be added to portage so here the workflow for the developer:

- new ebuild is sourced
- cache is generated
- manifest is built

In this case we have a problem if the source step is a single one, 
portage won't know in advance how to behave.

So the first step has to be split in two:
- first portage discovers which is the eapi version
- then behave as defined by the eapi

The problem is that right now sourcing is done by having an instructed 
bash. So the simplest way to get the first step done is parsing the 
ebuild file with something different like file(1) and then instruct bash 
and do the parsing.

This will solve the issue for the developer.

What is proposed in glep-55 seems to aim to solve both issues at the 
same time (it isn't stated) by switching file extension every time the 
eapi is changed. This is slightly against the principle of the least 
surprise and apparently is disliked by enough people to lead the 
situation to be discussed in the council.

The fact the glep itself is too much terse doesn't help acknowledging 
the problems it aims to solve and the fact it fails to state actual 
issues that may need a solution doesn't make it worth the effort and 
disruption it would lead.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Tiziano Müller]

> What is proposed in glep-55 seems to aim to solve both issues at the 
> same time (it isn't stated) by switching file extension every time the 
> eapi is changed. This is slightly against the principle of the least 
> surprise and apparently is disliked by enough people to lead the 
> situation to be discussed in the council.
> 

Instead of switching file extension every time the eapi is changed you
could also increment it only when a new EAPI breaks sourcing the ebuild
compared to the requirements of the prior EAPI.
(This way you'd in fact split EAPI into a major- and a minor-version.)

Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato]

Tiziano Müller wrote:
>> What is proposed in glep-55 seems to aim to solve both issues at the 
>> same time (it isn't stated) by switching file extension every time the 
>> eapi is changed. This is slightly against the principle of the least 
>> surprise and apparently is disliked by enough people to lead the 
>> situation to be discussed in the council.
>>
> 
> Instead of switching file extension every time the eapi is changed you
> could also increment it only when a new EAPI breaks sourcing the ebuild
> compared to the requirements of the prior EAPI.
> (This way you'd in fact split EAPI into a major- and a minor-version.)

Makes you getting to have to do the two stage source again AND you get 
another non obvious condition "Should I bump the eapi internally or the 
filename?"

The main point again what is proposed in glep-55 is it that isn't 
invasive and non-transparent to users and developers.

As stated in the analysis, the user side is already covered by the fact 
users use the cache, the developer side would require a two stage 
sourcing when committing to remain transparent.

What we need to balance is if the invasive proposal is simpler than 
having a two stage sourcing done.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Thomas Anderson]

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

On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
> Tiziano M??ller wrote:
>>> What is proposed in glep-55 seems to aim to solve both issues at the same 
>>> time (it isn't stated) by switching file extension every time the eapi is 
>>> changed. This is slightly against the principle of the least surprise and 
>>> apparently is disliked by enough people to lead the situation to be 
>>> discussed in the council.
>>>
>> Instead of switching file extension every time the eapi is changed you
>> could also increment it only when a new EAPI breaks sourcing the ebuild
>> compared to the requirements of the prior EAPI.
>> (This way you'd in fact split EAPI into a major- and a minor-version.)
>
> Makes you getting to have to do the two stage source again AND you get 
> another non obvious condition "Should I bump the eapi internally or the 
> filename?"

The glep is quite clear on that point.

> The main point again what is proposed in glep-55 is it that isn't invasive 
> and non-transparent to users and developers.

It's not all that invasive. All that changes is that the EAPI goes at
the end of the filename and you don't set it in the ebuild. Developers
should be able to keep up with this, and if a user asks it's easy enough
to say that "it's a new version of ebuild, it has newer features see
www.blah.org/blah for details". And really, users already ask what EAPI
is so it's not that much headache.

-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

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

Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

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

On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Let's try to start with a common workflow for the user:
> - an user with an ancient version of portage syncs
> - it requires a package
> - it looks at the cache ($portdir/metadata/cache/)
> - picks the best entry from the ones showing an eapi it understands
> - keeps going.
> 
> Apparently we do not have any issue...

...assuming the metadata cache is valid. That isn't always the case.

> 2- The user will get unpredictable behavior, but portage tell you
> when upgrading is needed...

Not if the version you'd need to do metadata generation is ~arch it
doesn't.

> 3- you'd have to disable them

Yes, tell everyone to disable all the overlays that make use of a few
features only in ~arch package managers... That'll work...

> In this case we have a problem if the source step is a single one, 
> portage won't know in advance how to behave.
> 
> So the first step has to be split in two:
> - first portage discovers which is the eapi version

...which it can't do, because it doesn't know the EAPI.

> The problem is that right now sourcing is done by having an
> instructed bash. So the simplest way to get the first step done is
> parsing the ebuild file with something different like file(1) and
> then instruct bash and do the parsing.

file(1) can't parse ebuilds. Only an ebuild implementation can parse
ebuilds, and only if it already knows the EAPI.

> What is proposed in glep-55 seems to aim to solve both issues at the 
> same time (it isn't stated) by switching file extension every time
> the eapi is changed. This is slightly against the principle of the
> least surprise and apparently is disliked by enough people to lead
> the situation to be discussed in the council.

There's no surprise at all. It's extremely clear.

-- 
Ciaran McCreesh

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

Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 03:15:03 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Let's try to start with a common workflow for the user:
>> - an user with an ancient version of portage syncs
>> - it requires a package
>> - it looks at the cache ($portdir/metadata/cache/)
>> - picks the best entry from the ones showing an eapi it understands
>> - keeps going.
>>
>> Apparently we do not have any issue...
> 
> ...assuming the metadata cache is valid. That isn't always the case.

When it isn't?

>> 2- The user will get unpredictable behavior, but portage tell you
>> when upgrading is needed...
> 
> Not if the version you'd need to do metadata generation is ~arch it
> doesn't.

...

>> 3- you'd have to disable them
> 
> Yes, tell everyone to disable all the overlays that make use of a few
> features only in ~arch package managers... That'll work...

disable overlays to UPGRADE to the new portage. Not rocket science...

>> In this case we have a problem if the source step is a single one, 
>> portage won't know in advance how to behave.
>>
>> So the first step has to be split in two:
>> - first portage discovers which is the eapi version
> 
> ...which it can't do, because it doesn't know the EAPI.

If you are generating the cache you must have a way to know it...

>> The problem is that right now sourcing is done by having an
>> instructed bash. So the simplest way to get the first step done is
>> parsing the ebuild file with something different like file(1) and
>> then instruct bash and do the parsing.
> 
> file(1) can't parse ebuilds.

file parses quite well avi and mov, ebuild will be anytime more complex 
than that right?

Anyway it isn't a problem since the version of portage doing the work is 
supposed to be up to date, if isn't it will be updated first using the 
normal user workflow that has already been covered by the cache.

> Only an ebuild implementation can parse
> ebuilds, and only if it already knows the EAPI.

That is always the case since you are adding an ebuild and you are 
supposed to have an up to date portage in order to do that.

>> What is proposed in glep-55 seems to aim to solve both issues at the 
>> same time (it isn't stated) by switching file extension every time
>> the eapi is changed. This is slightly against the principle of the
>> least surprise and apparently is disliked by enough people to lead
>> the situation to be discussed in the council.
> 
> There's no surprise at all. It's extremely clear.

Not that much.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh]

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

On Mon, 23 Feb 2009 15:46:24 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Apparently we do not have any issue...
> > 
> > ...assuming the metadata cache is valid. That isn't always the case.
> 
> When it isn't?

Every now and again (probably after someone changes eutils...), rsync
mirrors end up shipping a load of stale metadata for parts of the tree.
Portage users probably don't notice, since it just causes a slowdown.

> disable overlays to UPGRADE to the new portage. Not rocket science...

No no. You're forcing people to switch to ~arch to be able to use
overlays.

> >> In this case we have a problem if the source step is a single one, 
> >> portage won't know in advance how to behave.
> >>
> >> So the first step has to be split in two:
> >> - first portage discovers which is the eapi version
> > 
> > ...which it can't do, because it doesn't know the EAPI.
> 
> If you are generating the cache you must have a way to know it...

No, we don't. That's the entire frickin' point of GLEP 55, and one
that you would do well to understand fully before commenting further.
The way we generate metadata now is massively horrible, and only works
because there aren't any serious global scope differences between
EAPIs. We can't make any global scope changes to future EAPIs because
it breaks current metadata generation. Right now it's safe to pretend
EAPI 0 until the real EAPI is worked out, but that won't hold in the
future -- as soon as global scope changes come along, there's no safe
EAPI that can be assumed, even if we didn't have to worry about
breaking existing package managers.

> >> The problem is that right now sourcing is done by having an
> >> instructed bash. So the simplest way to get the first step done is
> >> parsing the ebuild file with something different like file(1) and
> >> then instruct bash and do the parsing.
> > 
> > file(1) can't parse ebuilds.
> 
> file parses quite well avi and mov, ebuild will be anytime more
> complex than that right?

It's already *way* more complicated than that. Extracting metadata
requires a full bash 3 implementation along with a considerable amount
of supporting code.

> Anyway it isn't a problem since the version of portage doing the work
> is supposed to be up to date, if isn't it will be updated first using
> the normal user workflow that has already been covered by the cache.

Most users don't run ~arch, and do use overlays. So no, this will affect
normal user workflow.

> > Only an ebuild implementation can parse
> > ebuilds, and only if it already knows the EAPI.
> 
> That is always the case since you are adding an ebuild and you are 
> supposed to have an up to date portage in order to do that.

Again, you're not getting it. Doesn't matter how up to date your
package manager is. You can't find out the EAPI unless you already know
the EAPI.

> >> What is proposed in glep-55 seems to aim to solve both issues at
> >> the same time (it isn't stated) by switching file extension every
> >> time the eapi is changed. This is slightly against the principle
> >> of the least surprise and apparently is disliked by enough people
> >> to lead the situation to be discussed in the council.
> > 
> > There's no surprise at all. It's extremely clear.
> 
> Not that much.

How is '.ebuild-3' being used to specify version 3 of the ebuild format
in the least bit surprising?

-- 
Ciaran McCreesh

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