[gentoo-dev] *IMPORTANT* top-level management structure!

[gentoo-dev] *IMPORTANT* top-level management structure!

[Daniel Robbins]

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

Hi guys,

We are all painfully aware of the chronic communication, coordination and
planning issues that are a direct result of the massive growth of this
project. The primary victim of this growth has been the release of 
Gentoo Linux 1.4, as well as all of our sanity.

Kurt and I have developed a comprehensive plan which we hope to get in place
*this week* to address all of these issues. A draft of the plan is below. It
is long, but *ALL* developers need to read it in its *ENTIRETY* and
understand why we need to move from a unstructured community development
model to a model that incorporates the best possible software development
and management practices. This is the first critical step in making this
happen.  Being better organized is the only way we can effectively grow
while improving the quality of Gentoo. Enough said, please read.

Gentoo top-level management structure proposal, recursive implementation
========================================================================
Authors: Daniel Robbins and Kurt Lieber

*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT

This is a draft. But I want to get this finalized and in place by Thursday
if we can. We are simply growing too fast to not get this in place within
days.

(Note: see "manager responsibility #9" to understand the recursive nature
of this proposal.)

What is the purpose of this proposal?
-------------------------------------

The purpose of this proposal is to solve chronic management, coordination
and communication issues in the Gentoo project. In particular, currently we
have no clearly defined top-level management structure, and no official,
regular meetings to communicate status updates between developers serving
in critical roles. In general, most communication takes place on irc and
irregularly via email. There is also little to no accountability, even
at a high level, to complete projects on time.

Because of this current state of affairs, it is difficult to set goals and
track the status of projects. This lack of communication and coordination
also makes it difficult for top-level developers to manage their own
projects. In addition, we have the other chronic problem of not having
clearly-defined roles and scopes of executive decision-making authority for
top-level developers, which results in many top-level developers doubting
that they even have the authority to manage their own projects and
sub-projects. While this has *never* been the intention of top-level
developers, it is the unfortunate result of an unstructured development
process: no one knows what is going on, and everyone defers to the Chief
Architect for all executive decisions.

Clearly, a plan is needed to swiftly and permanently address these issues by
increasing communication, coordination, and accountability. Roles and scopes
of executive decision-making authority need to be defined for top developers
so that they have a clear mandate as well as accountability to manage their
projects and thus ensure their projects complete their appointed work
efficiently and on-schedule.

How do we fix this?
-------------------

This proposal suggests fixing this issue by creating an official top-level
management structure. This management structure will consist of the chief
architect and a group of developers that will be given the title of
"Top-level managers." Top-level managers will be accountable for the
projects they manage, and be responsible for communicating the status of
their projects to the rest of the top-level managers and chief architect,
among other things detailed later in this document.

All the top-level projects in the Gentoo project will be clearly defined,
including with goals, sub-projects, members, roadmap and schedules.  The
"Hardened Gentoo" page at http://www.gentoo.org/proj/en/hardened/ is a
excellent example of such a top-level project definition.

Certain executive decision-making authority will be granted to these
projects, as agreed upon by the top-level managers and project members.
Then, a top-level manager or managers will be officially adopt projects.
These managers will be responsible for tracking the status of the project,
ensuring that the project meets targets and is generally managed properly.
Manager responsibilities are described in detail later in this document.

The operational manager of each top-level project will also be responsible
to report the status of the project in regular weekly status meetings in
which all top-level managers will participate. This regular communication
will allow proper coordination, goal-setting and scheduling to take place.

Types of management
-------------------

For top-level projects, there are currently two possible types of managers.
Each project must have at least one manager of each type, although one
person may serve both roles.  The first type of manager is the operational
manager, who is granted executive authority for the day-to-day running of
the project. Because this person is directly involved in the day-to-day
running of the project, this person has the responsibility to communicate
project status to the rest of the top-level management team.

The other type of manager is the tactical manager. The tactical manager has
executive decision-making authority over the long-term strategic direction
of the project. This manager's involvement in the day-to-day operations of
the project is limited. Both tactical and operational management are equally
important for a successful project.

Management team
---------------

Proposed initial top-level managment team is as follows:

Top-level managers (in no particluar order):
	Seemant Kulleen (seemant)
	Jay Pfeifer (pfeifer)
	Joshua Brindle (method)
	Kurt Lieber (klieber)
	Nick Jones (carpaski)
	Pieter Van den Abeele (pvdabeel)
	Jon Portnoy (avenj)

Chief Architect
	Daniel Robbins (drobbins)

Management charter
------------------

1) Constructive, professional communication: All communication should be
focused on improving the management of Gentoo projects, should be
constructive in nature and should be shared in a friendly, professional
manner.

2) Accountability to peers: Allow fellow members of this list to hold us
accountable to follow-through on projects and meet deadlines. Keep fellow
members accountable.

3) Management of projects: empower managers to have the authority and
strategic direction necessary to properly manage thier projects and efforts
to ensure projects complete their appointed work on time.

4) Results: our expectation is that our efforts, when properly executed,
will result in the Gentoo project's ability to meet deadlines, have much
better communication and coordination throughout the entire project, higher
overall quality and a more positive experience for all.

Manager responsibilities
------------------------

Every top-level Gentoo project will have a clearly defined scope, and
clearly defined and explicit executive decision-making authority that will
be granted to managers of the project to exercise and/or delegate as they
see fit. Both the scope and any necessary decision-making authority must be
agreed upon by both the chief architect and project members. The scope and
executive authority of a project can be expanded over time as required as
approved by the top level managers.

In addition to decision-making authority, managers have the following
responsibilities:

1) Keep a complete list of all projects and efforts you are managing,
and associated gentoo.org project page up-to-date

2) Manage and track the status of these efforts. This includes active
direction as well as passive tracking of progress.

3) Define clear goals, roadmaps and timelines (preliminary if necessary) for
every effort.

4) Proactively identify efforts that have problems and need help.

5) Ensure that your efforts are completed on-time.

6) Remain focused. Make sure that you are not managing more than you can handle.

7) Fulfill formal communication and coordination responsibilities required by
top-level managers (weekly meetings, etc.)

8) Fulfill formal communication and coordination responsibilities required
by individual efforts (project meetings, communication with project members,
etc.) This is *important* -- our management of projects means that we
have the responsibility not only to communicate with our peers but
also those who we are managing. This communication should be frequent,
have a formal component (planned meetings, official status updates,
etc.) and model good management practices to members of our teams.

9) *RECURSIVE FUNCTIONALITY*: When possible, implement these management
practices for *sub*-projects (define managers, clear sub-project goals,
grant executive authority) with you serving as primary authority.

gentoo-managers list
====================

The gentoo-managers list will be created as the official email communications
channel for all top-level Gentoo Linux managers.

The tenative plan for top-level management coordination is as follows:

Monday full status email:

	Every Monday afteroon, every member of this list posts a status summary of
	projects/efforts that they are managing, as well as any items that they
	would like to discuss "live" on IRC in the upcoming "live" meeting.
	If you are unable to attend the "live" IRC meeting, an email to this
	list mentioning your inability to attend should be posted by Monday
	afternoon or before.

	The goal of the Monday afternoon email is to get every other top-level
	manager up to speed on the status of your efforts and any efforts
	managed by you, and to have a tenative meeting agenda in place for the
	"live" IRC meeting.

Monday IRC chat:

	On Monday evening, we convene on irc for a "live" meeting.
	The goal of this meeting isn't to provide status updates on our
	projects, but to work out any outstanding hands-on issues relating to the
	management of Gentoo Linux. These issues can include:

		1) Assignment of unmanaged projects
		2) Resolving critical, time-sensitive problems
		3) Trying to "fix" projects that are having trouble staying on-target
		4) Sharing new ideas about how to coordinate our efforts better
		5) Finding ways to improve our management of projects

	The goal of this live IRC chat is to provide a regular forum to resolve
	tricky issues that benefit from real-time, "live" discussion. Generally,
	this meeting should last no more than one hour if possible. Generally,
	new ideas and practices should be discussed in this live meeting, with
	the list being used for status updates and coordinated resolution of
	critical issues.

	(Note: inability to attend due to time zone can be addressed by posting
	the full IRC log to gentoo-managers and allowing non-attending members
	to post ideas, comments and follow-ups)

Thursday update:

	Every Thursday afternoon, every member of this list posts a "status
	update" email, giving all members a quick, general update on any efforts
	currently underway. This allows for some fairly rapid feedback for any
	efforts that were started the previous Monday, and an opportunity to
	recover from any efforts that have fallen off-target since the previous
	Monday.

	This email need not be exhaustive, but may be if necessary.

	The goal of this update is to allow any problems with our projects to be
	discussed and shared before the weekend, so that an adequate solution or 
	interim solution can be found before the weekend.

top-level projects and *preliminary* top-level managerial assignments below.
Note that *sub-project* managers are generally not listed, but will be
defined in time. We are starting with the top levels first.


	gentoo-linux:
		Gentoo Linux
		tactical manager: drobbins, seemant
		operational manager: seemant
		back-up: avenj
		sub-projects:
			x86-stable: Gentoo Linux x86 stable branch
			x86-unstable: Gentoo Linux x86 unstable branch
			amd64
			ppc
			alpha
			sparc
			hppa
			etc.
			
	kernel: 
		Kernel development
		tactical manager: pfeifer (lolo?)
		operational manager: pfeifer (lolo?)
		sub-projects:
			x86
			amd64
			ppc
			alpha
			sparc
			hppa
			etc.
	
	gentoo-alt:
		Alternate operating system platform/special-purpose projects
		tactical managers: drobbins, pvdabeel
		operational manager: pvdabeel
		sub-projects:
			gentoo-bsd
			gentoo-macos
			livecd: Gentoo Linux LiveCD technology efforts
	
	hardened:
		Hardened Gentoo -- efforts related to integrated security
		techologies into Gentoo Linux.
		tactical manager: method
		operational manager: method
		page: http://www.gentoo.org/proj/en/hardened/
		sub-projects:
			selinux
			propolice
			systrace
			hardened-sources
			grsecurity

	tools:
		Useful Gentoo scripts and tools (for user or developer use, possibly
		Portage-related)
		tactical manager: pvdabeel
		operational manager: pvdabeel
		subprojects:
			keychain
			dynfw
			eperl
	
	devrel:
		General development management, developer relations
		tactical managers: seemant, drobbins
		operational manager: avenj
		back-up: klieber 
		subprojects:
			newdev: Recruiting of developers, enforcement of recruitment policy
			devops: Day-to-day oversight of Gentoo development, commits
		
	releng:
		Managing and coordinating release process
		tactical manager: drobbins, seemant
		operational manager: avenj
		subprojects:
			build: Management of stage/package building efforts on all architectures
			install-doc: install documentation
	
	qa:
		Explicit, proactive quality control efforts
		tactical manager: drobbins 
		operational manager: seemant
		subprojects:
			bugs: Overseeing bug distribution/assigment/completion and responsiveness
			security: Manage tracking and application of security fixes to packages
			policy-doc: policy documentation

	pr:
		Public relations efforts, contact with distrowatch.com, etc.
		tactical manager: drobbins
		operational manager: klieber
		back-up: seemant 
		subprojects:	
			partners: Gentoo partnerships, liaison(s) to metapkg, Gentoo Games, Inc.
			shows: Planning and organization for trade shows
			gwn: Gentoo Weekly News
	
	portage:
		Portage development, maintenance and new features implementation
		tactical manager: drobbins
		operational manager: carpaski
		subprojects:
			package-research: Research into new packaging technologies and capabilities
			managers: carpaski, drobbins, pvdabeel

	infrastructure:
		tactical manager: klieber
		operational manager: klieber
		gentoo.org Mirrors, servers, email, hosting, server security
		subprojects:	
			mirrors: ftp, web and rsync mirrors
			web: gentoo.org Web site design and related technology
			doc: general documentation

-- 
Daniel Robbins
Chief Architect, Gentoo Linux
http://www.gentoo.org

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

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Tony Clark]

On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
> aHi guys,

We are all painfully aware of the chronic communication, coordination and
planning issues that are a direct result of the massive growth of this
project. The primary victim of this growth has been the release of 
Gentoo Linux 1.4, as well as all of our sanity.

Kurt and I have developed a comprehensive plan which we hope to get in place
*this week* to address all of these issues. A draft of the plan is below. It
is long, but *ALL* developers need to read it in its *ENTIRETY* and
understand why we need to move from a unstructured community development
model to a model that incorporates the best possible software development
and management practices. This is the first critical step in making this
happen.  Being better organized is the only way we can effectively grow
while improving the quality of Gentoo. Enough said, please read.
----------------------------------------------------------------------------------------
Daniel,

I'm glad to see something is going to happen and if I can be of help please 
clet me know.  I do however have some basic problems which aren't addressed 
and only require a couple of people to sort them out.

1.  What is Gentoo 1.4.  What it may have been intended to be in January is 
probably not what it is going to be now.  Before you recruit all and sundry 
you have to define this as if it isn't defined everything will fall down and 
chaos will return.  Some basic things I see is that it needs to be are:
gcc3.3 based
glibc2.3.2
openssl0.9.7
2.  What are the core applications.  Is it a desktop, a server orinitated 
system or a system compremised to do both.  I would suggest desktop as I 
think thats what it is mainly used for, but I don't have the stats so I could 
be well off the mark. (Market research required)
3.  What platform should be supported at release time.  Here I think x86 and 
maybe x86-64.  Targeting too many will just delay it.  Have some other dates 
for the rest to follow.

These are just really fundementals but until the requirements are documented 
things will never really come together.  

Get things out in the open.  Gentoo-core is probably the worst idea someone 
ever came up with, OSS development is meant to be a very transparent process.  
Make it transparent.  I know there are always private issues but if they 
involve more than 3 people then perhaps they should be public.

Remember that 99% of your resources are probably volunteers, make it easy for 
them to do what they want to do and meet your objectives.  I'm not sure how 
you can make them accountable for what they do but I don't think thats a 
problem if they are empowered to do what they want to do.  Code hackers in 
general make poor managers and vice versa.

Good luck

tony

-- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Peter Johanson]

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

On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
> On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:

> 2.  What are the core applications.  Is it a desktop, a server orinitated 
> system or a system compremised to do both.  I would suggest desktop as I 
> think thats what it is mainly used for, but I don't have the stats so I could 
> be well off the mark. (Market research required)

One of the strenghts of gentoo, IMHO, is that it is suitable for *any*
of these uses. We don't need "core" applications in the sense of
distinguishing it as one type of distro or the other. It is a
metadistribution in every sense of the word, including not confining
itself to one "specialty"

> 3.  What platform should be supported at release time.  Here I think x86 and 
> maybe x86-64.  Targeting too many will just delay it.  Have some other dates 
> for the rest to follow.
> 
> These are just really fundementals but until the requirements are documented 
> things will never really come together.  
> 
> Get things out in the open.  Gentoo-core is probably the worst idea someone 
> ever came up with, OSS development is meant to be a very transparent process.  
> Make it transparent.  I know there are always private issues but if they 
> involve more than 3 people then perhaps they should be public.

i know there has been strong movement to move more things off of -core
and to -dev, as well as reducing non development issues to -user.
Continuing this effort, and keeping -core for truely important issues,
(konwn vulnerabilities like the KDE one from a while back) is important.
It should be stressed that -dev should be considered *the* place for
development mails, and -core for truly *core* specific issues.

-- 
Peter Johanson
<latexer@gentoo.org>

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

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Jon Portnoy]

On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
> On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
[snip]
> 1.  What is Gentoo 1.4.  What it may have been intended to be in January is 
> probably not what it is going to be now.  Before you recruit all and sundry 
> you have to define this as if it isn't defined everything will fall down and 
> chaos will return.  Some basic things I see is that it needs to be are:
> gcc3.3 based
> glibc2.3.2
> openssl0.9.7

We can do this if you want to wait another couple of months.

Unfortunately, there are some requests to have 1.4 ready for LWESF at 
the beginning of August.

This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 needs 
a much more mature upgrade path, otherwise there will be serious 
breakage (you need to remerge wget without ssl support, then merge the 
new openssl, then rebuild everything depending on it currently).

> 2.  What are the core applications.  Is it a desktop, a server orinitated 
> system or a system compremised to do both.  I would suggest desktop as I 
> think thats what it is mainly used for, but I don't have the stats so I could 
> be well off the mark. (Market research required)

I don't understand what you mean by 'core applications' in this context.

> 3.  What platform should be supported at release time.  Here I think x86 and 
> maybe x86-64.  Targeting too many will just delay it.  Have some other dates 
> for the rest to follow.

We target all platforms that're release-ready. Right now, that's x86, 
ppc, and sparc. Release-ready means the tree is prepped, the stages and 
LiveCDs can be built, install documents are up on the site.

> 
> These are just really fundementals but until the requirements are documented 
> things will never really come together.  
> 
> Get things out in the open.  Gentoo-core is probably the worst idea someone 
> ever came up with, OSS development is meant to be a very transparent process.  
> Make it transparent.  I know there are always private issues but if they 
> involve more than 3 people then perhaps they should be public.

We are making it transparent by discussing development on gentoo-dev.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Tony Clark]

On Wednesday 25 June 2003 06.04, Jon Portnoy wrote:
> On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
> > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
>
> [snip]
>
> > 1.  What is Gentoo 1.4.  What it may have been intended to be in January
> > is probably not what it is going to be now.  Before you recruit all and
> > sundry you have to define this as if it isn't defined everything will
> > fall down and chaos will return.  Some basic things I see is that it
> > needs to be are: gcc3.3 based
> > glibc2.3.2
> > openssl0.9.7
>
> We can do this if you want to wait another couple of months.
>
> Unfortunately, there are some requests to have 1.4 ready for LWESF at
> the beginning of Augusy
This is just classical, happens everyday type stuff in electronics/software 
companies, espically ones who don't know what they are building with clear 
goals.  Marketing keeps moving the requirements and dates aren't met.  Some 
deadline finally gets set and a patch work job happens to meet THE DATE.

> This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 needs
> a much more mature upgrade path, otherwise there will be serious
> breakage (you need to remerge wget without ssl support, then merge the
> new openssl, then rebuild everything depending on it currently).
The OpenSSL upgrade is really ready, it just that the whole tree needs a 
rebuild which is time consumming.  You have to break the cycle sooner or 
later.  Seems to me one solution is to release a binary version of 1.4 build 
with the latest OpenSSL goes someway to ease that upgrade.  Users can get a 
working basic system maybe with kde and gnome desktops then add or rebuild at 
their own pace.  New takers have no problems as they are current.  GCC is a 
slightly different problem but not as large.  I guess it could be solved 
putting different versions of GCC in slots.  Glibc is pretty well there and 
doesn't seem to have any problems that I have noticed.

>
> > 2.  What are the core applications.  Is it a desktop, a server orinitated
> > system or a system compremised to do both.  I would suggest desktop as I
> > think thats what it is mainly used for, but I don't have the stats so I
> > could be well off the mark. (Market research required)
>
> I don't understand what you mean by 'core applications' in this context.
I think of core applications as things people are actually going to use to do 
something outside of maintaining their systems.  ie desktop, browser, apache 
etc.  verses core-system stuff like kernels, tools, portage etc.

> > 3.  What platform should be supported at release time.  Here I think x86
> > and maybe x86-64.  Targeting too many will just delay it.  Have some
> > other dates for the rest to follow.
>
> We target all platforms that're release-ready. Right now, that's x86,
> ppc, and sparc. Release-ready means the tree is prepped, the stages and
> LiveCDs can be built, install documents are up on the site.

Well if you ask me, thats too many for an August deadline.  Do the best that 
can be done with x86 and have the rest follow by a month.  That way any nasty 
bugs can be squashed before the other 2 hit the stand but I guess the 
Marketing Dept has mandated that all 3 will be ready at the same time. :)

>
> > These are just really fundementals but until the requirements are
> > documented things will never really come together.
> >
> > Get things out in the open.  Gentoo-core is probably the worst idea
> > someone ever came up with, OSS development is meant to be a very
> > transparent process. Make it transparent.  I know there are always
> > private issues but if they involve more than 3 people then perhaps they
> > should be public.
>
> We are making it transparent by discussing development on gentoo-dev.
Don't tell me, someone woke up this morning and formed a new management 
structure, honest :)  You know you need this transparent as it is the only 
hope of it getting done in time.  It's not a big deal for me actually, it's 
just that of ppl where primed and ready for the announcement you would be 
more than halfway towards meeting the objectives.

Anyway, from another comment it is impossible to define goals for Gentoo 
therefore I would submit it is impossible to have a 1.4 release.  I have no 
problems with that, marketing probably does though.

tony
-- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Jon Portnoy]

On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote:
> On Wednesday 25 June 2003 06.04, Jon Portnoy wrote:
> > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
> > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
> >
> > [snip]
> >
> > > 1.  What is Gentoo 1.4.  What it may have been intended to be in January
> > > is probably not what it is going to be now.  Before you recruit all and
> > > sundry you have to define this as if it isn't defined everything will
> > > fall down and chaos will return.  Some basic things I see is that it
> > > needs to be are: gcc3.3 based
> > > glibc2.3.2
> > > openssl0.9.7
> >
> > We can do this if you want to wait another couple of months.
> >
> > Unfortunately, there are some requests to have 1.4 ready for LWESF at
> > the beginning of Augusy
> This is just classical, happens everyday type stuff in electronics/software 
> companies, espically ones who don't know what they are building with clear 
> goals.  Marketing keeps moving the requirements and dates aren't met.  Some 
> deadline finally gets set and a patch work job happens to meet THE DATE.

We know what we're building and have clear goals. Those goals have been 
specified on this list by Daniel in the past.

With minor exceptions, _those goals are met_.

However, you're now suggesting _entirely new_ goals that _do not fit_ 
with the schedule already in mind. Marketing is irrelevant - a few 
people said "Do you think we'll be ready for LWESF?" and I said "Yes." I 
intend to follow up on that, now that our goals are either met or about 
to be met. There is no 'THE DATE' that we absolutely must adhere to. 
Instead, I'm telling you that there is no technical way we can go with 
gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a 
significantly long period of time while work is done in those areas.

> 
> > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 needs
> > a much more mature upgrade path, otherwise there will be serious
> > breakage (you need to remerge wget without ssl support, then merge the
> > new openssl, then rebuild everything depending on it currently).
> The OpenSSL upgrade is really ready, it just that the whole tree needs a 
> rebuild which is time consumming.  You have to break the cycle sooner or 
> later.  Seems to me one solution is to release a binary version of 1.4 build 
> with the latest OpenSSL goes someway to ease that upgrade.  Users can get a 

Certainly, new stage1 and stage2 installs would have no problem - they 
haven't done an emerge system yet. A stage3 with openssl 0.9.7 would 
have no problem. Existing users or people using old stage3s would be 
screwed. We need a better upgrade path for that in order to avoid the 
kind of "patch work job" you described earlier.

With regards to 'breaking the cycle,' we need functionality in Portage 
that either allows the ebuild to directly run revdep-rebuild or 
incorporate revdep-rebuild into Portage (or preferably real reverse 
dependencies, which will come in Portage 2.1 last I heard).


> working basic system maybe with kde and gnome desktops then add or rebuild at 
> their own pace.  New takers have no problems as they are current.  GCC is a 
> slightly different problem but not as large.  I guess it could be solved 
> putting different versions of GCC in slots.  Glibc is pretty well there and 
> doesn't seem to have any problems that I have noticed.

SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is 
not ready for it. Many applications will not build and there are many, 
many unsolved problems and weird issues that people can't track down. 
GCC 3.3 is not production ready and I, for one, am not interested in 
pushing people to release a broken compiler on the masses for the sake 
of saying "we're up to date!" - can you please justify pushing GCC 3.3 
before it's ready?

glibc is just about set, yes. Note that I didn't say anything about 
glibc in my email.

> 
> >
[snip
> > > 3.  What platform should be supported at release time.  Here I think x86
> > > and maybe x86-64.  Targeting too many will just delay it.  Have some
> > > other dates for the rest to follow.
> >
> > We target all platforms that're release-ready. Right now, that's x86,
> > ppc, and sparc. Release-ready means the tree is prepped, the stages and
> > LiveCDs can be built, install documents are up on the site.
> 
> Well if you ask me, thats too many for an August deadline.  Do the best that 
> can be done with x86 and have the rest follow by a month.  That way any nasty 
> bugs can be squashed before the other 2 hit the stand but I guess the 
> Marketing Dept has mandated that all 3 will be ready at the same time. :)

That's not too many for an August deadline: I'm not sure where you got 
that idea. They'll be ready at the same time because it makes sense for 
them to be ready at the same time to have a uniform release. There is no 
reason _not_ to release them at the same time.

If a specific arch leads decides they're not ready for a 1.4 release, 
they won't be released. I'm not going to mandate that archs that aren't 
ready have a release, but I'm not going to refuse to release what's 
ready, either.

Marketinng Dept? We have nothing to gain from 'marketing' except for 
providing a superior product to users. I am sorry that providing a 
superior product to users and attempting to avoid any inconvienence to 
users does not fit with what you would like. I am not willing to push 
gcc 3.3 yet because it breaks for a lot of people; I am not willing to 
push openssl 0.9.7 out of package.mask because many people will have 
broken systems without a better upgrade path. I am sorry that you do not 
understand QA.

> 
> >
> > > These are just really fundementals but until the requirements are
> > > documented things will never really come together.
> > >
> > > Get things out in the open.  Gentoo-core is probably the worst idea
> > > someone ever came up with, OSS development is meant to be a very
> > > transparent process. Make it transparent.  I know there are always
> > > private issues but if they involve more than 3 people then perhaps they
> > > should be public.
> >
> > We are making it transparent by discussing development on gentoo-dev.
> Don't tell me, someone woke up this morning and formed a new management 
> structure, honest :)  You know you need this transparent as it is the only 
> hope of it getting done in time.  It's not a big deal for me actually, it's 
> just that of ppl where primed and ready for the announcement you would be 
> more than halfway towards meeting the objectives.

Can you explain what you mean here? Getting what done 
in time? Which announcement? Which objectives?

> 
> Anyway, from another comment it is impossible to define goals for Gentoo 
> therefore I would submit it is impossible to have a 1.4 release.  I have no 
> problems with that, marketing probably does though.

Now you're really grasping at straws. Can you tell me which comment says 
that it's impossible to define goals for Gentoo?

What marketing? The fact that I said that it'd be nice to have something 
to hand out on CDs to people for LWESF so they can go home and install 
Gentoo suddenly means everything we do is based on marketing?

I apologize for all of us for trying to provide you, the users, with a 
superior product, good QA, and convienent upgrades.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[foser]

On Wed, 2003-06-25 at 05:42, Peter Johanson wrote:

> i know there has been strong movement to move more things off of -core
> and to -dev, as well as reducing non development issues to -user.
> Continuing this effort, and keeping -core for truely important issues,
> (konwn vulnerabilities like the KDE one from a while back) is important.
> It should be stressed that -dev should be considered *the* place for
> development mails, and -core for truly *core* specific issues.

This is exactly the problem of -dev, that replies go totally off topic.
Despite the validity of the points made they do not matter in this
discussion and partly have been discussed before .

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Svyatogor]

Hello!
I am fairly new to this project and of course don't know all the difficulties, 
which you might have faced lately, but still I'd like to make as some 
questions on this plan.

First of all, the whole thing sounds quite nice. Especially cause it seems to 
bring some order and also some understanding who's responsible for what, and 
whom you need to contact in case you have this or other trouble.

Secondly, in a number of places you point out such thing as 'accountability'. 
Of course it is extremely important, but this is an Open Source project 
(AFAIK) and I don't actually see how you're planning to enforce responsibity 
for meeting project goals and deadlines.

Then, you say:

"Both the scope and any necessary decision-making authority must be
agreed upon by both the chief architect and project members."

How do you actually see this being done? While all project members and 'chief 
architect' and top level guys will most likely have the same intuitive 
understanding of what needs to be done, it'' be hard to agree upon a certain 
formal plan/definition. I am not trying to imply, that I don't like the idea. 
What I'm trying probably you need to elaborate on some procedures of reaching 
this agreement.

Ok, something else. You mention mailing list and IRC channel. However, you 
don't specify if they are gonna be opened for everyone to read listen, or 
not. I believe, it is extremely important for everyone - both devs and users 
to see what is going on in the management of the project. In the end of the 
day most people are volunteers and don't want to find thmesleves one day in 
situation when top managers, just bring them ready decision, which they've 
never had a chance to comment on.


-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Tony Clark]

On Wednesday 25 June 2003 07.47, Jon Portnoy wrote:
> On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote:
> > On Wednesday 25 June 2003 06.04, Jon Portnoy wrote:
> > > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
> > > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
> > >
> > > [snip]
> > >
> > > > 1.  What is Gentoo 1.4.  What it may have been intended to be in
> > > > January is probably not what it is going to be now.  Before you
> > > > recruit all and sundry you have to define this as if it isn't defined
> > > > everything will fall down and chaos will return.  Some basic things I
> > > > see is that it needs to be are: gcc3.3 based
> > > > glibc2.3.2
> > > > openssl0.9.7
> > >
> > > We can do this if you want to wait another couple of months.
> > >
> > > Unfortunately, there are some requests to have 1.4 ready for LWESF at
> > > the beginning of Augusy
> >
> > This is just classical, happens everyday type stuff in
> > electronics/software companies, espically ones who don't know what they
> > are building with clear goals.  Marketing keeps moving the requirements
> > and dates aren't met.  Some deadline finally gets set and a patch work
> > job happens to meet THE DATE.
>
> We know what we're building and have clear goals. Those goals have been
> specified on this list by Daniel in the past.
past day, week, month, year?  He has had about 4 posts here in the last 6 
months.  Why isn't the QA guy demanding a list of packages to be included?
>
> With minor exceptions, _those goals are met_.

What exceptions? Why the sudden panic then?
>
> However, you're now suggesting _entirely new_ goals that _do not fit_
> with the schedule already in mind. Marketing is irrelevant - a few
> people said "Do you think we'll be ready for LWESF?" and I said "Yes." I
> intend to follow up on that, now that our goals are either met or about
> to be met. There is no 'THE DATE' that we absolutely must adhere to.
> Instead, I'm telling you that there is no technical way we can go with
> gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a
> significantly long period of time while work is done in those areas.
Now above you say there is a deadline and here you say there isn't.  I can't 
see how you can say I am describing new goals when you can't point me to a 
document which states what the current goals are.  There is no QA as noone 
can trace a specification pass back to a specified requirement.  I've 
digressed into QA but thats actually what the total process should be about.

> > > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7
> > > needs a much more mature upgrade path, otherwise there will be serious
> > > breakage (you need to remerge wget without ssl support, then merge the
> > > new openssl, then rebuild everything depending on it currently).
> >
> > The OpenSSL upgrade is really ready, it just that the whole tree needs a
> > rebuild which is time consumming.  You have to break the cycle sooner or
> > later.  Seems to me one solution is to release a binary version of 1.4
> > build with the latest OpenSSL goes someway to ease that upgrade.  Users
> > can get a
>
> Certainly, new stage1 and stage2 installs would have no problem - they
> haven't done an emerge system yet. A stage3 with openssl 0.9.7 would
> have no problem. Existing users or people using old stage3s would be
> screwed. We need a better upgrade path for that in order to avoid the
> kind of "patch work job" you described earlier.
>
> With regards to 'breaking the cycle,' we need functionality in Portage
> that either allows the ebuild to directly run revdep-rebuild or
> incorporate revdep-rebuild into Portage (or preferably real reverse
> dependencies, which will come in Portage 2.1 last I heard).
Ok, now this is good.  All that is needed is to write these points down and 
pretty soon you will end up with a requirement document that everyone can 
understand, identify where they can be of most use and a check list you can 
tick off when each thing is done.  Now the project is managed!  It really is 
simple but because it is tedious, for a good designer, it is somewhat boring.

>
> > working basic system maybe with kde and gnome desktops then add or
> > rebuild at their own pace.  New takers have no problems as they are
> > current.  GCC is a slightly different problem but not as large.  I guess
> > it could be solved putting different versions of GCC in slots.  Glibc is
> > pretty well there and doesn't seem to have any problems that I have
> > noticed.
>
> SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is
> not ready for it. Many applications will not build and there are many,
> many unsolved problems and weird issues that people can't track down.
> GCC 3.3 is not production ready and I, for one, am not interested in
> pushing people to release a broken compiler on the masses for the sake
> of saying "we're up to date!" - can you please justify pushing GCC 3.3
> before it's ready?

I don't need too.  I'm not a gentoo developer, I just  help where I can, when 
I can.  What you should be telling me is here is a url of the number of 
packages that won't build with gcc3.3 in portage and here is another list 
that we are not sure of.  Have that in an easy to find location then things 
can start to happen.  It's all very well to say things are as broken as SCO's 
kernel code but all I can say is, show me the list and I will see what I can 
do to fix some of it. :)

>
> That's not too many for an August deadline: I'm not sure where you got
> that idea. They'll be ready at the same time because it makes sense for
> them to be ready at the same time to have a uniform release. There is no
> reason _not_ to release them at the same time.

Great but not visible.
>
> If a specific arch leads decides they're not ready for a 1.4 release,
> they won't be released. I'm not going to mandate that archs that aren't
> ready have a release, but I'm not going to refuse to release what's
> ready, either.

Your the release guy, your call seems reasonable.

>
> Marketinng Dept? We have nothing to gain from 'marketing' except for
> providing a superior product to users. I am sorry that providing a
> superior product to users and attempting to avoid any inconvienence to
> users does not fit with what you would like. I am not willing to push
> gcc 3.3 yet because it breaks for a lot of people; I am not willing to
> push openssl 0.9.7 out of package.mask because many people will have
> broken systems without a better upgrade path. I am sorry that you do not
> understand QA.

Talk about the pot calling the kettle black.  You can't point to 1 record that 
confirms anything your designing.  I have been a designer for ISO9001 
approved companies for the last 10 years, before that to Mil and other 
telecom standards, please give me a break.

>
> > > > These are just really fundementals but until the requirements are
> > > > documented things will never really come together.
> > > >
> > > > Get things out in the open.  Gentoo-core is probably the worst idea
> > > > someone ever came up with, OSS development is meant to be a very
> > > > transparent process. Make it transparent.  I know there are always
> > > > private issues but if they involve more than 3 people then perhaps
> > > > they should be public.
> > >
> > > We are making it transparent by discussing development on gentoo-dev.
> >
> > Don't tell me, someone woke up this morning and formed a new management
> > structure, honest :)  You know you need this transparent as it is the
> > only hope of it getting done in time.  It's not a big deal for me
> > actually, it's just that of ppl where primed and ready for the
> > announcement you would be more than halfway towards meeting the
> > objectives.
>
> Can you explain what you mean here? Getting what done
> in time? Which announcement? Which objectives?
Your asking me?  Shit I'm not running the project, your meant to know all 
those answers.

>
> > Anyway, from another comment it is impossible to define goals for Gentoo
> > therefore I would submit it is impossible to have a 1.4 release.  I have
> > no problems with that, marketing probably does though.
>
> Now you're really grasping at straws. Can you tell me which comment says
> that it's impossible to define goals for Gentoo?
Can you point to any document that defines Gentoo 1.4?

>
> What marketing? The fact that I said that it'd be nice to have something
> to hand out on CDs to people for LWESF so they can go home and install
> Gentoo suddenly means everything we do is based on marketing?

Ecveryone has marketing whether they know it or not.  You just described a 
part of marketing.
>
> I apologize for all of us for trying to provide you, the users, with a
> superior product, good QA, and convienent upgrades.
I think it is already established that you have no QA in the design sense.  
Bugs are handled pretty well, product is good, ego is a little on the high 
side, so in general thanks for a job well done.  Hey QA ain't everything, I'm 
the first to admit that, I'm just happy Gentoo is QAed to death like debian.

tony
-- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Seemant Kulleen]

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

foul language and high tempers -- this thread has degenerated.

For those of you interested in gcc 3.3 bugs, mosey on over to bugs.gentoo.org query for gcc 3.3 and you'll be presented with your list that you ask for. 

As for the rest of it, whether you choose to believe it or not, we ARE working towards getting information to be more accessible.  We're sorry it's not here right now, on several websites in 50 languages.  But such a thing is on its way.  The infrastructure (hardware, bandwidth, software) has been in development (no, please don't make sarcastic statements putting words in my mouth that we're building our own pc's and fiber optic cables, thanks) for a couple of months now.

As for clearly defined 1.4 goals, someone can repost them.

-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

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

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Matthew Kennedy]

Tony Clark <tclark@telia.com> writes:

> On Wednesday 25 June 2003 07.47, Jon Portnoy wrote:
>> On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote:
>> > On Wednesday 25 June 2003 06.04, Jon Portnoy wrote:
>> > > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
>> > > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
>> > >
>> > > [snip]
>> > >
>> > > > 1.  What is Gentoo 1.4.  What it may have been intended to be in
>> > > > January is probably not what it is going to be now.  Before you
>> > > > recruit all and sundry you have to define this as if it isn't defined
>> > > > everything will fall down and chaos will return.  Some basic things I
>> > > > see is that it needs to be are: gcc3.3 based
>> > > > glibc2.3.2
>> > > > openssl0.9.7
>> > >
>> > > We can do this if you want to wait another couple of months.
>> > >
>> > > Unfortunately, there are some requests to have 1.4 ready for LWESF at
>> > > the beginning of Augusy
>> >
>> > This is just classical, happens everyday type stuff in
>> > electronics/software companies, espically ones who don't know what they
>> > are building with clear goals.  Marketing keeps moving the requirements
>> > and dates aren't met.  Some deadline finally gets set and a patch work
>> > job happens to meet THE DATE.
>>
>> We know what we're building and have clear goals. Those goals have been
>> specified on this list by Daniel in the past.
> past day, week, month, year?  He has had about 4 posts here in the last 6 
> months.  Why isn't the QA guy demanding a list of packages to be included?
>>
>> With minor exceptions, _those goals are met_.
>
> What exceptions? Why the sudden panic then?
>>
>> However, you're now suggesting _entirely new_ goals that _do not fit_
>> with the schedule already in mind. Marketing is irrelevant - a few
>> people said "Do you think we'll be ready for LWESF?" and I said "Yes." I
>> intend to follow up on that, now that our goals are either met or about
>> to be met. There is no 'THE DATE' that we absolutely must adhere to.
>> Instead, I'm telling you that there is no technical way we can go with
>> gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a
>> significantly long period of time while work is done in those areas.
> Now above you say there is a deadline and here you say there isn't.  I can't 
> see how you can say I am describing new goals when you can't point me to a 
> document which states what the current goals are.  There is no QA as noone 
> can trace a specification pass back to a specified requirement.  I've 
> digressed into QA but thats actually what the total process should be about.
>
>> > > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7
>> > > needs a much more mature upgrade path, otherwise there will be serious
>> > > breakage (you need to remerge wget without ssl support, then merge the
>> > > new openssl, then rebuild everything depending on it currently).
>> >
>> > The OpenSSL upgrade is really ready, it just that the whole tree needs a
>> > rebuild which is time consumming.  You have to break the cycle sooner or
>> > later.  Seems to me one solution is to release a binary version of 1.4
>> > build with the latest OpenSSL goes someway to ease that upgrade.  Users
>> > can get a
>>
>> Certainly, new stage1 and stage2 installs would have no problem - they
>> haven't done an emerge system yet. A stage3 with openssl 0.9.7 would
>> have no problem. Existing users or people using old stage3s would be
>> screwed. We need a better upgrade path for that in order to avoid the
>> kind of "patch work job" you described earlier.
>>
>> With regards to 'breaking the cycle,' we need functionality in Portage
>> that either allows the ebuild to directly run revdep-rebuild or
>> incorporate revdep-rebuild into Portage (or preferably real reverse
>> dependencies, which will come in Portage 2.1 last I heard).
> Ok, now this is good.  All that is needed is to write these points down and 
> pretty soon you will end up with a requirement document that everyone can 
> understand, identify where they can be of most use and a check list you can 
> tick off when each thing is done.  Now the project is managed!  It really is 
> simple but because it is tedious, for a good designer, it is somewhat boring.
>
>>
>> > working basic system maybe with kde and gnome desktops then add or
>> > rebuild at their own pace.  New takers have no problems as they are
>> > current.  GCC is a slightly different problem but not as large.  I guess
>> > it could be solved putting different versions of GCC in slots.  Glibc is
>> > pretty well there and doesn't seem to have any problems that I have
>> > noticed.
>>
>> SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is
>> not ready for it. Many applications will not build and there are many,
>> many unsolved problems and weird issues that people can't track down.
>> GCC 3.3 is not production ready and I, for one, am not interested in
>> pushing people to release a broken compiler on the masses for the sake
>> of saying "we're up to date!" - can you please justify pushing GCC 3.3
>> before it's ready?
>
> I don't need too.  I'm not a gentoo developer, I just  help where I can, when 
> I can.  What you should be telling me is here is a url of the number of 
> packages that won't build with gcc3.3 in portage and here is another list 
> that we are not sure of.  Have that in an easy to find location then things 
> can start to happen.  It's all very well to say things are as broken as SCO's 
> kernel code but all I can say is, show me the list and I will see what I can 
> do to fix some of it. :)
>

Hi Tony,

This is the list I've started to work off of:

http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=gcc-3.3+gcc+3.3&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=everything+gcc3.1&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

There's really only 14 open bugs, however I leave the closed ones in
the list for historical interest.

Jon, GCC will never be perfect.  Like anything, there's always bugs,
so I wouldn't stress out too much :)

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Jon Portnoy]

On Wed, Jun 25, 2003 at 10:58:55AM -0700, Seemant Kulleen wrote:
> foul language and high tempers -- this thread has degenerated.

Indeed. I apologize to all -dev readers for contributing to that with 
sarcastic comments. I'm short on patience lately.

[snip]
> 
> As for clearly defined 1.4 goals, someone can repost them.
> 

Might be missing something, but off the top of my head...

- genkernel (completed but needs further testing)
- CFLAGS/CHOST autogeneration (almost completed)
- non-tmpfs baselayout (completed and in stable)
- GRP (jmorgan has done testing in this area - mainly we need to build and QA)

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Tony Clark]

On Wednesday 25 June 2003 20.48, Matthew Kennedy wrote:

> Hi Tony,
>
> This is the list I've started to work off of:
>
> http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwordssu
>
> There's really only 14 open bugs, however I leave the closed ones in
> the list for historical interest.

Thats pretty good really.  I guess the show stopper is the glib issues with 
gtk-2 as rebuilding dependancies isn't handled yet by portage IIRC.  Rest 
seem like drop the hammer patch and turn optimisation down on a couple of 
ebuilds.  Only problem I have with my own statement is I have no idea what 
the test coverage is like with the regression testing.  I'll try a couple of 
builds next week once I have moving house out of the way.  My head will be a 
little cooler then so I won't bark so loudly :)  I would guess a normal 
system build is only covering about 25% of the packages in portage.  A meta 
package to build everything non conflicting would be useful for this type of 
thing.

tony

-- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Some testing

[Tony Clark]

On Wednesday 25 June 2003 21.01, Jon Portnoy wrote:
> On Wed, Jun 25, 2003 at 10:58:55AM -0700, Seemant Kulleen wrote:
> > foul language and high tempers -- this thread has degenerated.
>
> Indeed. I apologize to all -dev readers for contributing to that with
> sarcastic comments. I'm short on patience lately.
It's not a problem.  It happens to everyone at times.

> > As for clearly defined 1.4 goals, someone can repost them.
>
> Might be missing something, but off the top of my head...
>
> - genkernel (completed but needs further testing)
Ok I was able to test this. Unfortunately it failed for me. I know I need to 
post a bug but that will have to wait till the morning.  The basic problem is
genkernel vanilla-sources --testing
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wn       
aphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe 
-mpreferr       k-boundary=2 -march=i386 -DMODULE -DMODVERSIONS -include 
/usr/src/linux-2.4.21       e/linux/modversions.h  -nostdinc -iwithprefix 
include -DKBUILD_BASENAME=sim710        sim710.o sim710.c
sim710.c: In function `sim710_driver_init':
sim710.c:589: `A_msg_reject_used' undeclared (first use in this function)
sim710.c:589: (Each undeclared identifier is reported only once
sim710.c:589: for each function it appears in.)
sim710.c:591: `A_test1_src_used' undeclared (first use in this function)
sim710.c:593: `A_test1_dst_used' undeclared (first use in this function)
sim710.c: In function `sim710_detect':
sim710.c:1580: `Ent_test1' undeclared (first use in this function)
sim710.c:1613: `A_int_test1' undeclared (first use in this function)
make[2]: *** [sim710.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.21/drivers/scsi'
make[1]: *** [_modsubdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.21/drivers'
make: *** [_mod_drivers] Error 2

A couple of comments.  The script doesn't source /etc/make.conf so it doesn't 
get march=athlon or make_opts="-j5" correct.  Builds a march=i386 kernel. 
using -j1
doesn't see distcc.
not sourcing /etc/make.conf maybe intential
didn't build smp support.
It doesn't check that the kernel source is alreay installed.

tony


-- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623



--
gentoo-dev@gentoo.org mailing list