[gentoo-dev] What should be in place before 1.0 release

[gentoo-dev] What should be in place before 1.0 release

[Karl Trygve Kalleberg]

Hi gang.

I just like to voice my opinion about issues that should be addressed
before the release of Gentoo Linux 1.0 (hurrah!)

While I can to a large degree accept that the distro itself is technically
ready enough to be released, our development team is in no way prepared to
handle the influx of new users.

At minimum, we should have the following points fixed:
1) A proper bug-reporting system. We simply won't be able to keep track of
the issues cropping up in gentoo-{dev,users,ebuild,whatever} given the
current developer situation.
2) A flawless installation guide. This means that we should do the
installation of the 1.0 version in a handful of different configurations
and make certain the installation guide is not only correct, but succinct
and unambiguous. This is tricky, but every hour we spend fixing it before
final release, will save us tenfold down the line.
3) Verify that all our ebuilds actually work as advertised. Some ebuilds
seem to be more error-prone than others (minicom, koffice). The ones that
have any problems whatsoever should be masked out until we know that they
really work.
4) In a related note, we should have a
"grace-period"/"codeslush"/"codefreeze" of at least one week where we do
not add new stuff, and do nothing but bug-squashing. We should verify that
*all* ebuilds have been tested, preferrably with *all* their optional USE
arguments.
5) We should have a release plan on the web, a task-list if you will,
where we check off items as we progress along to 1.0. This will hopefully
work as a great motivator once we're over half-way ;)
6) We should officially nominate a Release Manager (I guess this will be
drobbins, but it would be nice for everybody, including non-developers, ie
hardcore Gentoo testers to know who's neck is on the block ;).
7) Perhaps we even should have a release team that acted as drobbins'
elven helpers and make certain that all the items on the task-list are
addressed in a timely fashion. Perhaps all the developers should just act
as elven helpers.. 

Hope this sets thoughts churning. If we want 1.0 to be stable and good, we
will have to put a lot of effort into it, and do so in a structured
fashion. The all-nighter "throw code at it until it works" is NOT an
option. 


Kind regards,

Karl T

Re: [gentoo-dev] What should be in place before 1.0 release

[Dan C]

Just an addition to the list, I think a gentoo-newbie mailing list would be
a good idea. I personally have been fooling around with Gentoo since pre
1.0_rc5, and it's my first in depth linux experience (RH -> Drake -> RH ->
Slackware (for a while) -> Gentoo), and I really like it. Yet I don't feel
my knowledge justifies asking questions to gentoo-dev, and conversation in
the chat room comes in and out like waves.

So, I sugest a gentoo-newbie list to allow guilt free posting for all of us
with lesser problems. (And as Karl sated, we're going to have quite a few
newbies (hopefully) soon. The quicker we get them up, running, and
contributing ebuilds the better).

-DSB

Re: [gentoo-dev] What should be in place before 1.0 release

[Blue Lizard]

Karl Trygve Kalleberg wrote:
> Hi gang.
> 
> I just like to voice my opinion about issues that should be addressed
> before the release of Gentoo Linux 1.0 (hurrah!)
> 
> While I can to a large degree accept that the distro itself is technically
> ready enough to be released, our development team is in no way prepared to
> handle the influx of new users.
> 
> At minimum, we should have the following points fixed:
> 1) A proper bug-reporting system. We simply won't be able to keep track of
> the issues cropping up in gentoo-{dev,users,ebuild,whatever} given the
> current developer situation.

bugzilla _could_ handle this, but while it is technically ready enough 
our development team is in no way prepared to handle the influx of new 
users that would find it a pain in the neck to use.

> 2) A flawless installation guide. This means that we should do the
> installation of the 1.0 version in a handful of different configurations
> and make certain the installation guide is not only correct, but succinct
> and unambiguous. This is tricky, but every hour we spend fixing it before
> final release, will save us tenfold down the line.

Personally, I was surprised at the quality of the 1.0_rc6 install from 
source guide.  Could be some improvements, but it is a nice place to 
start from.

> 3) Verify that all our ebuilds actually work as advertised. Some ebuilds
> seem to be more error-prone than others (minicom, koffice). The ones that
> have any problems whatsoever should be masked out until we know that they
> really work.

A good way for ebuild to handle apps that dont flag/opt well would be 
nice, other than hard coding everything :)  Like if a build is known to 
spark out when a given portion is compiled -O3, knock it down to -O2 
(IOW ebuild parses out flags in make.conf and handles wisely, according 
to the writers instructions.)

> 4) In a related note, we should have a
> "grace-period"/"codeslush"/"codefreeze" of at least one week where we do
> not add new stuff, and do nothing but bug-squashing. We should verify that
> *all* ebuilds have been tested, preferrably with *all* their optional USE
> arguments.

You are out of your mind.  One week?  DUDE!  This is a 1.0 release of 
what could be a major mainstream linux distribution.  One week?

> 5) We should have a release plan on the web, a task-list if you will,
> where we check off items as we progress along to 1.0. This will hopefully
> work as a great motivator once we're over half-way ;)

Yes, and the idea is that up until the very minute that feature freeze 
goes into effect, anything and everything goes on that list.  Someone 
gets the slightest little notion of something that'd be cool and POOF!, 
on the list.  Just that stuff more whimish than others would be in a 
diff priority class for obvious reasons.

> 6) We should officially nominate a Release Manager (I guess this will be
> drobbins, but it would be nice for everybody, including non-developers, ie
> hardcore Gentoo testers to know who's neck is on the block ;).

> 7) Perhaps we even should have a release team that acted as drobbins'
> elven helpers and make certain that all the items on the task-list are
> addressed in a timely fashion. Perhaps all the developers should just act
> as elven helpers.. 

Who is in charge of evangelism and propoganda right now?

> 
> Hope this sets thoughts churning. If we want 1.0 to be stable and good, we
> will have to put a lot of effort into it, and do so in a structured
> fashion. The all-nighter "throw code at it until it works" is NOT an
> option. 
>

It's not?  awwwwwwwww.  ;P

Re: [gentoo-dev] What should be in place before 1.0 release

[Karl Trygve Kalleberg]

On Sun, 14 Oct 2001 16:37:23 -0400
Blue Lizard <webmaster@dofty.zzn.com> wrote:

> bugzilla _could_ handle this, but while it is technically ready enough 
> our development team is in no way prepared to handle the influx of new 
> users that would find it a pain in the neck to use.

Then we find something that's easier to use. We really want this to
further Gentoo development, not hamper it. I do not think our current
system with sporadic mails to the gentoo-dev (and sometimes
gentoo-ebuild!) list is good enough. 

> A good way for ebuild to handle apps that dont flag/opt well would be 
> nice, other than hard coding everything :)  Like if a build is known to 
> spark out when a given portion is compiled -O3, knock it down to -O2 
> (IOW ebuild parses out flags in make.conf and handles wisely, according 
> to the writers instructions.)

We already do this some places, but it is tricky and highly error-prone
since it sometimes requires large amounts of bash wizardry. (Look for -Ox
where x > 2, then bump down to two. If x is s, then remove -Ox altogether,
etc).

Then again, the bash wizardry is what we're (not) paid to do. It's just
that I abhor having to maintain tricky code. The tricky part should be
getting the code to be easy to write an maintain, not making tricky code
out of relatively simple problems. </rant>

> > 4) In a related note, we should have a
> > "grace-period"/"codeslush"/"codefreeze" of at least one week where we
do
> > not add new stuff, and do nothing but bug-squashing. We should verify
that
> > *all* ebuilds have been tested, preferrably with *all* their optional
USE
> > arguments.
> 
> You are out of your mind.  One week?  DUDE!  This is a 1.0 release of 
> what could be a major mainstream linux distribution.  One week?

"at least" should be taken to mean "at minimum", "no less than", or
"certainly more wouldn't hurt" ;p

> Yes, and the idea is that up until the very minute that feature freeze 
> goes into effect, anything and everything goes on that list.  Someone 
> gets the slightest little notion of something that'd be cool and POOF!, 
> on the list.  Just that stuff more whimish than others would be in a 
> diff priority class for obvious reasons.

Exactly why I started the wishlist thread, and why I now intend to
maintain a wishlist on our site.

> Who is in charge of evangelism and propoganda right now?

No one in particular, but drobbins is using his connections with IBM's
DeveloperWorks for all it's worth. The rest of the developers are of
course plugging Gentoo whenever (in)appropriate.


Kind regards,

Karl T

Re: [gentoo-dev] What should be in place before 1.0 release

[Mikael Hallendal]

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

sön 2001-10-14 klockan 23.34 skrev Karl Trygve Kalleberg:
> On Sun, 14 Oct 2001 16:37:23 -0400
> Blue Lizard <webmaster@dofty.zzn.com> wrote:
> 
> > bugzilla _could_ handle this, but while it is technically ready enough 
> > our development team is in no way prepared to handle the influx of new 
> > users that would find it a pain in the neck to use.
> 
> Then we find something that's easier to use. We really want this to
> further Gentoo development, not hamper it. I do not think our current
> system with sporadic mails to the gentoo-dev (and sometimes
> gentoo-ebuild!) list is good enough. 

I don't think that anyone thinks that gnome-dev a good solution for
bugreporting. (After all it should be a developer-list for
devel-discussions).

I think that we should start using a bug-tracking system and that we
should start doing so soon. As I've said before, Bugzilla is really
powerful but can also be a large step for new users. However, this is
with the default-interface, we could do our own interface that's easier
to use.

Someone also mentioned roundup (http://roundup.sourceforge.net/). I
tried to get it running on my Gentoo-machine but it didn't want to play.
Someone (and me) should give it another try.

IMHO, we can choose either as long as it works. I also think that we
should use this system for our "todo"'s, in other words, start using the
bug-tracking system for what we currently uses Dev-wiki.

I'm not sure about Roundup but bugzilla can also be used for handling
ebuilds (instead of gentoo-ebuild-list).

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


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

Re: [gentoo-dev] What should be in place before 1.0 release

[Blue Lizard]

Mikael Hallendal wrote:
> sön 2001-10-14 klockan 23.34 skrev Karl Trygve Kalleberg:
> 
>>On Sun, 14 Oct 2001 16:37:23 -0400
>>Blue Lizard <webmaster@dofty.zzn.com> wrote:
>>
>>
>>>bugzilla _could_ handle this, but while it is technically ready enough 
>>>our development team is in no way prepared to handle the influx of new 
>>>users that would find it a pain in the neck to use.
>>>
>>Then we find something that's easier to use. We really want this to
>>further Gentoo development, not hamper it. I do not think our current
>>system with sporadic mails to the gentoo-dev (and sometimes
>>gentoo-ebuild!) list is good enough. 
>>
> 
> I don't think that anyone thinks that gnome-dev a good solution for
> bugreporting. (After all it should be a developer-list for
> devel-discussions).
> 
> I think that we should start using a bug-tracking system and that we
> should start doing so soon. As I've said before, Bugzilla is really
> powerful but can also be a large step for new users. However, this is
> with the default-interface, we could do our own interface that's easier
> to use.
> 
> Someone also mentioned roundup (http://roundup.sourceforge.net/). I
> tried to get it running on my Gentoo-machine but it didn't want to play.
> Someone (and me) should give it another try.
> 
> IMHO, we can choose either as long as it works. I also think that we
> should use this system for our "todo"'s, in other words, start using the
> bug-tracking system for what we currently uses Dev-wiki.
> 
> I'm not sure about Roundup but bugzilla can also be used for handling
> ebuilds (instead of gentoo-ebuild-list).
> 
> Regards,
>   Mikael Hallendal
> 
> 


Well, if you are making a new interface to bugzilla (or whatever backend 
is chosen), which seems preferable, then it is not a big deal to have 
separate interfaces (like different forms on a website) for a BR, UC, or 
FER.  Bug report, usability correction, and feature enhancement request 
respectively.  That way if someone not very intigrated with development 
or clueless about code thinks 'it would be cool if you could...' he need 
say little more.  And it would be easier for triage, version control, 
that kind of thing.  That is, easier from the POV of the person writing 
the report/request and easier for the developer(s) it concerns.  So yes, 
I agree that writing a gentoo interface is a good idea.  Roundup is 
pretty, but I fear that it might not suit our purposes very well. 
Still, learn from it.  While implementing our own interfaces (kinda like 
real time triage), take from it that ease of gathering together all your 
active 'stuff' together.  Page for users to look at bugs they've filed 
and their status, activity, etc. (think MyPage on ubid).  Page for 
developers to see bugs assigned to them, if they are qa contact, if a 
bug has patch up for review and it falls in their 'sector' 
(component/area), new bugs that would be of interest (falls in area of 
specialty, contact, someone cc'ed them, etc.).  Note that unlike 
mozilla's implementation, it is more contained in one system unit 
thingy.  Like instead of being based on emails and cc's and chechking 
boxes or filling in...this is all totally together in my head but to put 
into words or code seems impossible.  Think like the way it sorta 
(great, now the idea is evolving too far beyond the example) ... ya 
know.  Like the way MandrakeExpert sorta kinda doesn't really work. 
Replace the expert select check boxes with a pulldown menu that updates 
with the selection of component and other aspect triaging attributes 
that minimize the required user knowledge background.  This is so 
incoherent I'm just gonna stop.  Look at this, not a single line break. 
  It's how I think, must be why I'm always so confused ;P

5:34 AM?  When did that happen?  It's 2 isnt it?  huh?
-Blue (yeah, I might be the reason this ml turns moderated :p)

Re: [gentoo-dev] What should be in place before 1.0 release

[Mikael Hallendal]

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

mån 2001-10-15 klockan 11.35 skrev Blue Lizard:
 
> Well, if you are making a new interface to bugzilla (or whatever backend 
> is chosen), which seems preferable, then it is not a big deal to have 
> separate interfaces (like different forms on a website) for a BR, UC, or 
> FER.  Bug report, usability correction, and feature enhancement request 
> respectively.  That way if someone not very intigrated with development 
> or clueless about code thinks 'it would be cool if you could...' he need 
> say little more.  And it would be easier for triage, version control, 
> that kind of thing.  That is, easier from the POV of the person writing 
> the report/request and easier for the developer(s) it concerns.  So yes, 
> I agree that writing a gentoo interface is a good idea.  Roundup is 
> pretty, but I fear that it might not suit our purposes very well. 
> Still, learn from it.  While implementing our own interfaces (kinda like 
> real time triage), take from it that ease of gathering together all your 
> active 'stuff' together.  Page for users to look at bugs they've filed 
> and their status, activity, etc. (think MyPage on ubid).  Page for 
> developers to see bugs assigned to them, if they are qa contact, if a 
> bug has patch up for review and it falls in their 'sector' 
> (component/area), new bugs that would be of interest (falls in area of 
> specialty, contact, someone cc'ed them, etc.).  Note that unlike 
> mozilla's implementation, it is more contained in one system unit 
> thingy.  Like instead of being based on emails and cc's and chechking 
> boxes or filling in...this is all totally together in my head but to put 
> into words or code seems impossible.  Think like the way it sorta 
> (great, now the idea is evolving too far beyond the example) ... ya 
> know.  Like the way MandrakeExpert sorta kinda doesn't really work. 
> Replace the expert select check boxes with a pulldown menu that updates 
> with the selection of component and other aspect triaging attributes 
> that minimize the required user knowledge background.  This is so 
> incoherent I'm just gonna stop.  Look at this, not a single line break. 
>   It's how I think, must be why I'm always so confused ;P

Yes, but next time, PLEASE use linebreaks and it will be easier to read
the mail.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


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