[gentoo-dev] State of Developement

[gentoo-dev] State of Developement

[Paul]

	Hi;

	I am curious about the state of gentoo; I feel I have a
material interest, as I try to report bugs, submit patches, and
ebuilds because I want to make this distribution better for me.
	I have noticed that the numbers assigned to each of my
new bug reports has been advancing at such a high rate over time,
that I am given to wonder if the developers can keep up. My
ebuilds especially have seemed to languish lately.
	How are you guys doing? Do you have any areas that you
would like us to focus on? (eg. QA) I could squeeze out ebuilds
regularly, but I tend to wait on those in the pipeline.
	I havent checked, but is gentoo-core still closed?
Could it be read-only, maybe only in digest form? The more
I know about where this project is going, the more motivated
I am to help, rather than say, sitting back on my haunches
and waiting. (something I have been unable to do so far:)
	I am not suggesting make gentoo democratic, just take
advantage of those who are not part of the core team better,
by giving more guidance.

Paul
set@pobox.com

Re: [gentoo-dev] State of Developement

[Henti Smith]

On Mon, 26 Aug 2002 02:43:46 -0400
Paul <set@pobox.com> wrote:

> 	Hi;
> 
> 	I am curious about the state of gentoo; I feel I have a
> material interest, as I try to report bugs, submit patches, and
> ebuilds because I want to make this distribution better for me.
> 	I have noticed that the numbers assigned to each of my
> new bug reports has been advancing at such a high rate over time,
> that I am given to wonder if the developers can keep up. My
> ebuilds especially have seemed to languish lately.
> 	How are you guys doing? Do you have any areas that you
> would like us to focus on? (eg. QA) I could squeeze out ebuilds
> regularly, but I tend to wait on those in the pipeline.
> 	I havent checked, but is gentoo-core still closed?
> Could it be read-only, maybe only in digest form? The more
> I know about where this project is going, the more motivated
> I am to help, rather than say, sitting back on my haunches
> and waiting. (something I have been unable to do so far:)
> 	I am not suggesting make gentoo democratic, just take
> advantage of those who are not part of the core team better,
> by giving more guidance.

Well said. :)) 

I have to agree. there are alot of non-core people on this list and just itching to help out in any respect possible.
Maybe assign a new core member to "public relations" to help up and coming developers in helping where you guys need the most help but cannot warrent 
spending core members time doing.

Henti Smith

Re: [gentoo-dev] State of Developement

[Preston A. Elder]

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

On Monday 26 August 2002 02:43 am, Paul wrote:
> 	I have noticed that the numbers assigned to each of my
> new bug reports has been advancing at such a high rate over time,
> that I am given to wonder if the developers can keep up. My
> ebuilds especially have seemed to languish lately.
As more users (especially inexperienced and bug-happy ones) use gentoo, more 
bugs get raised, often times to be marked as duplicates or user error.

As for the ebuilds languisihing longer, there are two reasons for this.  
First, we try to give bugs higher priority ... the whole 'clean up your house 
as is before taking in more mess', and
Second, we're gearing up to release gentoo 1.4, which means theres basically 
no new packages being added to the tree unless we want to justify it to 
Daniel Robbins (which makes sense, you dont want to keep introducing more 
problems when your trying to stabalize a release).

> 	How are you guys doing? Do you have any areas that you
> would like us to focus on? (eg. QA) I could squeeze out ebuilds
> regularly, but I tend to wait on those in the pipeline.
re: where to focus on, thats not my domain, however documentation is ALWAYS 
appreciated (developers hate documenting things ;).  As for the new ebuilds, 
you can submit them to bugzilla, just dont expect them to be added to the 
system before 1.4 is released.

> 	I havent checked, but is gentoo-core still closed?
yes, it is.

> Could it be read-only, maybe only in digest form? The more
> I know about where this project is going, the more motivated
> I am to help, rather than say, sitting back on my haunches
> and waiting. (something I have been unable to do so far:)
Why not email Daniel directly about this :)

- -- 
PreZ
Developer
Gentoo Technologies
http://www.gentoo.org

I wish I could change the world, but God won't give me the source code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9aghoV+1AOejiuzYRAqI6AJ96enDPBj67RGbQPeBwi8lgziWF+wCfSruS
AU1+ZxTLFLfk8aV+KNcQDe8=
=WGmC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] State of Developement

[Jeremiah Mahler]

On Mon, Aug 26, 2002 at 06:52:19AM -0400, Preston A. Elder wrote:
> 
> On Monday 26 August 2002 02:43 am, Paul wrote:
> > 	I have noticed that the numbers assigned to each of my
> > new bug reports has been advancing at such a high rate over time,
> > that I am given to wonder if the developers can keep up. My
> > ebuilds especially have seemed to languish lately.
> As more users (especially inexperienced and bug-happy ones) use gentoo, more 
> bugs get raised, often times to be marked as duplicates or user error.
> 
> As for the ebuilds languisihing longer, there are two reasons for this.  
> First, we try to give bugs higher priority ... the whole 'clean up your house 
> as is before taking in more mess', and
> Second, we're gearing up to release gentoo 1.4, which means theres basically 
> no new packages being added to the tree unless we want to justify it to 
> Daniel Robbins (which makes sense, you dont want to keep introducing more 
> problems when your trying to stabalize a release).
> 
And they have to go through a specific set of privileged people.

> > 	How are you guys doing? Do you have any areas that you
> > would like us to focus on? (eg. QA) I could squeeze out ebuilds
> > regularly, but I tend to wait on those in the pipeline.
> re: where to focus on, thats not my domain, however documentation is ALWAYS 
> appreciated (developers hate documenting things ;).  As for the new ebuilds, 
> you can submit them to bugzilla, just dont expect them to be added to the 
> system before 1.4 is released.
> 
Q: Can I help, can I help
A: Sure, you can take out the trash and scrub the toilets.

> > 	I havent checked, but is gentoo-core still closed?
> yes, it is.
> 
Ivory tower?

> - -- 
> PreZ
> Developer
> Gentoo Technologies
> http://www.gentoo.org
> 

As a user of Gentoo, I feel like a child whose parent has to double
check everything I do. And in the same way that the child 
becomes frustrated with their parent because they place no trust
in the child, I am frustrated with Gentoo because it places no
trust in the users.

Among all the distributions I am familiar with, Gentoo is,
in my opinion, the best as far as placing trust in it's users.
But Gentoo is also, in my opinion, far from what I imagine as ideal.

-- 
Jeremiah Mahler
<jmahler@pacbell.net>

Re: [gentoo-dev] State of Developement

[Grant Goodyear]

> And they have to go through a specific set of privileged people.

True, although to the best of my knowledge all distributions have
a similar system.  I don't think it will ever make sense to 
provide CVS write access to all users; it's simply too easy to
mess things up.  Goodness knows that our developers regularly 
manage to render Gentoo uninstallable, and they're trying very
hard not to do that.  Our system isn't perfect, but I'm not sure
what would be better.

> Q: Can I help, can I help
> A: Sure, you can take out the trash and scrub the toilets.

Well, right now that's pretty much what the developers are doing,
too.  Our biggest need for help right now is good bug reports and
help with existing bugs.  The only major "development" that is
ocurring right now is portage and some people starting to work on
a sensible installer.  Everything else is really bug fixing of 
one sort or another.

> > > 	I havent checked, but is gentoo-core still closed?
> > yes, it is.
> > 
> Ivory tower?

The original rationale for closing gentoo-core was that it allowed
developers a chance to propose wacky ideas (and get shot down) 
with minimal embarrassment (and without generating a flood of
"hey, some dev wants to do _this_!) posts on the mailing lists
and forums.  I don't particularly have an objection to gentoo-core
being made read-only.  I certainly think it would be an improvement from 
a PR standpoint.  At the same time, I could also see how making the
list truly public might cut down on the number of "hey, some unnamed devs 
have been doing _this_, and it really has to stop!" messages that need
to be sent but might not be if everybody gets to read our "dirty
laundry", so to speak (and mix metaphors).

> As a user of Gentoo, I feel like a child whose parent has to double
> check everything I do. And in the same way that the child 
> becomes frustrated with their parent because they place no trust
> in the child, I am frustrated with Gentoo because it places no
> trust in the users.

That's an interesting argument, because I would still argue that
other than Linux From Scratch, Gentoo provides users with more 
flexibility than does any other distribution.  If you want to 
play with a masked ebuild, unmask it.  If you want an ebuild
that has been languishing on bugzilla for a while, download it
and emerge it (or write it, if that's necessary).  If you want
to be a developer, start fixing bugs on bugzilla and make your
good work known.  If nobody gets around to inviting you to be
a developer, e-mail me and tell me what you've been doing, and
I'll look into it and get back to you.  I'm pretty sure that
nobody is actually trying to be rude, but we all are quite
definitely overworked.

> Among all the distributions I am familiar with, Gentoo is,
> in my opinion, the best as far as placing trust in it's users.
> But Gentoo is also, in my opinion, far from what I imagine as ideal.

Fair enough.  If you have additional ideas on how we can trust our
users better, please do post on bugzilla.

-g2boojum-
-- 
Grant Goodyear				The Secrets of Physics:
Dept. of Chemistry			1. Add zero.
Clemson University			2. Multiply by one.
Clemson, SC  29617			3. Expand in a Taylor series
e-mail: grant@grantgoodyear.org		4. Integrate by parts.
http://www.grantgoodyear.org		5. Fourier transform.

Re: [gentoo-dev] State of Developement

[Dominik Westner]

Well, first let me say that Gentoo is the first Linux distribution I 
really like. It's not yet perfect but it's getting there.
It's also the first distribution I would like to get involved more.

I have submitted some ebuilds and most of the ended up in portage quite 
quickly. Some have been reworked a little bit, which I appreciate a 
lot, because you see how to make it better. About some (very few) I 
never heard back (e.g. Darwin Streaming Server). I don't know why, but 
maybe nobody cared about the packages.
I also submitted bug reports and got lots of feedback. So I am very 
happy about this, even if so far none of my suggestions made it into 
the system, which is ok, because I feel that the people are really busy 
with other things and for me it's easy to setup the system the way I 
like it.


On Montag, August 26, 2002, at 09:28 PM, Grant Goodyear wrote:

>> And they have to go through a specific set of privileged people.
>
> True, although to the best of my knowledge all distributions have
> a similar system.  I don't think it will ever make sense to
> provide CVS write access to all users; it's simply too easy to
> mess things up.  Goodness knows that our developers regularly
> manage to render Gentoo uninstallable, and they're trying very
> hard not to do that.  Our system isn't perfect, but I'm not sure
> what would be better.

One cool think, I would really like to see is a public read/write 
third-party portage tree (simillar the way PORTDIR_OVERLAY works now 
locally).
This would not be checked by default, but one could enable it. Once 
ebuilds stabilize they could be moved from there into the main portage 
tree.
This would take the burden from the core team to do QA and rework 
submitted ebuilds. And people submitting ebuilds would get much more 
feedback. And the maintainer would be the person, who submitted the 
ebuild not somebody from the core team ;-)

I guess we could do that right now by setting up a sf project and hack 
the portage tools. (or simply use PORTDIR_OVERLAY for this purpose).

>
>> Q: Can I help, can I help
>> A: Sure, you can take out the trash and scrub the toilets.
>
> Well, right now that's pretty much what the developers are doing,
> too.  Our biggest need for help right now is good bug reports and
> help with existing bugs.  The only major "development" that is
> ocurring right now is portage and some people starting to work on
> a sensible installer.  Everything else is really bug fixing of
> one sort or another.


Please, no installer ;-) The way of installing gentoo is so simple and 
straight forward, I could not imagine an easier install.

Dominik

Re: [gentoo-dev] State of Developement

[George Shapovalov]

Hi Grant, Jeremiah

On Monday 26 August 2002 12:28, Grant Goodyear wrote:
> > And they have to go through a specific set of privileged people.
>
> True, although to the best of my knowledge all distributions have
> a similar system.  I don't think it will ever make sense to
> provide CVS write access to all users; it's simply too easy to
> mess things up.  Goodness knows that our developers regularly
> manage to render Gentoo uninstallable, and they're trying very
> hard not to do that.  Our system isn't perfect, but I'm not sure
> what would be better.
Jeremiah: yup, above is quite to the point. I'd second all that Grant has 
said. However there is some hope for more general user involvment. Please 
read below...

> > Q: Can I help, can I help
> > A: Sure, you can take out the trash and scrub the toilets.
>
> Well, right now that's pretty much what the developers are doing,
> too.  Our biggest need for help right now is good bug reports and
> help with existing bugs.  The only major "development" that is
> ocurring right now is portage and some people starting to work on
> a sensible installer.  Everything else is really bug fixing of
> one sort or another.
This is quite true, core developers spend large portion of their time "taking 
out the trash". However I am afraid that we are pretty stuck in this mode the 
way things are now. The problem is: these bugs are mostly not ours, but 
rahter due to ignorance/weirdness/etc of upstream stuff, I mean here original 
authors of the packages. It would be a life in heaven if everything installed 
via "./configure && make && make install". All packages would compile on any 
arch and glibc/gcc version and no weir dependencies were lost in docs and 
nothing would conflict... Well, you get the idea. Unfortunately this is our 
imperfect word where everything tends to break and noticeable portion of bugs 
require getting in touch with package authors or figuring out just what 
build/configuration changes were implemented in this new revision?
   Things will get better when we release 1.4, however I am afraid not by 
much.

The point I am getting at here is that we should and can allow our users to 
take care of a large portion of non-crytical packages. What we need is:
1. Multiple stability levels or KEYWORDS
2. Streamlined ebuild processing - that automates submission of new 
ebuilds/versions and assigns them some kind of "new" or "user-test" 
keyword/level
3.Feedback system that collects user voices and moves ebuilds to corresponding 
categories increasing or decreasing their stability rating.
4. Core group oversees and takes care of the core/crytical stuff and has 
*much* more time to work onportage/sysinit/other_more_distro_specifc_stuff
Well, that would be one possible point of view on this :).

Please take a look at bug#1523 for much more details (though bear in mind that 
some of that stuff is outdated by now).

> > Among all the distributions I am familiar with, Gentoo is,
> > in my opinion, the best as far as placing trust in it's users.
> > But Gentoo is also, in my opinion, far from what I imagine as ideal.
>
> Fair enough.  If you have additional ideas on how we can trust our
> users better, please do post on bugzilla.
That's what I did over half a year ago. Since then I got involved in gentoo 
more than I imagined :).

So, the situation can (and I think should) be changed to give even more 
freedom to our users (and take some stress off core group simultaneously ;)). 
However as any change this takes time, especially with a large evolving 
system which gentoo became. At present we are near completion of step 1 in 
that partial list above (I mean here the KEYWORDS that we were so busy 
adding. As things settle down we will switch to this new masking mechanism 
and get even some more functionality into. At least this was the plan 
according to discussions/announcements over past few month). Eventually I 
hope we will get some more issues resolved and will be offering:
1. multitude of profiles (not just arch/gcc specific but tailored to certain 
tasks: such as server vs desktop, etc.)
2. partial [portage tree] database checkout (according to profile or stability 
setting)
3. streamlined/user_managed ebuild submissions (for non-crytical stuff)
4. anything else?

And it all takes quite some work, so any help is appreciated; but then any 
exciting project has a lot of routine associated with it.

George

Re: [gentoo-dev] State of Developement

[Daniel Mettler]

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

george (et al.),

On Tuesday 27 August 2002 00:24, George Shapovalov wrote:
> original authors of the packages. It would be a life in heaven
> if everything installed via "./configure && make && make
> install". All packages would compile on any arch and glibc/gcc
> version and no weir dependencies were lost in docs and nothing
> would conflict...

ack.

> Well, you get the idea. Unfortunately this
> is our imperfect word where everything tends to break and

ack. nevertheless i'd like to add that gentoo is particularly and 
implicitly vulnerable to such issues as some troubles are 
"home-made by concept".

1) gentoo uses performance optimizations by default (which 
sometimes lead to non-deterministic, non-reproducible results 
which are particularly hard to track down and solve, e.g. 
parallel make)

2) gentoo users usually further tweak their systems (aggressive 
gcc flags, ...)

3) while better performance is desirable one must be aware (i 
think most gentooers are) that things tend to be less stable, 
less predictable the more aggressive and uncommon the 
performance optimizations are.

gentoo also uses the latest app releases which are less 
thouroughly tested by nature and consequences not entirely clear 
from the beginning (introduction of non-backwards-compatible 
changes, e.g. libvorbis).

now i do not say that this is bad practice or a conceptually 
wrong, i just say that this implicitly means that gentoo is a 
"bleeding edge" distro and that this is gentoo's (and its 
community's) own decision (thus no self-pity, please ;)

the same goes for greater flexibility which is fine but makes 
*any* testing approach pretty tough to unmanageable (see 
combinatorics ;). in real world, there will always be a 
trade-off between performance optimizations, flexibility and 
stability.

> changes were implemented in this new revision? Things will get
> better when we release 1.4, however I am afraid not by much.

well, it's some bad luck currently with these horrible gcc 2.95.3 
- -> gcc 3.1 -> gcc 3.2 changes. as the gcc devs have declared to 
take better care of backwards compatibility in the future, i 
hope things will stabilize.

> The point I am getting at here is that we should and can allow
> our users to take care of a large portion of non-crytical
> packages. What we need is: 1. Multiple stability levels or
> KEYWORDS

ack.

> 2. Streamlined ebuild processing - that automates submission
> of new ebuilds/versions and assigns them some kind of "new" or
> "user-test" keyword/level

ack.

> 3.Feedback system that collects user voices and moves ebuilds
> to corresponding categories increasing or decreasing their
> stability rating.

ack. the barrier for giving feedback should be as low as possible 
and feedback should be given instantly. i.e. emerge should give 
the user an option to send a standardized bug-report by more or 
less just hitting enter when an ebuild fails (i think this has 
been discussed several times on this list already).

rule: you can always trash submitted, bad (useless) bug-reports 
but you can't get bug-reports that were not submitted. 
standardizing bug-reports should also help in improving their 
quality.

> 4. Core group oversees and takes care of the
> core/crytical stuff and has *much* more time to work
> onportage/sysinit/other_more_distro_specifc_stuff Well, that
> would be one possible point of view on this :).

addendum regarding qa: perhaps a more process-oriented 
organization would help improving qa and take some pressure from 
core-devs? has this ever been evaluated? how is qa organized 
atm?

disclaimer: i do not know how gentoo-core is really organized (i 
do not think anybody outside of gentoo-core does). i think some 
more information about gentoo's internal organization, tasks, 
release schedules and targets for non-gentoo-core people would 
be very much appreciated and would enhance confidence, 
predictability and thus the coordination of own activities. 
gentoo-core still looks like some kind of a blackbox to me as 
what regards these points. is this really intended?

> Please take a look at bug#1523 for much more details (though
> bear in mind that some of that stuff is outdated by now).

i've only skimed your proposal but it looks fine to me. is there 
any reason why gentoo-core has not approved it yet?

summa summarum:

1.) gentoo as a distro has its own strengths and weaknesses
2.) organization is a very important thing when managing software 
projects
3.) information flow from gentoo-core to gentoo-dev/-user and 
vice-versa is important

regards

dan

- -- 
      ...::: Daniel Mettler | http://www.numlock.ch :::....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9as5ASLYjgrGjnWQRAsroAJ40C3TJCCZmVKy0zaYFD37jrA1kHACeJu1l
A9+Z8QG4R/T2Ywg1nPguzis=
=eC5U
-----END PGP SIGNATURE-----

Re: [gentoo-dev] State of Developement

[George Shapovalov]

Hi guys.

I'll answer this message, as I think this will cover some questions by Evan as 
well.

> > Well, you get the idea. Unfortunately this
> > is our imperfect word where everything tends to break and
> ack. nevertheless i'd like to add that gentoo is particularly and
> 1) gentoo uses performance optimizations by default (which
> 2) gentoo users usually further tweak their systems (aggressive
> 3) while better performance is desirable one must be aware (i
> think most gentooers are) that things tend to be less stable,
> less predictable the more aggressive and uncommon the
> performance optimizations are.
Well, this is what freedom is about. We cannot do much about this short of 
locking users to certain precompiled binaries, as debian does. You should 
think of gentoo more in terms of a meta-distribution with the ability to set 
or screw things next to only Linux From Scratch. Some breakage by the more 
advantrous types is inevitable, while on the other hand I saw reports by 
people running gentoo on servers without any problems (and of course they do 
not run the daily cron job of "emerge rsync &&emerge -u world" :) ).

> gentoo also uses the latest app releases which are less
> thouroughly tested by nature and consequences not entirely clear
> from the beginning (introduction of non-backwards-compatible
> changes, e.g. libvorbis).
Good point. Eventually this will be remedied by the stable profile which will 
lock packages to the approved stable versions for the most part. Please do 
not confuse with branches: there is no point in branching gentoo. It is far 
better to have a big general database and subset it (via profiles or KEYWORDS 
of what we have at present) on order to get the system tailored for the 
certain task. 
However bear in mind, that gentoo is a young distribution (guess why we are 
1.4 now and not say 7.5?). We are in early stages of implementing all these 
features.


> the same goes for greater flexibility which is fine but makes
> *any* testing approach pretty tough to unmanageable (see
> combinatorics ;). in real world, there will always be a
> trade-off between performance optimizations, flexibility and
> stability.
This is why we really depend on you - our users. We perform significant amount 
of testing before new packages or versions are incorporated into the tree 
(and this is a part of the reason new submissions take long time to be 
processed). However it is not possible to cover all possible combinations of 
architectures, package and compiler versions and combinations. More important 
packages get tested more, less important..., well, this is what this 
multistability user-driven ebuild processing concept is about: to let 
interested users help us and themselves simultaneously.


> > 3.Feedback system that collects user voices and moves ebuilds
> > to corresponding categories increasing or decreasing their
> > stability rating.
> ack. the barrier for giving feedback should be as low as possible
> and feedback should be given instantly. i.e. emerge should give
> the user an option to send a standardized bug-report by more or
> less just hitting enter when an ebuild fails (i think this has
> been discussed several times on this list already).
If you have some tight concept or a good idea, please contribute it. Answering 
to this thread or posting a comment to that bug I mentioned (and there are 
some more) are the ways to get your word to developers.
(This is a general remark, I see you do just that below. Thanks for that!)

> rule: you can always trash submitted, bad (useless) bug-reports
> but you can't get bug-reports that were not submitted.
> standardizing bug-reports should also help in improving their
> quality.
True. Also it should be kept in mind that the feedback system should be 
largely automatic and well balanced (so that popularity of the package does 
not influence its stability ratings too much for example).


> disclaimer: i do not know how gentoo-core is really organized (i
> do not think anybody outside of gentoo-core does). i think some
> more information about gentoo's internal organization, tasks,
> release schedules and targets for non-gentoo-core people would
> be very much appreciated and would enhance confidence,
> predictability and thus the coordination of own activities.
> gentoo-core still looks like some kind of a blackbox to me as
> what regards these points. is this really intended?
Good point. 
The intent is to have some place for "wild" discussions, which might 
potentially and unnecessarily upset users: "gentoo devs want to do this evil 
thing!" while it was merely a trial suggestion that was shot down quickly 
afterwards. Core devs are encouraged to take questions that require user 
feedback or general discussion to the gentoo-dev.


> > Please take a look at bug#1523 for much more details (though
> > bear in mind that some of that stuff is outdated by now).
>
> i've only skimed your proposal but it looks fine to me. is there
> any reason why gentoo-core has not approved it yet?
Well, its not that it has not been approved, its more the issue of difference 
between accepting some idea and implementing it :).
It does take quite some work and time to do things, especially that touch the 
core of the system and require updates to majority or all the ebuilds. We 
just recently had a large session of KEYWORD additions. This required all 
developers to retest and modify their ebuilds (or all the ebuilds they 
oversee). This is not over yet, but nearing completion, thus taking care of 
the larger part of step 1 (as in my previous message). Other parts of that 
proposal will have to be settled and implemented as well. Particularly a good 
discussion on the feedback/voting system may help to settle at least the 
design.

And thanks for the thoughts!

George

[gentoo-dev] 1.4beta compliment, complaint, question, suggestion

[Fuper]

I picked up a Fujitsu 9G 10,000 rpm SCSI drive for $75, downloaded the
Gentoo .1.4beta portage and stage1 tarballs, and did a test making a
clean install of the (hidden) beta version of Aug 22nd.

[Dual P3 800 MHz, 512 MB ECC SDRAM, three Ultra2 SCSI drives and jaz
drive, two IDE drives and cd-rw/dvd, mixed reiser, ext3 and ext2 ---
/boot with grub is a separate ext2 partition the way God intended and
now serves to boot either the old Gentoo-1.2 or the new Gentoo-1.4b]


Compliment:

The install went onto a couple of new reiser partitions smoothly.  The
bootstrap.sh completed (after I realized that 512MB of /var space is not
nearly enough for a Gentoo bootstrap); the system emerge completed, and
the 2.4.19 vanilla-kernel compiled without a hitch and rebooted my
system.

Thanks developers!  Now I have a gcc-3.2 compiled system and it is very
fast (especially on that 10000 rpm Fujitsu drive).


Complaint:

The cleanly emerged cups-1.1.15 did not work.  This is with a
_postscript_ printer, an HP 5MP.  Any print job is canceled immediately
by the print subsystem.  I was disgusted because this is the third time
I have tried to run Gentoo cups-1.1.15.  I thought that surely it would
be ok on a fresh install.  It's not ok.  :-p

I had to fall back to cups-1.1.14-r4, which worked flawlessly.


Question:

I installed Sylpheed and started it up to configure my mail but it
immediately aborted with the message
    Bind:  permission denied
What permission?  My network is setup ok and I can get onto Internet
through my firewall with Mozilla; I don't see any problem with
tcp-wrappers and such. This error occurs before Sylpheed even takes note
that there's no ~/.sylpheed directory and asks for configuration
information.

What can cause this "Bind" problem?  I'd appreciate help from a more
clueful person because I'm feeling lost about that error message and
don't know how to get past it.  Of course, now I'm booting from my old
partitions with Gentoo 1.2 because my Gentoo 1.4b doesn't do mail :-<


Suggestions:

- Put a statement in the install docs that /var/tmp requires a gigabyte
of space.  I think that the doc now says mildly that it will use several
hundred megabytes.  Most users will assume that 512 MB qualifies as
"several hundred megabytes", but it wasn't enough for me.  Say "almost a
gigabyte".

- Mask out cups-1.1.15 until it is fixed. 



Thanks if you can help with my mail problem...

Re: [gentoo-dev] 1.4beta compliment, complaint, question, suggestion

[mike]

> Complaint:
> 
> The cleanly emerged cups-1.1.15 did not work.  This is with a
> _postscript_ printer, an HP 5MP.  Any print job is canceled immediately
> by the print subsystem.  I was disgusted because this is the third time
> I have tried to run Gentoo cups-1.1.15.  I thought that surely it would
> be ok on a fresh install.  It's not ok.  :-p
> 
> I had to fall back to cups-1.1.14-r4, which worked flawlessly.

http://bugs.gentoo.org/show_bug.cgi?id=4522
this is a known issue that is being worked on ... also being worked on
by egs/cups people (google for their mailing list posts)
-mike

Re: [gentoo-dev] 1.4beta compliment, complaint, question, suggestion

[Karl Trygve Kalleberg]

On 27 Aug 2002, Fuper wrote:

> - Put a statement in the install docs that /var/tmp requires a gigabyte
> of space.  I think that the doc now says mildly that it will use several
> hundred megabytes.  Most users will assume that 512 MB qualifies as
> "several hundred megabytes", but it wasn't enough for me.  Say "almost a
> gigabyte".

It really depends on whether you go for stage1, 2 or 3, which and how many
packages you install and which useflags you require.

As stated elsewhere on this list, you "may need 5GB". This uncertainty is
a price you have to pay for being able to customize so much. The docs
should probably be clearer about that..

File a bug on it.


Kind regards,

Karl T

Re: [gentoo-dev] State of Developement

[Evan Read]

On Mon, Aug 26, 2002 at 03:24:40PM -0700, George Shapovalov wrote:

<snip>

> The point I am getting at here is that we should and can allow our users to 
> take care of a large portion of non-crytical packages. What we need is:
> 1. Multiple stability levels or KEYWORDS
> 2. Streamlined ebuild processing - that automates submission of new 
> ebuilds/versions and assigns them some kind of "new" or "user-test" 
> keyword/level
> 3.Feedback system that collects user voices and moves ebuilds to corresponding 
> categories increasing or decreasing their stability rating.
> 4. Core group oversees and takes care of the core/crytical stuff and has 
> *much* more time to work onportage/sysinit/other_more_distro_specifc_stuff
> Well, that would be one possible point of view on this :).

Keywords, hey?  So I could track a stable tree that doesn't change so much 
and doesn't break? Is this coming with 1.4?
 
> 1. multitude of profiles (not just arch/gcc specific but tailored to certain 
> tasks: such as server vs desktop, etc.)

Oh sweet ;) desktop+stable? ;)

> And it all takes quite some work, so any help is appreciated; but then any 
> exciting project has a lot of routine associated with it.

This sounds good George.  I have been evaluating Gentoo of the last few 
days and I keep coming back to "it needs a stable tree".  I really hate 
breakages. I would prolly be willing to test new stuff in VMWare or UML, 
but not my main system.

I think that having different, trackable releases would be a turning point 
for the distribution.  It could become useful for production.


p.s.  Is there a page that lists new stuff coming in 1.4?

Thanks!

-- 
Evan Read
http://eread.freeshell.org

"The future comes 60 minutes an hour no matter who you are or what you 
do." 
	The Screwtape Letters - C.S. Lewis

Re: [gentoo-dev] State of Developement

[Evan Read]

On Mon, Aug 26, 2002 at 11:01:02AM -0700, Jeremiah Mahler wrote:

> > re: where to focus on, thats not my domain, however documentation is ALWAYS 
> > appreciated (developers hate documenting things ;).  As for the new ebuilds, 
> > you can submit them to bugzilla, just dont expect them to be added to the 
> > system before 1.4 is released.
> > 
> Q: Can I help, can I help
> A: Sure, you can take out the trash and scrub the toilets.

And what the problem? If you don't like the way the developers dish out 
duties on their OS, don't use it. Developing ebuilds that might make a 
release that isn't coming out in the next month sounds generous to me.

 
> > > 	I havent checked, but is gentoo-core still closed?
> > yes, it is.
> > 
> Ivory tower?

Their prerogative.

> As a user of Gentoo, I feel like a child whose parent has to double
> check everything I do. And in the same way that the child 
> becomes frustrated with their parent because they place no trust
> in the child, I am frustrated with Gentoo because it places no
> trust in the users.

Maybe you should maintain a large collection of ebuilds outside of their 
tree or maybe maintain your own stable branch of Gentoo to _build_ the 
trust instead complaining that you can be trusted with no proof (I assume 
what you have written here is all you have communicated to the 
developers).
 
> Among all the distributions I am familiar with, Gentoo is,
> in my opinion, the best as far as placing trust in it's users.
> But Gentoo is also, in my opinion, far from what I imagine as ideal.
> 

So they don't trust you, and they trust you? As far as I am concerned, 
until you have CVS commit access, they don't trust you.  But that is ok.  
Because I implicitly trust them.  Well, I am not sure I do, hence Gentoo 
runs in VMWare for me).  I want them to save me from myself. gentoo-core 
can't break!


At the end of the day, it is their project.  They ask you to submit bug 
reports (with patches if you like) and to test. To do all the things a 
developer does.  They just tell you they would like to look at the quality 
of your submissions before they are commited.

Why aren't you thanking God that is the case? You should be afraid to ask 
for commit access on a source tree (which I assume gentoo-core would 
imply).

Read this: 
http://www.onlamp.com/pub/a/bsd/2002/01/31/Big_Scary_Daemons.html


Thanks.

-- 
Evan Read
http://eread.freeshell.org

"The future comes 60 minutes an hour no matter who you are or what you 
do." 
	The Screwtape Letters - C.S. Lewis