FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-08-2008, 09:12 AM
"Piotr Jaroszyński"
 
Default 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
 
Old 06-08-2008, 09:24 AM
Alistair Bush
 
Default 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
 
Old 06-08-2008, 09:33 AM
"Fernando J. Pereda"
 
Default 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
 
Old 06-08-2008, 09:38 AM
Ferris McCormick
 
Default A few questions to our nominees

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

On Sun, 8 Jun 2008 11:12:27 +0200
"Piotr Jaroszyński" <peper@gentoo.org> 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) <fmccor@gentoo.org>
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�
 
Old 06-08-2008, 10:19 AM
Ferris McCormick
 
Default A few questions to our nominees

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

On Sun, 8 Jun 2008 09:38:17 +0000
Ferris McCormick <fmccor@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 8 Jun 2008 11:12:27 +0200
> "Piotr Jaroszyński" <peper@gentoo.org> 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) <fmccor@gentoo.org>
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-----
 
Old 06-08-2008, 10:45 AM
Roy Bamford
 
Default 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
 
Old 06-08-2008, 10:59 AM
"Denis Dupeyron"
 
Default A few questions to our nominees

On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford <neddyseagoon@gentoo.org> 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
 
Old 06-08-2008, 11:22 AM
Richard Freeman
 
Default A few questions to our nominees

Denis Dupeyron wrote:

On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford <neddyseagoon@gentoo.org> 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
 
Old 06-08-2008, 11:27 AM
Ciaran McCreesh
 
Default A few questions to our nominees

On Sun, 08 Jun 2008 07:22:06 -0400
Richard Freeman <rich0@gentoo.org> 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
 
Old 06-08-2008, 11:35 AM
"Nirbheek Chauhan"
 
Default A few questions to our nominees

On Sun, Jun 8, 2008 at 4:57 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 08 Jun 2008 07:22:06 -0400
> Richard Freeman <rich0@gentoo.org> 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
 

Thread Tools




All times are GMT. The time now is 03:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org