Re: [gentoo-dev] A few questions to our nominees
On Sat, 14 Jun 2008 10:38:18 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Ignoring possible semantic issues for the moment, Please point them so I could fix them properly ^^ For example all the ordering issues pointed out by others in this thread. Also the whole 'template' approach is likely going to introduce a number of issues. And as your proposal is lacking a lot of details more problems will come up over time. Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. After some discussions with dev-zero, I think we'll need a new phase, possibly trigged by maint, before I was thinking about adding it to sync. What exactly do you mean with 'maint'? Plus it has similar (unstated) transition issues as GLEP-54, just avoids a new comparison algorithm and the CPV vs. atom issue. Hmm, give me more informations about your concern. Simply how would you actually introduce this stuff without breaking existing setups? Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26. This
is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0.26, once
0.26 gets in portage you want to update to the release.
* How are you planning to handle reinstalls? Should installing world
always reinstall live things? Never? Or what?
depends on the other ebuilds
More specifically?
the live ebuild act as template for a autogenerated _pre, if there is
something higher than _pre that one will be picked.
* How are live ebuilds selected by the package manager?
live ebuilds gets considered as preN+1 for any purpose.
So you're saying they *always* get reinstalled as a new version if
they're part of the dep tree?
only on -e since you do not have the live template evaluated again.
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
And when trunk is unversioned?
Upstream has an issue, still you know which is the version they aim.
live ebuild for SVN branches/0.26/?
foo-0.26.live?
Orders incorrectly when 0.26.1 has been released.
no.
What is inside the template is just concern of the ebuild writer. I
suggest to use the same version as marked in the configure or other
version value the release will get once upstream decides to release.
There's no way of getting the desired effect with current dep specs.
Your comment seems unrelated to the text.
Anyway pkgcore and portage devs, I'd like your opinion on this point.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 13 Jun 2008, at 10:43, Luca Barbato wrote:
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
And when trunk is unversioned?
Upstream has an issue, still you know which is the version they aim.
Wrong. Your GLEP has an issue because it isn't able to cover a real-
world case. See the pu branch in Git.
- ferdy
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26.
This is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0.26,
once 0.26 gets in portage you want to update to the release.
A lot of projects work like this:
* trunk/ is current development, and is ahead of any release.
* branches/0.26/ is forked from trunk/ when 0.26 is released, and is
equal to or ahead of any 0.26 release.
How does your proposal handle this?
* How are you planning to handle reinstalls? Should installing
world always reinstall live things? Never? Or what?
depends on the other ebuilds
More specifically?
the live ebuild act as template for a autogenerated _pre, if there is
something higher than _pre that one will be picked.
So you install foo-1.2-live. The package manager installs this as
foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2.
Which has two issues:
* It means whenever you install foo-1.2-live, there will always be a
newer version, and the package manager will always select it for
upgrades. Is this really desired behaviour?
* It means the package manager somehow has to keep track of what pre to
substitute in. How does it do this?
* How are live ebuilds selected by the package manager?
live ebuilds gets considered as preN+1 for any purpose.
So you're saying they *always* get reinstalled as a new version if
they're part of the dep tree?
only on -e since you do not have the live template evaluated again.
So when are templates evaluated?
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
And when trunk is unversioned?
Upstream has an issue, still you know which is the version they aim.
Again, no. It's fairly common for unversioned trunk where upstream
don't yet know if it'll be released as an x release, an x.y release or
an x.y.z release.
live ebuild for SVN branches/0.26/?
foo-0.26.live?
Orders incorrectly when 0.26.1 has been released.
no.
Yup, because your 0.26 branch will be equal to or ahead of 0.26.1, but
0.26.live will order as less than 0.26.
Anyway pkgcore and portage devs, I'd like your opinion on this point.
What, the gaping holes I've pointed out aren't enough?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Fri, Jun 13, 2008 at 10:43:39AM +0200, Luca Barbato wrote: Anyway pkgcore and portage devs, I'd like your opinion on this point. Custom repository is how I intended to implement this; the upshot of the version translation is that the resultant vdb version is managable by any PM, regardless if they support -live, which 'generated' the ebuild. Presuming svn python bindings aren't as sucky as I recall, tempted to take a thwack at it over the weekend. One thing that would need ironing out for such a proposal is how to mark in the template metadata variation dependant upon vcs exceeding a certain level- example would be, revno 300 RDEPEND='=dev-lang/python-2.4*' = revno 300 RDEPEND='=dev-lang/python-2.5' That... gets tricky. I can think of hacks for it, but none I like. Alternatively, if there was a way to have seperate templates that are selected dependant upon the desired rev, it becomes possible. One other thing that needs discussion imo, is how such a scheme would work for non integer based revnos- git for example, which is reliant on a hash (just the hash, afaik). Either way, I tend to view it as having a fair bit more control then the -scm proposal, although needs fleshing out a bit. ~harring pgprRkNRVBKzy.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Fri, 13 Jun 2008 04:14:38 -0700 Brian Harring [EMAIL PROTECTED] wrote: One other thing that needs discussion imo, is how such a scheme would work for non integer based revnos- git for example, which is reliant on a hash (just the hash, afaik). Neither Luca's proposal nor -scm even attempts to address anything to do with upstream revisions. Whilst doing so would be useful, it's considerably more work. There's another proposal floating around that lets -scm be extended to deal with upstream revisions too, but from an amount-of-work perspective it's highly unlikely that Portage will be able to deliver that stage of it any time soon -- the -scm proposal is designed to fit in nicely with the way ebuilds currently handle live packages, whilst not requiring much effort to implement. Being realistic here, -scm is something that's deliverable and useful in a relatively short timeframe, but extending it to upstream-revision awareness isn't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Brian Harring wrote: Custom repository is how I intended to implement this; the upshot of the version translation is that the resultant vdb version is managable by any PM, regardless if they support -live, which 'generated' the ebuild. Presuming svn python bindings aren't as sucky as I recall, tempted to take a thwack at it over the weekend. Would be great =) One thing that would need ironing out for such a proposal is how to mark in the template metadata variation dependant upon vcs exceeding a certain level- example would be, revno 300 RDEPEND='=dev-lang/python-2.4*' = revno 300 RDEPEND='=dev-lang/python-2.5' That would be quite tricky and I'm not sure how many time it will be useful since we don't know the future this well ^^; I'd leave this part out for now. One other thing that needs discussion imo, is how such a scheme would work for non integer based revnos- git for example, which is reliant on a hash (just the hash, afaik). The revision has to be stored inside the generated ebuild so all you need to have is: - a way to know the revision you are checking out - a way to store such revision withing the ebuild lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Fri, 13 Jun 2008 13:32:47 +0200 Luca Barbato [EMAIL PROTECTED] wrote: The revision has to be stored inside the generated ebuild so all you need to have is: - a way to know the revision you are checking out - a way to store such revision withing the ebuild - a way of doing this cheaply so resolution doesn't take half an hour when you have kde-scm installed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Thu, 12 Jun 2008 11:05:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 Just for fun I took some of the ideas about alternative management of the issue and specified the features it makes it worth changing (better management and automated snapshot generation from the live ebuild). http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst I'd like to see some comment on it (I put it in glep form just now so it isn't exactly perfect) Ignoring possible semantic issues for the moment, I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. Plus it has similar (unstated) transition issues as GLEP-54, just avoids a new comparison algorithm and the CPV vs. atom issue. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 Just for fun I took some of the ideas about alternative management of the issue and specified the features it makes it worth changing (better management and automated snapshot generation from the live ebuild). http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst I'd like to see some comment on it (I put it in glep form just now so it isn't exactly perfect) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Thu, 12 Jun 2008 11:05:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Just for fun I took some of the ideas about alternative management of the issue and specified the features it makes it worth changing (better management and automated snapshot generation from the live ebuild). http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst I'd like to see some comment on it (I put it in glep form just now so it isn't exactly perfect) * ordering for _pre is wrong. * How are you planning to handle reinstalls? Should installing world always reinstall live things? Never? Or what? * How are live ebuilds selected by the package manager? * What's the filename for live ebuild for SVN trunk/? What about live ebuild for SVN branches/0.26/? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Just for fun I took some of the ideas about alternative management of
the issue and specified the features it makes it worth changing
(better management and automated snapshot generation from the live
ebuild).
http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
I'd like to see some comment on it (I put it in glep form just now so
it isn't exactly perfect)
* ordering for _pre is wrong.
hm?
* How are you planning to handle reinstalls? Should installing world
always reinstall live things? Never? Or what?
depends on the other ebuilds
* How are live ebuilds selected by the package manager?
live ebuilds gets considered as preN+1 for any purpose.
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
live ebuild for SVN branches/0.26/?
foo-0.26.live?
What is inside the template is just concern of the ebuild writer. I
suggest to use the same version as marked in the configure or other
version value the release will get once upstream decides to release.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: Anyone thinking that has a very limited understanding of how things work. Usually in this category you put everybody that disagrees with you, no matter the topic. Let's face it, there hasn't been any correct criticism, and any complaints have been from people who don't understand what's going on anyway and who seek to blame EAPI for Portage's lack of progress, rather than blaming Portage's lack of progress for lack of new EAPIs as they should. I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Anyone thinking that has a very limited understanding of how things work. Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? All I've received are some vague mutterings about how it should be less formal, some vague mutterings about how it should be more formal, some incoherent rants about how it's in some way unreadable and no actual specifics. All in all, something that looks suspiciously like I don't have any genuine objections but like to moan... So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? Probably because you have such a long history of saying it's broken without providing any details. Even when asked you sometimes choose to ignore the question. How does it feel to be on the receiving end for a chance? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? And what does that tell you about how well you fit this community ? So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? See above. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008 09:26:00 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? Probably because you have such a long history of saying it's broken without providing any details. Even when asked you sometimes choose to ignore the question. How does it feel to be on the receiving end for a chance? No, Roy, no. You're confusing you not understanding the explanation of, say, exploitable security holes in openrc with you not being told about them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008 10:28:57 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? And what does that tell you about how well you fit this community ? Are you suggesting that Gentoo *should* be a community of people who don't really know what they're doing who base their work upon things they half understand that they think they can change without having to think about the consequences? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 10:50, Luca Barbato wrote: Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu And how specifically is this going to help? You are missing the 'provide details' part. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. From a package manager implementer's perspective, that's a mess. It means looking all over the place to find relevant information on, say, what a package dep spec looks like. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. It is less ambiguous than natural language. That solves the issue The syntax is underspecified lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
So how, specifically, is PMS wrongly written, and why hasn't
anyone who thinks so bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook,
guidexml.
What technical reason is there to use a markup that's more work for
those of us doing the writing? Writing XML is a huge pain in the ass
compared to latex.
More people can understand those markups
I've yet to see anyone have any difficulties with Tex.
they are consistent with the gentoo documentation
GuideXML can't even begin to cover our requirements. Simple example:
try to rewrite the following in GuideXML:
---START---
Global variables must only contain invariant values
(see~\ref{metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
This is demonstrated by code listing~\ref{lst:env-saving}.
\lstinputlisting[float,caption=Environment state between
functions,label=lst:env-saving]{env-saving.listing}
---END---
they look better on screen than on paper
That's highly questionable. And PMS is sufficiently long that printing
it out is the easiest way of reading it, no matter what format it's in.
tex is a great typesetting markup to write academic books. Right tool
for the right task. It address the problem PMS is anything but
accessible
How does making PMS twice the file size and five times as complicated to
edit make it more accessible?
- use EBNF when describing a syntax.
Is there any indication that this is any clearer? EBNF gets messy
when it comes to describing the whitespace rules, for example.
It is less ambiguous than natural language. That solves the issue
The syntax is underspecified
In what places is the syntax currently underspecified, and in said
places, why is EBNF a better solution that tightening up the existing
language? Please illustrate your answer with real examples.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
So how, specifically, is PMS wrongly written, and why hasn't
anyone who thinks so bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook,
guidexml.
What technical reason is there to use a markup that's more work for
those of us doing the writing? Writing XML is a huge pain in the ass
compared to latex.
More people can understand those markups
I've yet to see anyone have any difficulties with Tex.
they are consistent with the gentoo documentation
GuideXML can't even begin to cover our requirements. Simple example:
try to rewrite the following in GuideXML:
---START---
Global variables must only contain invariant values
(see~\ref{metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
This is demonstrated by code listing~\ref{lst:env-saving}.
\lstinputlisting[float,caption=Environment state between
functions,label=lst:env-saving]{env-saving.listing}
---END---
Let's change all that hideous, barely readable multiple brace/bracket
abuse into something more human-readable, shall we?
---
p
Global variables must only contain invariant values (see uri
link=#metadata-invariancelink/uri). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
/p
p
This is demonstrated by the following:
/p
pre caption=Environment state between functions id=env-saving
bunch o'neat code
/pre
---
Oh, and that id is entirely optional; GuideXML is smart enough to keep
track of successive code blocks, so you automatically have numerical
inter/intra document links, as I'll demonstrate at the end of this email.
GuideXML has moved on, while you seem to be stuck in the past. For
example, look at all the neat things we can do especially for ebuild
syntax highlighting.[1] Might want to read the rest of that document,
while you're at it.
Thanks for playing; you lose.
[1] http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
On Monday 09 June 2008 11:28:03 Josh Saddler wrote: Let's change all that hideous, barely readable multiple brace/bracket abuse into something more human-readable, shall we? Please explain why angle brackets are readable but braces aren't. pre caption=Environment state between functions id=env-saving bunch o'neat code /pre Wow, you mean we just type in bunch o'neat code and the GuideXML processor magically figures out what we want and does it? That's amazing, you've really convinced me! I'm sure we'll have this checked into the repo in no time. Thanks for playing; you lose. LOL -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Pointless nit. Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. your opinion, just yours. Third, you should have a non-breaking space between 'see' and the reference. Pointless nit. How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. As usual for xml markups. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 09-06-2008 11:49:35 +0200, Luca Barbato wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible I think this is a bit of a pointless discussion. If people insist on reading the source and are scared of LaTeX, then the same can happen for any other language. PMS is available as pdf (or can easily being made by typing `make`), which is readable IMO, and one could always try how far one gets with a LaTeX-XML translator and XSLT transformations afterwards. Still, what is the point of requiring language X over Y? I for one prefer LaTeX over any of the formats you mentioned before, but that should not be of any value here. - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. It is less ambiguous than natural language. That solves the issue The syntax is underspecified Perhaps some examples showing the syntax could improve the situation here? -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 12:56:33 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Pointless nit. No, extremely important point. With PMS we can have things split over lots of files, and not have to care what file something's in when we link to it. This means we can move things around between files, not have to worry about breaking links, and be told automatically if we do screw up a link. How do we get this using GuideXML? Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. your opinion, just yours. It's really not. Please point me to professional style guides that do reference links using link as the text. Also see http://www.w3.org/QA/Tips/noClickHere . Third, you should have a non-breaking space between 'see' and the reference. Pointless nit. You're the one that wants good, readable output. How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. As usual for xml markups. Which is what? You have to manually copy the source content into the XML document, fixing the code yourself? Or come up with some convoluted build scripts to do it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler [EMAIL PROTECTED] wrote: p Global variables must only contain invariant values (see uri link=#metadata-invariancelink/uri). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. /p First, your link is incorrect. metadata-invariance is in a different file. Second, the link's text should be the section name or chapter number. Rendered as (see link) is horribly ugly. Third, you should have a non-breaking space between 'see' and the reference. p This is demonstrated by the following: /p pre caption=Environment state between functions id=env-saving bunch o'neat code /pre How does bunch o'neat code deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 09, 2008 at 01:00:52PM +0200, Fabian Groffen wrote: On 09-06-2008 11:49:35 +0200, Luca Barbato wrote: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato [EMAIL PROTECTED] wrote: So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem PMS is anything but accessible I think this is a bit of a pointless discussion. If people insist on reading the source and are scared of LaTeX, then the same can happen for any other language. PMS is available as pdf (or can easily being made by typing `make`), which is readable IMO, and one could always try how far one gets with a LaTeX-XML translator and XSLT transformations afterwards. Still, what is the point of requiring language X over Y? I for one prefer LaTeX over any of the formats you mentioned before, but that should not be of any value here. ++ I personally have had no problems reading and/or understanding PMS, and I've had to reference a fair bit of it. I'd like to hear exactly who has problems with what sections and how to fix that. As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's perogative. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. Regards, Thomas pgphJhgm1mXuT.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 9 Jun 2008, at 14:18, Luca Barbato wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Your opinion. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Pointless nit. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 09 Jun 2008 14:18:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Are you seriously suggesting that hypothetical contributions we might receive from people who hypothetically might contribute if only we used XML instead of Latex outweigh all the extra work XML requires? You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. The PDF spec requires that PDF readers have certain fonts available, and those're the fonts we're using. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 09, 2008 at 01:26:53PM +0100, Ciaran McCreesh wrote: On Mon, 09 Jun 2008 14:18:01 +0200 Luca Barbato [EMAIL PROTECTED] wrote: The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Are you seriously suggesting that hypothetical contributions we might receive from people who hypothetically might contribute if only we used XML instead of Latex outweigh all the extra work XML requires? Right, and though I don't understand LaTeX all that well, it wasn't too difficult to stop me from writing the spec for one function. I personally dislike XML even more than LaTeX, but that shouldn't stop those who wrote it from using it. pgpNVKiLPgC4x.pgp Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Mon, 2008-06-09 at 14:18 +0200, Luca Barbato wrote: Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. Untrue... latex is documented, and lots of people feel more comfortable with it than with XML (for example me). It's just a matter of taste and thus a decision of the people actually doing the work. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Install app-text/evince. It looks quite nice there. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A few questions to our nominees
On Sun, 8 Jun 2008 12:27:52 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: The current council has raised never actually deciding anything to an art form. Barking up the wrong (portage) tree again? Kindest regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: I personally have had no problems reading and/or understanding PMS, and I've had to reference a fair bit of it. I'd like to hear exactly who has problems with what sections and how to fix that. As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's perogative. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. For those that don't know me, I'm a member of the Documentation Team. I also have some background with XSLT (not as huge as neysx, our leader, has, but still I'm not really a begginer in this area). That said, I completely agree with the choice of latex in this particular case. If there was a fixed request on GudeXML, this document would not have been at all written yet. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
Luca Barbato wrote: Thomas Anderson wrote: As Fabian said it really isn't a matter of We like XML better than LaTeX! It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. See the devmanual. It uses completely different XML markup. It is XML, but not compatible at all with the GuideXML. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 I don't have any particular objections to these, besides the vague aesthetic one of having EAPI in the filename. Particularly long, weird EAPIs filled with special characters (to which some will reply So don't do that). It would be pretty cool to be able to sync a portage tree excluding ebuilds of any unsupported EAPI, though. 3. Most wanted changes in future EAPIs USE deps (in portage as of $recent, so we might be able to do this soon) Anything that's gotten to the point where people hack around it to use it in the tree is clearly something that should become part of an EAPI, a la built_with_use(). That's one kind of action that shows something is a feature we really need. Some features I'd like to see in general use that may not require new EAPIs: -New eclasses and elibs (GLEP 33) -Clean multilib support (PM treating ABI to allow multiples of the same PVR) -USE flag groups (GLEP 29) that don't suck like USE_EXPAND -Signing everything (eclasses and all) -GLEP 42 (news reporting) finally getting used Other things I'd like to see: -A hosting site for all of our patches. This would enable better collaboration with other distros and upstream. -More unit tests, building on the ones I posted to -dev recently. -A real tinderbox server doing continuous integration tests that people can check at any time and that will do the blame game and email people who broke something. -Someone to finish creandus (pioto's user creation thingy) Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Donnie Berkholz wrote: On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote: looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 I don't have any particular objections to these, besides the vague aesthetic one of having EAPI in the filename. Particularly long, weird EAPIs filled with special characters (to which some will reply So don't do that). Donnie, I agree, and I think it would be a mistake to use the filename extension for the EAPI number, even for simple non-long-or-funky EAPIs. I know that my reasons will be considered, by some, to be irrelevant (especially since aesthetics and/or style/elegance are of less importance to some), but I really think this should be carefully considered; a mistake here would be quite a shame. I'll state again (slightly modified) what I wrote a while back on this issue. Technical reasons to avoid the filename: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. I don't care how many people say a) that this is not an issue or b) that it's not a duplication, in every data system I've worked on, it has been a very bad idea to have more than one version of the same info that can get out of sync with each other. Even if you take great care, I'd still always want to check both and not trust either version of the info blindly. Caching or hashing is different (i.e. where the caching mechanism is robust), since the system itself keeps the cache up to date, and one version of the info is strictly derived from the other rather than both being the source. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. 2) It is not an elegant filename policy. Many systems have elegance as a design goal. 3) Assuming going this route is a mistake, it could be hard to reverse. Currently, I consider Gentoo's ebuild filename conventions simple and elegant. In fact, it is beautifully done. I'd hate to see this go down the wrong path now. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, 9 Jun 2008, Joe Peterson wrote: Technical reasons to avoid the filename: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. Okay... so: find /usr/portage -name *ebuild becomes: find /usr/portage -name *ebuild* That doesn't seem that much harder to me... Same for the file detection for editors. 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. [...] If you read the proposal more closely, you would notice that it specifically says to *not* specify EAPI in more than one place. It belongs solely in the filename suffix. The only reason the EAPI variable would be recognized inside the file itself is to allow for backwards compatibility with the current way EAPI=1 is done -- this behavior would be discouraged in all future ebuilds. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). In most unixes, the file extension is completely meaningless. What matters is the contents of the file. Nautilus, etc, mostly use detection based upon the files contents to identify file types (at least for local files), not file extensoins. 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. The reason for this is that, while the current two EAPIs don't cause trouble if you try to source them when you don't support them, that doesn't mean future ones won't. I'm not talking about anything silly like rewriting ebuilds in python, but things like changing syntax for DEPEND could potentially confuse older package managers. By adding the EAPI specification to the filename instead, old package managers just plain won't see packages they don't understand, so there's no need to worry about this. Also, sourcing a package to extract one metadata key takes much more time than just not loading it in the first place. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. New eapis aren't necessarily of any immediate use to people. Those who don't see the need for them can continue to just use EAPI=0, plain old .ebuild files of the sort that've been around for years, and for many packages this is totally appropriate. The only devs who should care are the ones who have a need for the new features. Users shouldn't ever have to read the ebuild files themselves. The package manager should tell them everything they need to know. 2) It is not an elegant filename policy. Many systems have elegance as a design goal. That's a matter of opinion. It seems perfectly elegant to me -- not to mention the various, rather clear technical benefits of it. 3) Assuming going this route is a mistake, it could be hard to reverse. Not really. The entire point of this scheme is that we can change at any time w/o breaking stuff. If we decide to go with .pbuild files for the future, we can just do that. Old package managers still won't care. -- Mike Kelly -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs 4. Strategies to ensure that gentoo's package manager is able to quickly/smartly/sainly support future EAPI's, GLEP54, GLEP55? [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On 8 Jun 2008, at 11:12, Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html Hi, I already argued in favour of both GLEP54 and GLEP55 in a council meeting. I'm eager to know what real problems people have with those. Until now, we've only seen stupid complains such as: 'changing extension breaks my shitty scripts', 'it looks weird', 'I don't understand what you are talking about, yet I want to comment', 'but scm means something else for me'... Other than that, I'm looking forward to both GLEPs being accepted whether I make it to the council or not. With respect to future EAPIs, from the top of my head, I'd like Gentoo to have: * USE dependencies. * Suggested dependencies. * Blockers information to the package manager. * Proper SCM integration with the package manager. - ferdy-- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] A few questions to our nominees
Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jun 2008 11:12:27 +0200 Piotr Jaroszyński [EMAIL PROTECTED] wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- Best Regards, Piotr Jaroszyński [Error decoding BASE64] Sorry to disappoint you. If you get me on council, I'm going to ask for a recommendation and follow it unless it looks ridiculous. For the GLEPs you mentioned, unless someone came forward otherwise, I'd approve them out of hand. As for future EAPIs, that is not a council matter that I can see. Why on earth can't that be done at the level of those who care? I.e., people who implement package managers or want EAPIs. It seems to me all we want is consistency, and council's job is to put package manager people into a room and tell them not to come out until they agree on something. If I'm a councilor, I really don't care what that is. I'll listen to what you want for future EAPIs, but I don't think it's council's job to decide. Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhLqJMACgkQQa6M3+I///frwQCg3SmJMu9K9x3hjpx0jcc0tOBy YpIAn2DS+YeYw016hoebhIyLKtbu80tE =qDAl -END PGP SIGNATURE- ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jun 2008 09:38:17 + Ferris McCormick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jun 2008 11:12:27 +0200 Piotr Jaroszyński [EMAIL PROTECTED] wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- Best Regards, Piotr Jaroszyński [Error decoding BASE64] Sorry to disappoint you. If you get me on council, I'm going to ask for a recommendation and follow it unless it looks ridiculous. For the GLEPs you mentioned, unless someone came forward otherwise, I'd approve them out of hand. As for future EAPIs, that is not a council matter that I can see. Why on earth can't that be done at the level of those who care? I.e., people who implement package managers or want EAPIs. It seems to me all we want is consistency, and council's job is to put package manager people into a room and tell them not to come out until they agree on something. If I'm a councilor, I really don't care what that is. I'll listen to what you want for future EAPIs, but I don't think it's council's job to decide. Sorry, I missed something. This is probably a QA matter since they own PMS, I believe. But it still is not a Council matter. It's QA's job to get an agreement on EAPIs if there is a problem. Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhLslUACgkQQa6M3+I///fHlQCgjjzd35UA3ZzsV2VfVSz2BAo9 yhAAn3JHu/Y1hEcVqo4AVx+1Gwbv3zRI =XM2p -END PGP SIGNATURE-
Re: [gentoo-dev] A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2008.06.08 10:12, Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: [snip] Like it or not, the council are our engineering managers, not detailed designers. The councils role is to broker agreement and promulgate standards once they have been agreed by those who have to work with them. Looking back over the last council and its recent meetings, its clear that a lot of detailed design has been attempted at the meetings. That's because all engineering managers love to get some real engineering to do. Before the flames start lets consider the Package Manager Specification (PMS) as an example. For this (very black and white) illustration, forget the council discussions to date and imagine that representatives of all three package managers went to council and said in unison We have agreed this specification. Are council really going to start picking holes in it and say no? At the meeting ? Council will have spent some time before the meeting reading it and running question and answer sessions with all interested parties, so at the meeting they can put it to a vote to record its formal adoption. If this preparation showed were issues needing more work, it would be removed from the agenda unless there was a need for a public airing of the issues, then there would be a brief statement, not a long debate that tried to fix the issues there and then. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhLuG8ACgkQTE4/y7nJvasbtACgj8GgFrcFzQ3yY0QD6liq/Mar na4AoKr4b5ZjuF0gQUgyL3m+lic4Dh9Q =giiq -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford [EMAIL PROTECTED] wrote: Before the flames start lets consider the Package Manager Specification (PMS) as an example. For this (very black and white) illustration, forget the council discussions to date and imagine that representatives of all three package managers went to council and said in unison We have agreed this specification. Are council really going to start picking holes in it and say no? The council being our global technical lead, I can't see why they wouldn't be allowed to reject an agreed package manager specification or parts of it. If not, why bother electing them at all ? Not that I think that would be a smart move, but that's a different discussion. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Denis Dupeyron wrote: On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford [EMAIL PROTECTED] wrote: Before the flames start lets consider the Package Manager Specification (PMS) as an example. For this (very black and white) illustration, forget the council discussions to date and imagine that representatives of all three package managers went to council and said in unison We have agreed this specification. Are council really going to start picking holes in it and say no? The council being our global technical lead, I can't see why they wouldn't be allowed to reject an agreed package manager specification or parts of it. If not, why bother electing them at all ? Not that I think that would be a smart move, but that's a different discussion. Well, obviously there is a balance here, but one thing that Roy pointed out that I completely agree with is the need to have most of the discussion BEFORE the meeting. A council meeting is a very time-limited event which is really designed to officially ratify decisions that have essentially already been made. The best place to have open discussion and debate over an issue is on mailing lists/etc - this allows the widest possible community to participate, and gives people time to consider their decisions. Policy shouldn't be decided by what the best shoot-from-the-hip argument was at a 1 hour meeting. Maybe if an item is on the agenda and it doesn't really have consensus there is some value to 5 minutes of free discussion, followed by a delay for one month to hash it out on lists/etc. For the most part I think the current council has embraced this, although most of the discussion on lists do not involve council members themselves (though they clearly follow the discussions). -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, 08 Jun 2008 07:22:06 -0400 Richard Freeman [EMAIL PROTECTED] wrote: For the most part I think the current council has embraced this, although most of the discussion on lists do not involve council members themselves (though they clearly follow the discussions). The current council has raised never actually deciding anything to an art form. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
On Sun, Jun 8, 2008 at 4:57 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 08 Jun 2008 07:22:06 -0400 Richard Freeman [EMAIL PROTECTED] wrote: For the most part I think the current council has embraced this, although most of the discussion on lists do not involve council members themselves (though they clearly follow the discussions). The current council has raised never actually deciding anything to an art form. You have raised flame and don't actually contribute anything useful to an art form. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, 8 Jun 2008 17:05:06 +0530 Nirbheek Chauhan [EMAIL PROTECTED] wrote: The current council has raised never actually deciding anything to an art form. You have raised flame and don't actually contribute anything useful to an art form. If you seriously think I haven't contributed anything useful, you raise ignorant nonsensical whining to... well, no, it's still just ignorant nonsensical whining. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] A few questions to our nominees
2008/6/8 Nirbheek Chauhan [EMAIL PROTECTED]: You have raised flame and don't actually contribute anything useful to an art form. Whilst I'd agree Ciaran flames with the best of them, and trolls with the worst, you simply cannot contend he never contributed anything to the project and despite now no longer being a developer, he still continues to contribute. I often don't agree with him, but can't help but respect the work he does. I would like to see Council move towards a more compressed meeting format -- people presenting arguments need to work out their stuff before bringing it up in the meeting, and to allow for quick turn-around of decisions I'd suggest fortnightly meetings which are time-limited to 60 minutes each. A prioritized schedule determines which order we deal with issues in and anything not getting attention is bumped 2 weeks, with the priority adjusted if necessary to ensure it gets attention then. Each issue should be limited to between 5-20 minutes. If people can't get through the politics and debate in the allotted time then it should either get bumped 2 weeks and given another 5-20 minutes, or we should table a special meeting to allow a full 60-90 minutes *just* to decide that one issue and nothing else. Sitting around in #gentoo-council for 3-4 hours every month isn't conducive to progress, it's going to make people get tired/bored and not pay proper attention and/or not bother to turn up, which just leads to elections. Endless cycle? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
n Sun, Jun 8, 2008 at 6:11 PM, Alex Howells [EMAIL PROTECTED] wrote: 2008/6/8 Nirbheek Chauhan [EMAIL PROTECTED]: You have raised flame and don't actually contribute anything useful to an art form. Whilst I'd agree Ciaran flames with the best of them, and trolls with the worst, you simply cannot contend he never contributed anything to the project and despite now no longer being a developer, he still continues to contribute. I never meant his overall contributions to the project were null. I meant his usual trend in replying to threads is to flame, and not contribute anything useful to the THREAD. I often don't agree with him, but can't help but respect the work he does. *When* he is willing, he can contribute very positively, as is obvious by the footprints left by him on the Gentoo project. However, this tendency of his of diverting logical threads towards a gorge by issuing useless rhetoric and flames is irking me to say the least. The last few threads are all the evidence anyone needs to verify this. I do not wish to start a flame war, and will not reply to this thread concerning this topic anymore. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote: [snip] I often don't agree with him, but can't help but respect the work he does. I would like to see Council move towards a more compressed meeting format -- people presenting arguments need to work out their stuff before bringing it up in the meeting, and to allow for quick turn-around of decisions I'd suggest fortnightly meetings which are time-limited to 60 minutes each. A prioritized schedule determines which order we deal with issues in and anything not getting attention is bumped 2 weeks, with the priority adjusted if necessary to ensure it gets attention then. Each issue should be limited to between 5-20 minutes. If people can't get through the politics and debate in the allotted time then it should either get bumped 2 weeks and given another 5-20 minutes, or we should table a special meeting to allow a full 60-90 minutes *just* to decide that one issue and nothing else. Sitting around in #gentoo-council for 3-4 hours every month isn't conducive to progress, it's going to make people get tired/bored and not pay proper attention and/or not bother to turn up, which just leads to elections. Endless cycle? ++ From me on this one. If I were elected to the Council, I would do my best to get this happening. welp -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Piotr Jaroszyński wrote: 1. GLEP54 2. GLEP55 None of them got discussion back in -dev, the glep hadn't been changed as requested during the unnecessary long discussion in the meeting. Looks like the overall consensus is that those aren't useful as they are and thus either you fix them, discussing the changes with the people in -dev (NOT THE COUNCIL) or you may retract them. 3. Most wanted changes in future EAPIs Somebody is thinking the PMS and the EAPI definition as it is are wrong and should be replaced since they aren't useful for their purpose. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, 08 Jun 2008 19:54:46 +0200 Luca Barbato [EMAIL PROTECTED] wrote: 3. Most wanted changes in future EAPIs Somebody is thinking the PMS and the EAPI definition as it is are wrong and should be replaced since they aren't useful for their purpose. Anyone thinking that has a very limited understanding of how things work. Let's face it, there hasn't been any correct criticism, and any complaints have been from people who don't understand what's going on anyway and who seek to blame EAPI for Portage's lack of progress, rather than blaming Portage's lack of progress for lack of new EAPIs as they should. -- Ciaran McCreesh signature.asc Description: PGP signature
