[gentoo-releng] 2004.2 planning

[gentoo-releng] 2004.2 planning

[John Davis]

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

Hi all,
Its that time again :) While you are relaxing and hopefully sitting by
the sun, I have been working on 2004.2 (and relaxing as well ;)

Before I get to 2004.2, we need a 2004.1 recap. 2004.1 did amazingly
well. In my time at Gentoo, I have never seen a release go so well. What
we did for 2004.1 was truly amazing work - each of you should be proud
as hell about what we got accomplished in that short amount of time.
Everyone involved did a hell of a job, thank you :)

Of course though, there are always things to improve. Here is what I see
as areas that we could improve in:

1. More QA on everything, especially LiveCDs
2. Hardware detection and module autoloading for x86
3. Genkernel and initrds for other arches
4. Better communication about what arches are releasing
5. Deadline completion

Okay, so here is the breakdown:

 To address #1 I have built a month+ of QA time into 2004.2 (please see
the link at the bottom for the link to the preliminary 2004.2 page). A
month of QA should allow us plenty of time to test everything that we
have and fix whatever problems come up. Additionally, this extended QA
period helps to fix #5, the more time we have on QA, the more likely we
are to hit deadline because we won't have to hack in any last minute
changes. Now, because of this month+ of QA, when the deadline rolls
around, I am going to strictly adhere to it, so just keep that in mind.

#2 is something that we are working on presently (we being beejay,
roger55, and myself). This will probably go on the feature request list
and get itself resolved rather quickly.

#3 is all plasmaroo and the genkernel team. Please contact him ASAP with
your bugs - he is lightning quick about patches to fix problems :)

#4 is something pretty easy to address - please keep me up-to-date as to
whether or not your arch can make it. This is not really a biggie, but
it helps with planning.

#5 will be fixed with #1, QA helps a lot of things :)

The two areas of improvement that I expect will take the most time are
#2 and #5. The extended QA period should help us here though.

Okay, the schedule for 2004.2 is much more lax than 2004.1. Please take
the time to look over the 2004.2 info sheet linked from the bottom of
this mail and provide me with some feedback with regard to the schedule.
Again, I want to make this release as low stress as possible, so let me
know if I can adjust the schedule in any way to help complete this goal
:)

Ok, the last thing in this long e-mail (I swear :) is the feature
request. Please see the mail that I am going to send to -core and -dev.
Basically, I am going to field some feature requests and then hold a
meeting with all of you on releng to see what requested features are
feasible. I will keep you posted.

Again, awesome job on 2004.1! Let's do the same and even more with
2004.2.

Cheers,
//zhen

Link to the 2004.2 page:
http://nue.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml

-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Sven Vermeulen]

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

On Thu, Apr 29, 2004 at 11:38:44PM -0400, John Davis wrote:
> Link to the 2004.2 page:
> http://nue.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml

Hi John and releng-colleagues,

To make sure that no draft or unfinished documents are put on a LiveCD I'm
only going to release a tarball once the documentation is finished (which
means when the boot information and filelistings are received and
processed). 

On http://dev.gentoo.org/~swift/releng.html you'll find a table in which I
put the information and download links once they are available.

John: can you please update the link in your 2004.2 document to point to the
above URL? 

TIA,
    Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Fri, 2004-04-30 at 03:02, Sven Vermeulen wrote:
> On Thu, Apr 29, 2004 at 11:38:44PM -0400, John Davis wrote:
> > Link to the 2004.2 page:
> > http://nue.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml
> 
> Hi John and releng-colleagues,
> 
> To make sure that no draft or unfinished documents are put on a LiveCD I'm
> only going to release a tarball once the documentation is finished (which
> means when the boot information and filelistings are received and
> processed). 
> 
> On http://dev.gentoo.org/~swift/releng.html you'll find a table in which I
> put the information and download links once they are available.
> 
> John: can you please update the link in your 2004.2 document to point to the
> above URL? 
> 
> TIA,
>     Sven Vermeulen

Changed, thanks Swift!
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Pieter Van den Abeele]

A few words of caution for 2004.2:

EXAMS EXAMS EXAMS

On 30 Apr 2004, at 05:38, John Davis wrote:

> 2004.1 did amazingly well.

We didn't implement a single feature request, so it should be taken 
with a grain of salt.

> In my time at Gentoo, I have never seen a release go so well. What
> we did for 2004.1 was truly amazing work - each of you should be proud
> as hell about what we got accomplished in that short amount of time.

I would like to see that reflected a bit more in the press release for 
upcoming 2004.2. Nobody reads those boring release notes right now, 
they are hidden somewhere on the releng page and not linked from the 
press release.
I'm not very inclined to keep writing them if livecds on the mirrors 
are not updateded (a simple typo in the bootloader config) when I have 
bugfixed (corrected typo) ones available.

Another example: nobody knows there are optimized G5 32bit stages, that 
we've released a first experimental ppc64 livecd... If we don't say 
we're the first, then another distro will.

> Okay, so here is the breakdown:
>
> To address #1 I have built a month+ of QA time into 2004.2 (please see
> the link at the bottom for the link to the preliminary 2004.2 page).

I need two weeks (8 days building, 2 days uploading) for building and 
releasing the ppc preliminary release (assuming no bugs occur). All 
features need to be completed by the 14th, and I'll take a snapshot 
from the building tool on the 14th, that leaves 4 days to actually 
implement and QA any new feature requests, because we're only deciding 
upon new feature requests on may 10th.

Please also note that I have some developers in training that are 
crucial for 2004.2. These people will most likely become dev when the 
release has been build.

> #3 is all plasmaroo and the genkernel team. Please contact him ASAP 
> with
> your bugs - he is lightning quick about patches to fix problems :)

genkernel is a bottleneck, because a new release is needed for each 
kernel we make a livecd .config for. And ppc has a lot of kernels to 
support (3x POWER, G3,G4,G5, pegasos, amiga, chrp, prep, oldworld) = 
32bit + 64bit = G5, POWER

I'd prefer to have kernel-sources with livecd config as default or 
something like that (see arch/ppc/configs/* in your kernel sources)

For pegasos we need to be able to produce a <kernel,initrd> all-in-one 
file. dholm has patches

We are intending to migrate our kernel stuff to kernel-2.eclass, johnm 
got the roadmap. The developer who is going to do that is currently in 
training, and will therefore not be able to do so before the release is 
build.

> Okay, the schedule for 2004.2 is much more lax than 2004.1. Please take
> the time to look over the 2004.2 info sheet linked from the bottom of
> this mail and provide me with some feedback with regard to the 
> schedule.
> Again, I want to make this release as low stress as possible, so let me
> know if I can adjust the schedule in any way to help complete this goal
> :)

see above

Isn't it possible to just update the stages and GRP? I see no reason to 
make 4 full releases a year. (Actually I do see some, but not really 
flattering ones).

> Ok, the last thing in this long e-mail (I swear :) is the feature
> request. Please see the mail that I am going to send to -core and -dev.
> Basically, I am going to field some feature requests and then hold a
> meeting with all of you on releng to see what requested features are
> feasible. I will keep you posted.

Preferably as few as possible. >EXAMS<

> Again, awesome job on 2004.1! Let's do the same and even more with
> 2004.2.
>
> Cheers,
> //zhen
>
> Link to the 2004.2 page:
> http://nue.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml
>
> -- 
> John Davis
> Gentoo Linux Developer
> <http://dev.gentoo.org/~zhen>
>
> ----
> GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
> Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Fri, 2004-04-30 at 12:31, Pieter Van den Abeele wrote:
> A few words of caution for 2004.2:
> 
> EXAMS EXAMS EXAMS
> 
> On 30 Apr 2004, at 05:38, John Davis wrote:
> 
> > 2004.1 did amazingly well.
> 
> We didn't implement a single feature request, so it should be taken 
> with a grain of salt.

I respectfully disagree, quite strongly actually. Although we did not
complete any of the feature request, which will be something that we
have to work on for 2004.2 (that is why I started the process so early),
we did get the release out on time and complete. Every release up to
2004.1 was late and broken; 1.4 was almost vaporware and 2004.0 was
late. We accomplished something that has never been done with Gentoo
before, and I see that as something to be proud of (not to say that we
have an enormous amount of room to improve).

> 
> > In my time at Gentoo, I have never seen a release go so well. What
> > we did for 2004.1 was truly amazing work - each of you should be proud
> > as hell about what we got accomplished in that short amount of time.
> 
> I would like to see that reflected a bit more in the press release for 
> upcoming 2004.2. Nobody reads those boring release notes right now, 
> they are hidden somewhere on the releng page and not linked from the 
> press release.
> I'm not very inclined to keep writing them if livecds on the mirrors 
> are not updateded (a simple typo in the bootloader config) when I have 
> bugfixed (corrected typo) ones available.

Very good point. I dropped the ball with the press release and the
release notes, be assured that they will be part of a more concise and
information filled press release for .2.
> 
> Another example: nobody knows there are optimized G5 32bit stages, that 
> we've released a first experimental ppc64 livecd... If we don't say 
> we're the first, then another distro will.

By all means, please post a news item on the g.o front page. Again, I
did not include them in the press release because I dropped the ball,
but you do not need releng's blessing to advertise your experimental
work. In fact, write up a news blurb for the front page and I will get
it published ASAP.

> 
> > Okay, so here is the breakdown:
> >
> > To address #1 I have built a month+ of QA time into 2004.2 (please see
> > the link at the bottom for the link to the preliminary 2004.2 page).
> 
> I need two weeks (8 days building, 2 days uploading) for building and 
> releasing the ppc preliminary release (assuming no bugs occur). All 
> features need to be completed by the 14th, and I'll take a snapshot 
> from the building tool on the 14th, that leaves 4 days to actually 
> implement and QA any new feature requests, because we're only deciding 
> upon new feature requests on may 10th.

Let's ditch the preliminary release requirement then. I would much
rather have QA and testing over a prelim release. Will this work?

> 
> Please also note that I have some developers in training that are 
> crucial for 2004.2. These people will most likely become dev when the 
> release has been build.
> 
> > #3 is all plasmaroo and the genkernel team. Please contact him ASAP 
> > with
> > your bugs - he is lightning quick about patches to fix problems :)
> 
> genkernel is a bottleneck, because a new release is needed for each 
> kernel we make a livecd .config for. And ppc has a lot of kernels to 
> support (3x POWER, G3,G4,G5, pegasos, amiga, chrp, prep, oldworld) = 
> 32bit + 64bit = G5, POWER
> 
> I'd prefer to have kernel-sources with livecd config as default or 
> something like that (see arch/ppc/configs/* in your kernel sources)
> 
> For pegasos we need to be able to produce a <kernel,initrd> all-in-one 
> file. dholm has patches
> 
> We are intending to migrate our kernel stuff to kernel-2.eclass, johnm 
> got the roadmap. The developer who is going to do that is currently in 
> training, and will therefore not be able to do so before the release is 
> build.

You need to open a dialog with plasmaroo on this one. Genkernel,
although used by releng, is not maintained by releng. Perhaps at some
point it can be in the future, but at this point in time, it is up to
you to get on plasmaroo to fix the problems.

> 
> > Okay, the schedule for 2004.2 is much more lax than 2004.1. Please take
> > the time to look over the 2004.2 info sheet linked from the bottom of
> > this mail and provide me with some feedback with regard to the 
> > schedule.
> > Again, I want to make this release as low stress as possible, so let me
> > know if I can adjust the schedule in any way to help complete this goal
> > :)
> 
> see above
> 
> Isn't it possible to just update the stages and GRP? I see no reason to 
> make 4 full releases a year. (Actually I do see some, but not really 
> flattering ones).

Quarterly releases aren't even a year old yet and are in the process of
being refined. Until they are, please bear with some of the issues that
come up. I very much so prefer quarterly releases because they keep QA
constantly going for the distro as a whole, and QA is something that we
have historically had problems with. I don't even want to think about
changing the quarterly schedule until we get another year under our belt
- we need to give it time to mature.
> 
> > Ok, the last thing in this long e-mail (I swear :) is the feature
> > request. Please see the mail that I am going to send to -core and -dev.
> > Basically, I am going to field some feature requests and then hold a
> > meeting with all of you on releng to see what requested features are
> > feasible. I will keep you posted.
> 
> Preferably as few as possible. >EXAMS<

In July, yeesh ...


Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Pieter Van den Abeele]

On 30 Apr 2004, at 21:39, John Davis wrote:

> Every release up to 2004.1 was late and broken; 1.4 was almost 
> vaporware and 2004.0 was
> late.

I would like to point out that ppc did more than 10 different _rc 
releases for the 1.4 cds, while waiting for x86 to be completed :-)

1.4 went broken when apple published broken firmware, incompatible with 
the kernel
2004.0 was broken because upstream ppc kernels were broken. (2.6.5 
finally fixed it).

> We accomplished something that has never been done with Gentoo
> before, and I see that as something to be proud of (not to say that we
> have an enormous amount of room to improve).

true

> Let's ditch the preliminary release requirement then. I would much
> rather have QA and testing over a prelim release. Will this work?

sure

> You need to open a dialog with plasmaroo on this one. Genkernel,
> although used by releng, is not maintained by releng. Perhaps at some
> point it can be in the future, but at this point in time, it is up to
> you to get on plasmaroo to fix the problems.

Genkernel works ok for catalyst. But the initrd complicates things for 
users just trying to build a working kernel for a new install.

>> Preferably as few as possible. >EXAMS<
>
> In July, yeesh ...

june and aug for me.

Pieter


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Nathaniel McCallum]

On Fri, 2004-04-30 at 22:05 +0200, Pieter Van den Abeele wrote:
> Genkernel works ok for catalyst. But the initrd complicates things for 
> users just trying to build a working kernel for a new install.

Warpzero and I have been discussing a GLEP to integrate kernel building
support into portage instead of gentoo.  Please don't flame me yet, I've
been trying to get a hold of pfeifer and plasmaroo to discuss it with
them (if you guys read this, let me know).  Nothing is formal yet, I'm
just working on the details and when something is more formal, we'll
post it.  (BTW, integrating kernel building into portage is a HUGE asset
to the GentooInstaller team).

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Kumba]

Nathaniel McCallum wrote:

> Warpzero and I have been discussing a GLEP to integrate kernel building
> support into portage instead of gentoo.  Please don't flame me yet, I've
> been trying to get a hold of pfeifer and plasmaroo to discuss it with
> them (if you guys read this, let me know).  Nothing is formal yet, I'm
> just working on the details and when something is more formal, we'll
> post it.  (BTW, integrating kernel building into portage is a HUGE asset
> to the GentooInstaller team).
> 
> Nathaniel

This sounds interesting.  I'm making a guess here, but would this entail 
doing something like extending one of the existing kernel.eclasses to 
incorporate appropriate kernel building/installing functions?  Users can 
store kernel configs in some dir in /etc, which get used by the eclass?


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Nathaniel McCallum]

On Sat, 2004-05-01 at 00:31 -0400, Kumba wrote:
> Nathaniel McCallum wrote:
> 
> > Warpzero and I have been discussing a GLEP to integrate kernel building
> > support into portage instead of gentoo.  Please don't flame me yet, I've
> > been trying to get a hold of pfeifer and plasmaroo to discuss it with
> > them (if you guys read this, let me know).  Nothing is formal yet, I'm
> > just working on the details and when something is more formal, we'll
> > post it.  (BTW, integrating kernel building into portage is a HUGE asset
> > to the GentooInstaller team).
> > 
> > Nathaniel
> 
> This sounds interesting.  I'm making a guess here, but would this entail 
> doing something like extending one of the existing kernel.eclasses to 
> incorporate appropriate kernel building/installing functions?  Users can 
> store kernel configs in some dir in /etc, which get used by the eclass?

Very roughly, yes.  There are a whole slew of other things though.  ie.
how to treat kernel sources after merge.  How to support automated
initrd building/bootsplash support, etc.  default kernel configs.
assisted config making. non-kernel modules. among other things.

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Bob Johnson]

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

On Friday 30 April 2004 02:39 pm, John Davis wrote:
>
> I respectfully disagree, quite strongly actually. Although we did not
> complete any of the feature request, which will be something that we
> have to work on for 2004.2 (that is why I started the process so early),
> we did get the release out on time and complete. Every release up to
> 2004.1 was late and broken; 1.4 was almost vaporware and 2004.0 was
> late. We accomplished something that has never been done with Gentoo
> before, and I see that as something to be proud of (not to say that we
> have an enormous amount of room to improve).
>


Zhen i have much respect for the work your doing on livecds now, but are you
really so blind to the quality?

Ive also seen notes that second kernel will be removed from future releases 
(if we cant fix it remove it) , also framebuffer/bootsplash will be removed.. 
(same thing , cant fix it remove it).   If all of Gentoo did this, in  a few 
years portage would be 2 ebuilds and a few scripts..

The process needs to slow down a bit. 

And btw this is not just personal feelings, ive had almost all ppl touching 
x86 livecds ask for help.
					Bob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAksAAxJgsCy9JAX0RAuj/AJ9xsXAlPd5YxjSANqUBJN3YbcemgACdGPhg
vHwXMYzuWhK4M9buW+GrXG4=
=exn/
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Fri, 2004-04-30 at 17:07, Bob Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 30 April 2004 02:39 pm, John Davis wrote:
> >
> > I respectfully disagree, quite strongly actually. Although we did not
> > complete any of the feature request, which will be something that we
> > have to work on for 2004.2 (that is why I started the process so early),
> > we did get the release out on time and complete. Every release up to
> > 2004.1 was late and broken; 1.4 was almost vaporware and 2004.0 was
> > late. We accomplished something that has never been done with Gentoo
> > before, and I see that as something to be proud of (not to say that we
> > have an enormous amount of room to improve).
> >
> 
> 
> Zhen i have much respect for the work your doing on livecds now, but are you
> really so blind to the quality?
> 
> Ive also seen notes that second kernel will be removed from future releases 
> (if we cant fix it remove it) , also framebuffer/bootsplash will be removed.. 
> (same thing , cant fix it remove it).   If all of Gentoo did this, in  a few 
> years portage would be 2 ebuilds and a few scripts..
> 
> The process needs to slow down a bit. 
> 
> And btw this is not just personal feelings, ive had almost all ppl touching 
> x86 livecds ask for help.
> 					Bob

Bob -
No, I am not blind to the *numerous* QA problems. I did say that we have
an enormous amount of room to improve, and I really do mean it; I don't
see how that is being blind. We accomplished one of our goals, to get a
release out on time and intact. Now, we work on QA and fix all of the
problems. Its a step by step process, we can't expect to have it all at
once. We have basically gone from nothing to a little bit of something,
now we are moving towards the full something - each part takes time.

I can honestly say to you that there have never been, and never will be,
plans to remove a feature just because we cannot get it to work. Not
only is that bad practice, but it shows that we are not competent in our
jobs. As long as two kernels are viable, we will use them. As long as we
have bootsplash we will use it. If you know where these notes are,
please tell me as they are completely wrong and need to be removed. 

If we do decide to move to 2.6 only it is because better hardware
support. I really don't see the need to keep 2.4 around if 2.6 is 100%
compatible with all scenarios. Even if we do go the 2.6 route, the
multiple kernel bug will be fixed as many more people than releng use
Catalyst to do many more things. Bootsplash though will always remain
(for supported arches) - there is no reason to get rid of it.

I hope this clears up some issues -

Cheers,
//zhen



-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Pieter Van den Abeele]

On 30 Apr 2004, at 23:39, John Davis wrote:

> Not only is that bad practice, but it shows that we are not competent 
> in our
> jobs.

I wouldn't generalize too much. :-)

Best regards,

Pieter Van den Abeele


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Kurt Lieber]

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

On Fri, Apr 30, 2004 at 05:39:41PM -0400 or thereabouts, John Davis wrote:
> > Zhen i have much respect for the work your doing on livecds now, but are you
> > really so blind to the quality?
> > 
> > Ive also seen notes that second kernel will be removed from future releases 
> > (if we cant fix it remove it) , also framebuffer/bootsplash will be removed.. 
> > (same thing , cant fix it remove it).   If all of Gentoo did this, in  a few 
> > years portage would be 2 ebuilds and a few scripts..
> > 
> > The process needs to slow down a bit. 
> > 
> > And btw this is not just personal feelings, ive had almost all ppl touching 
> > x86 livecds ask for help.
> > 					Bob
> 
> Bob -
> No, I am not blind to the *numerous* QA problems. I did say that we have
> an enormous amount of room to improve, and I really do mean it; I don't
> see how that is being blind. We accomplished one of our goals, to get a
> release out on time and intact. Now, we work on QA and fix all of the
> problems. Its a step by step process, we can't expect to have it all at
> once. We have basically gone from nothing to a little bit of something,
> now we are moving towards the full something - each part takes time.

I didn't see Bob's original message, but he, Pieter and now myself are
going to be saying exactly the same thing.

Quarterly releases are too ambitious.  We need to slow down.

Right now, we're so focused on quarterly releases that we cannot take
enough time to develop features that may take longer than three months to
code, test and get ready to go.

As Pieter pointed out earlier, if we want to release something in July and
do proper QA on it ahead of time, we don't really have much time to do any
actual *development*.  Who cares if we're releasing 4 new versions a year
if they're all identical save for minor cosmetic/typo stuff?  

Quarterly releases need to stop.

--kurt

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

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Fri, 2004-04-30 at 18:59, Kurt Lieber wrote:

> I didn't see Bob's original message, but he, Pieter and now myself are
> going to be saying exactly the same thing.
> 
> Quarterly releases are too ambitious.  We need to slow down.
> 
> Right now, we're so focused on quarterly releases that we cannot take
> enough time to develop features that may take longer than three months to
> code, test and get ready to go.
> 
> As Pieter pointed out earlier, if we want to release something in July and
> do proper QA on it ahead of time, we don't really have much time to do any
> actual *development*.  Who cares if we're releasing 4 new versions a year
> if they're all identical save for minor cosmetic/typo stuff?  
> 
> Quarterly releases need to stop.
> 
> --kurt

Kurt -
I've been thinking this over for quite awhile now and have vacilated
between continuing quarterly releases and moving to something else.
After much thought (and believe me, there has been a lot - during 2004.0
I wanted nothing to do with quarterly releases), I have decided that for
the immediate future, quarterly releases are the way to go for the
following reasons:

Gentoo users need and want quarterly releases. If there is a larger time
gap between releases, they are stuck waiting for updated stages, GRP,
etc. This leaves them with a longer install (more packages to update
because the release media is dated) and pretty much negates the effect
of GRP (who wants to use GRP if the versions are old).

Quarterly releases force good QA througout Gentoo. Building release GRP
every 3 months or so allows the more critical (kde, gnome, assorted core
utils, etc) to field more bugs and fix them. If something doesn't work
for releng, we report it to them and the problem is fixed. I cannot tell
you how many bugs we have fixed in packages like baselayout because our
release cycle is so testing intensive. The current release cycle scheme
is beneficial not just for releng, it helps Gentoo as a whole.

I think where we are getting caught up on quarterly releases is the
distinction between what kind of features go where. Releng cannot
support any feature request which does not directly affect our release
media. Portage feature requests do not belong on the releng feature
request list because we have no control over them. Does infra take
feature requests from hardened? Its a similar situation.

The release cycle timeframe is fine, but it may not seem that way
because a lot of features that do not belong in releng get lumped into
it. What Gentoo really needs is two feature request lists - one for
Gentoo as a whole, perhaps using the release cycle as a guideline
(implement GPG signing by 2005.1), but not putting other subproject's
duties onto releng, and one for releng (which would deal with release
specific features, such as adding in a log for dmesg or better labeling
our LiveCDs). If we have this distinction I believe that a lot of these
concerns will go away.

Cheers,
//zhen
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 2364 71BD 4BC2 705D F338  FF70 6650 1235 1946 2D47


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sat, 2004-05-01 at 20:14, Kurt Lieber wrote:
> On Sat, May 01, 2004 at 11:17:24AM -0400 or thereabouts, John Davis wrote:
> > Kurt -
> > I've been thinking this over for quite awhile now and have vacilated
> > between continuing quarterly releases and moving to something else.
> > After much thought (and believe me, there has been a lot - during 2004.0
> > I wanted nothing to do with quarterly releases), I have decided that for
> > the immediate future, quarterly releases are the way to go for the
> > following reasons:
> 
> I don't agree.  We should put this on the next manager's meeting as an
> agenda item.  As it stands, I'm not willing to support quarterly releases
> from an infra standpoint.  If the rest of the management team decides we
> should, then I will do my best.  As it stands, I think this is a huge waste
> of time, resources and development effort.
> 
> As a general rule, I think basing releases on time, rather than features,
> is a poor way of defining release goals.  I think gathering feature
> requests (as you have been doing so far) is a great idea.  I think we
> should then (as a management team) decide what features need to make it
> into the next release of Gentoo, decide how much time that will take to
> implement and then set a target release date based on that.  We should
> release based on features, not on time.
> 
> --kurt

Kurt -
I respect your opinion, but I do believe that you are rushing into a
decision that has no factual basis. Quarterly releases have not even
been going for a year and because of this there is not substantial
evidence against them. The fact is that quarterly releases benefit the
user as they are kept up to date every quarter.

Gentoo cannot go back to the old style (pre-2004.0) style of releases.
The nature of our distribution does not allow us to do this. I guarantee
you that if we do go back to the old style releases that we will be in
the same boat as we were with 1.4 - feature creep and constantly late
deadlines. Not only does this make Gentoo look bad as a distribution,
but it leaves our users out in the cold as GRP, a feature that users
very much enjoy, becomes useless due to its age.

The goal of quarterly releases is *not* meeting a deadline, but rather
providing our users with up-to-date release media for their convienence.
I do not understand why you are rushing into your decision that 
"quarterly releases [cannot be supported] from an infra standpoint" -
2004.1 went great from the infra side. There were no problems, and
2004.2 is going to be even better now that we know exactly what to do
with the bit flip method. Even without you there to look over things,
the release went out without a hitch.

Bring it up with the rest of the managers if you want to Kurt, but I
assure you that it is the wrong decision to do so. Quarterly releases
work for us devs, for the users, and for Gentoo. If you really are set
on doing releases 1.4 style where features like GPG signing hold the
release back forever, fine, but you are not doing what is right for our
users.

Please think about what I said earlier about the dual feature lists -
one for releng release specific features, and one for broader gentoo
specific features. Things like UTF8 integration and GPG signing have are
not something that releng can directly control, therefore, the
responsibility should not weigh on releng's shoulders to complete them,
but rather their own respective sub-projects.

Regards,
//John 
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Jason Wever]

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

On Wed, 05 May 2004 02:29:35 -0400
John Davis <zhen@gentoo.org> wrote:

> I respect your opinion, but I do believe that you are rushing into a
> decision that has no factual basis. Quarterly releases have not even
> been going for a year and because of this there is not substantial
> evidence against them. The fact is that quarterly releases benefit the
> user as they are kept up to date every quarter.

If this isn't the point Kurt was trying to make, then consider it mine. :)

Historically, (not necessarily Gentoo) projects that have had a time based
deadline over a "when it's done" type deadline end up suffering in
features and overall quality to meet those deadlines.

2004.0 and 2004.1 do show signs of this.  If we are to continue to do time
based releases, it is imperative that *all* of the needed adjustments to
the tools and ebuilds be made *before* we even begin into the release
cycle (minus the obvious security update exceptions).  Having these things
change while builds happen is not good for QA and for meeting deadlines.

-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sat, 2004-05-01 at 22:46, Jason Wever wrote:
> If this isn't the point Kurt was trying to make, then consider it mine. :)
> 
> Historically, (not necessarily Gentoo) projects that have had a time based
> deadline over a "when it's done" type deadline end up suffering in
> features and overall quality to meet those deadlines.
> 
> 2004.0 and 2004.1 do show signs of this.  If we are to continue to do time
> based releases, it is imperative that *all* of the needed adjustments to
> the tools and ebuilds be made *before* we even begin into the release
> cycle (minus the obvious security update exceptions).  Having these things
> change while builds happen is not good for QA and for meeting deadlines.

Yes, I agree with you here.
As Catalyst and baselayout (thanks to agriffis) begin to stabilize this
problem should begin to dissipate some. I am sorry that this has not
happened in the past as I have mostly been the one to cause change with
Catalyst, but with some more input, this will change in the future.

Regards,
//John
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Jeffrey Forman]

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

I think I am the one responding here with the least amount of
professional release engineering experience and in speaking to John and
reading over these threads some ideas came into my mind.

(1) Stick with the quarterly-release schedule until at least 2004.3 (the
last one of 2004). After that point, or a good time period before,
decide what we're going to do for >= 2005.
(2) If we stick with quarterly releases, change the viewpoint that even
releases (.0, .2) are NEW FEATURE releases. There needs to be some
compelling reason to release here. Maybe a db-backend portage (just an
idea) or some new from-the-ground-up feature. The odd (.1,.3) releases
incorporate bug fixes, typos, and other non-new-feature inclusions. In
my mind, this doesnt force devs/releng/infra to create totally new ideas
for every release. Come up with something original before the even
release, and refine it in the following odd quarter.

If we decide as 2005 nears to scrap the quarterly release system, maybe
go with tri-yearly or biannual releases. It just gives more time to the
release to come up with new ideas and new inclusions.

Ridicule, deride, praise,
-Jeff

On Wed, 2004-05-05 at 01:29, John Davis wrote:
> On Sat, 2004-05-01 at 20:14, Kurt Lieber wrote:
> > On Sat, May 01, 2004 at 11:17:24AM -0400 or thereabouts, John Davis wrote:
> > > Kurt -
> > > I've been thinking this over for quite awhile now and have vacilated
> > > between continuing quarterly releases and moving to something else.
> > > After much thought (and believe me, there has been a lot - during 2004.0
> > > I wanted nothing to do with quarterly releases), I have decided that for
> > > the immediate future, quarterly releases are the way to go for the
> > > following reasons:
> > 
> > I don't agree.  We should put this on the next manager's meeting as an
> > agenda item.  As it stands, I'm not willing to support quarterly releases
> > from an infra standpoint.  If the rest of the management team decides we
> > should, then I will do my best.  As it stands, I think this is a huge waste
> > of time, resources and development effort.
> > 
> > As a general rule, I think basing releases on time, rather than features,
> > is a poor way of defining release goals.  I think gathering feature
> > requests (as you have been doing so far) is a great idea.  I think we
> > should then (as a management team) decide what features need to make it
> > into the next release of Gentoo, decide how much time that will take to
> > implement and then set a target release date based on that.  We should
> > release based on features, not on time.
> > 
> > --kurt
> 
> Kurt -
> I respect your opinion, but I do believe that you are rushing into a
> decision that has no factual basis. Quarterly releases have not even
> been going for a year and because of this there is not substantial
> evidence against them. The fact is that quarterly releases benefit the
> user as they are kept up to date every quarter.
> 
> Gentoo cannot go back to the old style (pre-2004.0) style of releases.
> The nature of our distribution does not allow us to do this. I guarantee
> you that if we do go back to the old style releases that we will be in
> the same boat as we were with 1.4 - feature creep and constantly late
> deadlines. Not only does this make Gentoo look bad as a distribution,
> but it leaves our users out in the cold as GRP, a feature that users
> very much enjoy, becomes useless due to its age.
> 
> The goal of quarterly releases is *not* meeting a deadline, but rather
> providing our users with up-to-date release media for their convienence.
> I do not understand why you are rushing into your decision that 
> "quarterly releases [cannot be supported] from an infra standpoint" -
> 2004.1 went great from the infra side. There were no problems, and
> 2004.2 is going to be even better now that we know exactly what to do
> with the bit flip method. Even without you there to look over things,
> the release went out without a hitch.
> 
> Bring it up with the rest of the managers if you want to Kurt, but I
> assure you that it is the wrong decision to do so. Quarterly releases
> work for us devs, for the users, and for Gentoo. If you really are set
> on doing releases 1.4 style where features like GPG signing hold the
> release back forever, fine, but you are not doing what is right for our
> users.
> 
> Please think about what I said earlier about the dual feature lists -
> one for releng release specific features, and one for broader gentoo
> specific features. Things like UTF8 integration and GPG signing have are
> not something that releng can directly control, therefore, the
> responsibility should not weigh on releng's shoulders to complete them,
> but rather their own respective sub-projects.
> 
> Regards,
> //John 
-- 


--------------------
Jeffrey Forman
Gentoo Infrastructure
Gentoo Release Engin.
jforman@gentoo.org
--------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sat, 2004-05-01 at 23:08, Jeffrey Forman wrote:
> I think I am the one responding here with the least amount of
> professional release engineering experience and in speaking to John and
> reading over these threads some ideas came into my mind.
> 
> (1) Stick with the quarterly-release schedule until at least 2004.3 (the
> last one of 2004). After that point, or a good time period before,
> decide what we're going to do for >= 2005.
> (2) If we stick with quarterly releases, change the viewpoint that even
> releases (.0, .2) are NEW FEATURE releases. There needs to be some
> compelling reason to release here. Maybe a db-backend portage (just an
> idea) or some new from-the-ground-up feature. The odd (.1,.3) releases
> incorporate bug fixes, typos, and other non-new-feature inclusions. In
> my mind, this doesnt force devs/releng/infra to create totally new ideas
> for every release. Come up with something original before the even
> release, and refine it in the following odd quarter.
> 
> If we decide as 2005 nears to scrap the quarterly release system, maybe
> go with tri-yearly or biannual releases. It just gives more time to the
> release to come up with new ideas and new inclusions.
> 
> Ridicule, deride, praise,
> -Jeff

Jeff - 
The direction of your ideas is definitely a good one. I am very open to
this course of action.

Cheers,
//zhen
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Kurt Lieber]

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

On Wed, May 05, 2004 at 02:29:35AM -0400 or thereabouts, John Davis wrote:
> Kurt -
> I respect your opinion, but I do believe that you are rushing into a
> decision that has no factual basis. Quarterly releases have not even
> been going for a year and because of this there is not substantial
> evidence against them. The fact is that quarterly releases benefit the
> user as they are kept up to date every quarter.

People who use GRP are but a subset of our entire user base.  You are
defining a release criteria ideally suited to that minority group, but
ill-suited to the rest of our user base.  Let's make a quick list of pros
and cons:

Pros:
----
* Provides up-to-date GRP sets for people who install using this method
* Sells more CDs.
* uh...

Cons:
----
* Requires too much time/effort from other projects.  Arches have to take
  take snapshots and build package sets.  Documentation has to update
  install guides.  Infra has to communicate with the mirrors about the
  10+ GB of data that will be produced as a result and the list goes on.
  This would be fine if each release delivered significant value over the
  previous released version, but it doesn't.  Which leads to my next
  point... 
* Releases are largely meaningless, comprised of nothing more than package
  updates for GRP.  (What were the new and/or innovative features planned
  for 2004.1?  How many did we actually deliver on?  Where are stackable
  profiles?  Where is emerge --security support?)
* Focused entirely on the installation of Gentoo, which is but a small
  fraction of the overall Gentoo experience.  Quarterly releases do nothing
  to improve Gentoo for the tends of thousands of users who have been
  faithfully running it for months/years. 
* Takes away focus from developing longer-term, more innovative solutions
  that will better differentiate Gentoo from the rest of the pack.  Every
  hour spent towards getting another release ready to go out the door is
  one less hour that folks can spend on other projects that will have a
  more widespread benefit to the Gentoo community as a whole.

> Gentoo cannot go back to the old style (pre-2004.0) style of releases.
> The nature of our distribution does not allow us to do this. 

This is completely unsubstantiated and patently false.

> I guarantee you that if we do go back to the old style releases that we
> will be in the same boat as we were with 1.4 - feature creep and
> constantly late deadlines. 

OK, so let's take those as two separate criticisms:

* Feature creep.  Only if releng does a poor job of managing releases and
  allows this to happen.  As I said previously, I would like us to define,
  as a team, the features that we want to see in the next release of
  Gentoo.  I would then see it as releng's primary responsibility to ensure
  people stay focused on developing those features and preventing external
  features from "creeping" into the distro.
* Late deadlines.  Again, where is emerge --security and stackable profiles
  support in 2004.1?


> Not only does this make Gentoo look bad as a distribution, but it leaves
> our users out in the cold as GRP, a feature that users very much enjoy,
> becomes useless due to its age.

You have *zero* metrics on what percentage of Gentoo users use GRP.  Thus,
your claim is completely unsubstantiated.  Also, as I pointed out earlier,
GRP *only* helps users during the initial installation of Gentoo.  It does
*absolutely nothing* for the tens of thousands of Gentoo users who, like
myself, have existing installations that they rely upon and expect
continued improvements to.

> Bring it up with the rest of the managers if you want to Kurt, but I
> assure you that it is the wrong decision to do so. Quarterly releases
> work for us devs, for the users, and for Gentoo. If you really are set on
> doing releases 1.4 style where features like GPG signing hold the release
> back forever, fine, but you are not doing what is right for our users.

You have one opinion.  I have another.  I'm a Gentoo user, first and
foremost.  Does my opinion as a user not matter?  A number of other devs
(who are also users) have spoken out against quarterly releases.  Do their
opinions not matter?

It bothers me that you have assumed that you know what is right for "our
users" despite the fact that you have done no actual research and have no
facts on which to base your claim.  It further bothers me that you seem to
be disregarding the opinions of pvdabeel, livewire, myself, weeve and a
number of other devs who have indicated that they have concerns and
reservations about the current releng process. 

--kurt

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

Re: [gentoo-releng] 2004.2 planning

[Nathaniel McCallum]

On Sun, 2004-05-02 at 07:29 -0400, Kurt Lieber wrote:
> * Releases are largely meaningless, comprised of nothing more than package
>   updates for GRP.

Lets use 2004.x quarterly releases to perfect our GRP proceedure and get
GRP online.  Once we are at that point we can divorce GRP from liveCD
releases if we need to.  If we did GRP quarterly we could do LiveCDs
tri-anually with a big release at the beginning of each year.  Though,
that may create more confusion.  I personally like quarterly or
tri-anually releases.  I don't want to have less than 3 times a year
releases.

Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Donnie Berkholz]

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

On Sun, 2004-05-02 at 09:32, Nathaniel McCallum wrote:
> On Sun, 2004-05-02 at 07:29 -0400, Kurt Lieber wrote:
> > * Releases are largely meaningless, comprised of nothing more than package
> >   updates for GRP.
> 
> Lets use 2004.x quarterly releases to perfect our GRP proceedure and get
> GRP online.  Once we are at that point we can divorce GRP from liveCD
> releases if we need to.

Exactly what I was thinking when reading this thread. Just provide a
package+stages CD (or two) quarterly, and let them use a LiveCD from the
(biannual?) LiveCD release. From what I see, it appears that much of the
QA time goes into getting the LiveCDs working properly.
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Lance Albertson]

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

On Sun, 2004-05-02 at 11:45, Donnie Berkholz wrote:
> On Sun, 2004-05-02 at 09:32, Nathaniel McCallum wrote:
> > On Sun, 2004-05-02 at 07:29 -0400, Kurt Lieber wrote:
> > > * Releases are largely meaningless, comprised of nothing more than package
> > >   updates for GRP.
> > 
> > Lets use 2004.x quarterly releases to perfect our GRP proceedure and get
> > GRP online.  Once we are at that point we can divorce GRP from liveCD
> > releases if we need to.
> 
> Exactly what I was thinking when reading this thread. Just provide a
> package+stages CD (or two) quarterly, and let them use a LiveCD from the
> (biannual?) LiveCD release. From what I see, it appears that much of the
> QA time goes into getting the LiveCDs working properly.

Funny, I was actually just thinking of that last night before I went to
bed. I see that quarterly releases for stages/grp package sets are
needed, but I really don't see a need for quarterly livecd releases.
There needs to be enough time to work out bugs/implement new features,
etc. The only thing that I can see for quarterly releases is driver
upgrades on the kernels used on the livecds. So, that may be debatable. 

Thoughts?

(mind you, any changes I suggest would start in the 2005.x release
schedule)

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Nathaniel McCallum]

On Sun, 2004-05-02 at 12:04 -0500, Lance Albertson wrote:
> On Sun, 2004-05-02 at 11:45, Donnie Berkholz wrote:
> > On Sun, 2004-05-02 at 09:32, Nathaniel McCallum wrote:
> > > On Sun, 2004-05-02 at 07:29 -0400, Kurt Lieber wrote:
> > > > * Releases are largely meaningless, comprised of nothing more than package
> > > >   updates for GRP.
> > > 
> > > Lets use 2004.x quarterly releases to perfect our GRP proceedure and get
> > > GRP online.  Once we are at that point we can divorce GRP from liveCD
> > > releases if we need to.
> > 
> > Exactly what I was thinking when reading this thread. Just provide a
> > package+stages CD (or two) quarterly, and let them use a LiveCD from the
> > (biannual?) LiveCD release. From what I see, it appears that much of the
> > QA time goes into getting the LiveCDs working properly.
> 
> Funny, I was actually just thinking of that last night before I went to
> bed. I see that quarterly releases for stages/grp package sets are
> needed, but I really don't see a need for quarterly livecd releases.
> There needs to be enough time to work out bugs/implement new features,
> etc. The only thing that I can see for quarterly releases is driver
> upgrades on the kernels used on the livecds. So, that may be debatable. 
> 
> Thoughts?

The real problem here is not a problem with releng so much as it is a
problem with portage.  I'm not knocking portage at all, it has served us
great thus far.  However, having a seperate GRP release is really
inconvienient as compared to a binary tree.  Most enterprise users and
most personal users who don't have a ton of time on their hands, want
the ability to build from source if they need too, but to use binaries
when they don't.  Portage does GREAT at the first, but not so great at
the second.  If we had a binary tree(s), we could do with more
infrequent liveCDs (and a lot less stress on releng).  GRP should be a
temporary provision until portage has better binary support (notice the
emphasis on TEMPORARY).  However, there are even some devs talking about
canning GRP.  This is simply not an option, but neither is making GRP
perminant.  We need to, once and for all, engineer portage for the
greatest possible flexability.  Anyway, I know I'll probably get flamed,
but as I see it we only have two options kill off GRP or make portage
support a binary tree.  I've said enough...

don_fireproof_suit()
Nathaniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sun, 2004-05-02 at 13:04, Lance Albertson wrote:
> 
> Funny, I was actually just thinking of that last night before I went to
> bed. I see that quarterly releases for stages/grp package sets are
> needed, but I really don't see a need for quarterly livecd releases.
> There needs to be enough time to work out bugs/implement new features,
> etc. The only thing that I can see for quarterly releases is driver
> upgrades on the kernels used on the livecds. So, that may be debatable. 
> 
> Thoughts?
> 
> (mind you, any changes I suggest would start in the 2005.x release
> schedule)

Devs,
I very much like this idea - I think that a LiveCD release for each
cycle is a bit too ambitious, especially with regard to how many bugs
they field. The only thing that we would have to negotiate is the
universal CD which contains distfiles and stages for a networkless
installation. We could discuss through that at a later date though
(2005.x integration if we decide upon it).

Would this solution work better for everyone than the current one? Kurt,
would this work from your perspective infra wise? We could align new
Gentoo-wide features (GPG signing) with bi or tri annual LiveCD
releases. Hopefully this is a step in a direction that leads towards
some compromise.

Also, I would like to apologize if at times I seemed close minded or
impatient during this thread. Kurt, I surely did not mean to start any
type of flame war - I do feel strongly about my opinions, but am open
for compromise, so please don't take any of this as a personal attack. I
blame it all on this cold from hell that I have ;)

Cheers,
//zhen
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Paul de Vrieze]

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

On Sunday 02 May 2004 21:49, John Davis wrote:
> Devs,
> I very much like this idea - I think that a LiveCD release for each
> cycle is a bit too ambitious, especially with regard to how many bugs
> they field. The only thing that we would have to negotiate is the
> universal CD which contains distfiles and stages for a networkless
> installation. We could discuss through that at a later date though
> (2005.x integration if we decide upon it).

Maybe the livecd could be partially updated: new stages and GRP packages, but 
the other parts the same. This would stop most bugs.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-releng] 2004.2 planning

[Lance Albertson]

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

On Sun, 2004-05-02 at 15:04, Paul de Vrieze wrote:
> On Sunday 02 May 2004 21:49, John Davis wrote:
> > Devs,
> > I very much like this idea - I think that a LiveCD release for each
> > cycle is a bit too ambitious, especially with regard to how many bugs
> > they field. The only thing that we would have to negotiate is the
> > universal CD which contains distfiles and stages for a networkless
> > installation. We could discuss through that at a later date though
> > (2005.x integration if we decide upon it).
> 
> Maybe the livecd could be partially updated: new stages and GRP packages, but 
> the other parts the same. This would stop most bugs.
> 
> Paul

Yeah, this would be great. Our livecd is the first thing users see when
they first try installing Gentoo. If it appears to have any sort of bugs
on it, they start to lose faith in the distro at a very early stage.
Minimizing bugs on the livecd should be very important because of this
(of course, stages, grp packages should have minimal bugs as well).
Perhaps, if there are known issues that couldn't be resolved before a
release (we should always fix a bug before a release if possible), maybe
we should have a message right after the prompt comes up that states
something about the bug. I know it would be better to just fix the darn
thing, but the more information we give to our issues about known
problems, the better! It also minimizes on dup'ed bugs.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sun, 2004-05-02 at 16:04, Paul de Vrieze wrote:
> 
> Maybe the livecd could be partially updated: new stages and GRP packages, but 
> the other parts the same. This would stop most bugs.
> 
> Paul

Paul -
I would like to do that, but the universal LiveCD would have to be
rebuilt and re-uploaded, and they are around 700MB a piece. Perhaps we
could figure out an easier way to do this so that we can save infra some
mirror space. The alternative is that we could drop the "networkless"
install and just keep the minimal LiveCD which just boots the machine
and contains no stages or distfiles.

Cheers,
//zhen
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Jeffrey Forman]

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

I'm not too sure I'm hot on dropping the networkless install livecd.
Contrary to popular belief, there are areas of the globe without
broadband at home and big fat quota-free pipes (like some .au pipes
which meter bandwidth). I just took a look at the size difference
between the minimal and universal livecd's and there is a big size
difference in say dropping minimal and only keeping universal (something
i am not advocating). Just a thought...

-jeff


On Sun, 2004-05-02 at 15:30, John Davis wrote:
> On Sun, 2004-05-02 at 16:04, Paul de Vrieze wrote:
> > 
> > Maybe the livecd could be partially updated: new stages and GRP packages, but 
> > the other parts the same. This would stop most bugs.
> > 
> > Paul
> 
> Paul -
> I would like to do that, but the universal LiveCD would have to be
> rebuilt and re-uploaded, and they are around 700MB a piece. Perhaps we
> could figure out an easier way to do this so that we can save infra some
> mirror space. The alternative is that we could drop the "networkless"
> install and just keep the minimal LiveCD which just boots the machine
> and contains no stages or distfiles.
> 
> Cheers,
> //zhen
-- 


--------------------
Jeffrey Forman
Gentoo Infrastructure
Gentoo Release Engin.
jforman@gentoo.org
--------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Sven Vermeulen]

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

On Sun, May 02, 2004 at 04:30:11PM -0400, John Davis wrote:
> I would like to do that, but the universal LiveCD would have to be
> rebuilt and re-uploaded, and they are around 700MB a piece. Perhaps we
> could figure out an easier way to do this so that we can save infra some
> mirror space. The alternative is that we could drop the "networkless"
> install and just keep the minimal LiveCD which just boots the machine
> and contains no stages or distfiles.

This would result in several complaints by many users. A networkless
installation is imho frequently used (also because it's tied closely with
GRP installations which are quite popular).

One possibility (which I rather not advocate because I see more
disadvantages than advantages) is to have the user build their own
installation media.

Perhaps most confusion here is because we (well, at least "I") don't know how 
many resources are put in all the individual subtasks of a release? 

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-releng] 2004.2 planning

[Paul de Vrieze]

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

On Sunday 02 May 2004 22:30, John Davis wrote:
> On Sun, 2004-05-02 at 16:04, Paul de Vrieze wrote:
> > Maybe the livecd could be partially updated: new stages and GRP
> > packages, but the other parts the same. This would stop most bugs.
> >
> > Paul
>
> Paul -
> I would like to do that, but the universal LiveCD would have to be
> rebuilt and re-uploaded, and they are around 700MB a piece. Perhaps we
> could figure out an easier way to do this so that we can save infra
> some mirror space. The alternative is that we could drop the
> "networkless" install and just keep the minimal LiveCD which just
> boots the machine and contains no stages or distfiles.

This was an idea to stop bugs popping up in livecd's. I feel the 
diskspace issue is a different one. I personally like the networkless 
cd's as I have good bandwidth and favour uptodateness. Although I like 
GRP too (saves a whole lot of time).

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAlgQ3bKx5DBjWFdsRAjUSAJ42ZzlVHrYCm6BIibTMja/SW6QG2ACgx9SI
iIwwflDDe4t5wLnVRBKCF0k=
=DaMC
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[Sven Vermeulen]

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

On Sun, May 02, 2004 at 10:04:04PM +0200, Paul de Vrieze wrote:
> Maybe the livecd could be partially updated: new stages and GRP packages, but 
> the other parts the same. This would stop most bugs.

Documentation-wise this would be a good improvement as it would allow us to
document the bootoptions and -kernels well without having to redefine them
every release.

Wkr,
      Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Documentation & PR

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

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sun, 2004-05-02 at 07:29, Kurt Lieber wrote:
> 
> It bothers me that you have assumed that you know what is right for "our
> users" despite the fact that you have done no actual research and have no
> facts on which to base your claim.  It further bothers me that you seem to
> be disregarding the opinions of pvdabeel, livewire, myself, weeve and a
> number of other devs who have indicated that they have concerns and
> reservations about the current releng process. 
> 
> --kurt

Kurt -
I do not wish to get into a flamewar. I do know that GRP is something
used by our users - talk to swift about how many documentation requests
he gets for GRP, or talk to anyone who sits in #gentoo and see how many
questions they field about GRP. From what I have seen and from what I
have heard from good sources, GRP is important to the users. GRP does
not just serve a minority of users, but it serves users who:

A- Don't want to install from source because they don't have a (fast)
net connection 
B- Don't want to install from  source because they don't have the time
or hardware resources to
C- Don't want to deal with GCC/ GLIBC/ foo compile problems

GRP is not something just for a minority - removing GRP alienates a
subset of our users that do not have fast hardware or a fast network
connection. Even if they do make up a minority, it is our
*responsibility* to cater to their needs as well, its good customer
satisfaction practice. If you want me to do research, I will. Setting up
a user survey is no big deal.

I am not ignoring the concerns of any other devs. I have replied to each
and every one of their concerns in hope of finding a middle ground.
There are bugs in everything Kurt, and .1 was only the second release in
a new system and it has been getting better each time. The development
process for release engineering takes time. From what I have seen, you
want instant results and are not listening to anything that I am saying.
The releng team is working their best to try and resolve the problems
that we have. Talk to Livewire - after his recent e-mail we sat down in
#-releng and did a massive bugfixing on Catalyst. I have taken numerous
requests from the arch release coordinators on how to improve things.
Pieter has  a REMARKS file in Catalyst CVS with requests that will
better Catalyst and make the process more efficient, I have been
steadily completing every one of his requests. I am being as flexible as
possible.

Kurt, I do not understand what the problem is. I am working the best
that I can, and so is the rest of my team.  The fact is that *we cannot
stop quarterly releases in the middle of the year*. We will finish out
the year and do a review at the end.  If you would like to be a part of
that, please do as your input is much appreciated. We have bugs. We are
fixing them. Give us some time. If you would like to contact me off list
to discuss this, please do as I think there is a miscommunication here.
I can mail you my cell phone number.

Cheers,
//zhen 
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Kumba]

Kurt Lieber wrote:

> I didn't see Bob's original message, but he, Pieter and now myself are
> going to be saying exactly the same thing.
> 
> Quarterly releases are too ambitious.  We need to slow down.
> 
> Right now, we're so focused on quarterly releases that we cannot take
> enough time to develop features that may take longer than three months to
> code, test and get ready to go.
> 
> As Pieter pointed out earlier, if we want to release something in July and
> do proper QA on it ahead of time, we don't really have much time to do any
> actual *development*.  Who cares if we're releasing 4 new versions a year
> if they're all identical save for minor cosmetic/typo stuff?  
> 
> Quarterly releases need to stop.

Switching to a different release schedule in the middle of 2004 could 
cause confusion for users.  So here's my idea:

For the remainder of 2004, release our quarterly releases, this means 
2004.2 and 2004.3.  Take a big break during the summer for all the 
emerge enchancements (including --security) and consider making 2004.2 
in late july or early august, followed by 2004.3 in late october or 
early november.

For 2005, One idea which still provides semi-frequent gentoo releases 
could be going from a quarterly release schedule to a tri-annual release 
schedule, i.e., one every four months.  That's still more than other 
distros, but it also strikes a nice balance by allowing an average of 
probably 3 months for hacking/enhanching, followed by probably a month 
or so of the fun process of stage/grp building/testing before release.

So for 2005, you could do something like:

Late Jan -- 2005.0
Late May -- 2005.1
Late Sep -- 2005.2


Thoughts?


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] 2004.2 planning

[John Davis]

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

On Sat, 2004-05-01 at 23:14, Kumba wrote:
> 
> Switching to a different release schedule in the middle of 2004 could 
> cause confusion for users.  So here's my idea:
> 
> For the remainder of 2004, release our quarterly releases, this means 
> 2004.2 and 2004.3.  Take a big break during the summer for all the 
> emerge enchancements (including --security) and consider making 2004.2 
> in late july or early august, followed by 2004.3 in late october or 
> early november.
> 
> For 2005, One idea which still provides semi-frequent gentoo releases 
> could be going from a quarterly release schedule to a tri-annual release 
> schedule, i.e., one every four months.  That's still more than other 
> distros, but it also strikes a nice balance by allowing an average of 
> probably 3 months for hacking/enhanching, followed by probably a month 
> or so of the fun process of stage/grp building/testing before release.
> 
> So for 2005, you could do something like:
> 
> Late Jan -- 2005.0
> Late May -- 2005.1
> Late Sep -- 2005.2
> 
> 
> Thoughts?
> 
> 
> --Kumba

The idea for triannual releases definitely has some potential. After
2004, which you are right in saying that a change during this time would
be disruptive, we can surely do a review and see what works best. As
long as we have some type of continual release cycle so that our users
can be kept up to date, I will be happy.

The schedule that you proposed for the remainder of 2004 is what releng
actually the same as what we have planned presently ;) Check out the .2
info page -
http://www.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml

Thanks for your input -

Cheers,
//zhen
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] 2004.2 planning

[Jason Huebel]

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

K, so I've been sitting back watching this thread, formulating my evil
response. :-)  So here goes:

LiveCDs:
- ---
I like the idea of moving to a 4 month release cycle in 2005.

However, I think the quarterly release cycle is healthly for the amd64
arch right now because we are working to refine our LiveCDs for various
hardware.  It important that we have more frequent updates to our
LiveCDs because amd64 hardware is still a moving target.  For instance,
it's only been in the past few months that amd64 laptops have come on to
the market in any volume.  So we're working on refining the available
kernels to support them.


GRP:
- ---
Face it, devs hate having to build GRP because it's the longest part of
our release process.  But even I've used the GRP packages a number of
times so I could quickly build a Gentoo box on slow hardware. I really
would hate to have to build KDE or GNOME on a P3/550. :-)

GRP is good for users, but time consuming for releng.  Like it or not,
it's a necessary evil.


Feature Requests:
- ---
Releases aren't always about new features.  I think that we should
consider having one or two releases a year that include significant new
features, but the other releases are maintenance.  It seems to me that a
.0 release is a feature release, while >=.1 is maintenance. Or am I just
naive about what version numbers should really mean? ;-)

I would even be cool with having .0 and .2 as feature releases, like
jforman mentioned.  But I think it's overly ambitious to include some
new whizbang feature in every release.


LiveCDs:
- ---
Could the LiveCD's be broken up differently, making them easier to
maintain?  What if there was one bootable CD -- bootCD -- rather than
two -- universal and minimal?  That bootCD could be ejected and the user
could insert the appropriate stageCD. The stageCD's wouldn't need to be
bootable.  So, you could have:

bootCD - bootable, docs
stage1CD - stage1 tarball, distfiles
stage2CD - stage2 tarball, distfiles
stage3CD - stage3 tarball, distfiles
packageCD - packages

Don't know if this idea has any merit, but...


Other Thoughts:
- ---
catalyst docs need attention. 2004.1 was my first release and it was
tough.  zhen and beejay were a HUGE help, but I found there were times
when my CPU sat idle because I didn't know what to do next.  So I had to
wait around in the -releng channel for help. I understand that everyone
is busy and can't cater to my schedule (don't I wish :-), but if there
were some more comprehensive docs (or even some type of checklist) we
would all be better off.

I've got some handwritten notes on the steps for building a release.  I
guess I could XML-ify them if they would be useful to others.


That's about all I can think of for now. It's been a long day and I have
a nice bottle of cognac calling my name...

"Jason... Drink me..."
/me wanders off...


Jason Huebel
Gentoo/amd64 Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAlx/bbNgbbJup4jARAuveAJ4oAq3jDGAaDFVZF1Ag0mhe+GMYgwCdHsB1
Dlb7V/+VtgM0+eCzIQzCefo=
=H34G
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list